Feeds

back to article 'Better than Adobe' Foxit PDF plugin hit by worse-than-Adobe 0-day

A new security bug in the popular Foxit PDF reader plugin for web browsers allows miscreants to compromise computers and install malware. There's no patch for this zero-day vulnerability. Italian security researcher Andrea Micalizzi discovered that the latest version of the software crashes if users are tricked into clicking on …

COMMENTS

This topic is closed for new posts.
Paris Hilton

Does it affect the Foxit standalone reader?

I have my FF set to "Open in external app" rather than "open with plugin". I suspect it won't.....

0
0
Silver badge
Thumb Up

Re: Does it affect the Foxit standalone reader?

I have my FF set to "Open in external app" rather than "open with plugin"

Same here but I use the excellent SumatraPDF reader. It's open source with portable and installable versions.

4
0
Anonymous Coward

Re: Does it affect the Foxit standalone reader?

Yep, Sumatra is really good for windows users - small, light and fast.

In the Linux world I don't think you can beat Okular, I wouldn't soil my 'nix box with Foxit.

6
0
Silver badge
Thumb Up

Re: Does it affect the Foxit standalone reader?

That's what I use. Don't bother with PDF plugins.

0
0
Silver badge
Meh

Re: Does it affect the Foxit standalone reader?

Thought I'd switch from Foxit to Sumatra, but the fugly 1998-style website didn't fill me with confidence. All looked a bit two-bit for my taste, although Sumatra's focus on simplicity was good, avoiding all the security pitfalls of over-complication. Hmmm, on second thoughts, there may be a theme here that bears further inspection. To be continued...

In any case, props to Krzysztof Kowalczyk, Sumatra's author, for his vowel-aversion.

1
0

Re: Does it affect the Foxit standalone reader?

Same here.

Foxit Reader is the new Adobe Reader = BLOATWARE.

Sumatra PDF is the new Foxit Reader.

1
0
Boffin

Re: Does it affect the Foxit standalone reader?

The PDF-reading and interpreting code is not vulnerable. The vulnerability is in how the browser plug-in interprets URLs is has to open and pass to the PDF reader.

1
0

Eugh.

2001 called, they want their exploit back.

5
0

Re: Eugh.

2001 called?

Did you warn them about the September 11th attacks?

7
0
Silver badge
Devil

"Better than Adobe"

That's like boasting about having a two inch cock.

12
0
Anonymous Coward

Re: "Better than Adobe"

At least a two inch cock is useful when compared to adobe :)

0
0
Anonymous Coward

Re: "Better than Adobe"

Lucky sod! Where did you get it from?

0
0
Bronze badge

"The offending code, highlighted by Micalizzi, is a simple loop that copies the entire URL into a fixed-sized buffer while scanning for '%' escape codes"

Programmer-facepalm.

Seriously? A fixed-sized buffer that you didn't bother to check the contents fitted inside? I mean, not even a check, let alone actually sizing the buffer properly in the first place?

4
0
(Written by Reg staff) Silver badge

Re: Lee

It's a rather neat and tidy bug, if you look at the code in the disclosure.

mov al,[esi+ebp]

cmp al,'%'

jz handle_url_escape_code

mov ecx,[esp+1Ch]

mov [ebx+ecx],al

jmp continue_loop

So.. keep looping, writing whatever's in the URL string (pointed to by esi+ebp, copied into al) into the buffer at ebx+ecx one byte at a time. continue_loop increments esi and ebx.

I've only briefly glanced at the rest of the code, but it does appear to do some checking (multiple uses of repne scasb) to make sure it doesn't run past the end of the URL string - but not the buffer boundary.

C.

2
0
Silver badge

Significance

I'm always a bit sceptical about the danger of this type of bug. Sure, it will cause unpredictable errors, but lets look at what could happen.

As they talk about stack overflows, I'm presuming that the URL is being copied into a variable stored on the stack, i.e. a local variable. When this exploit runs, whatever is in the memory locations after this variable will contain some data that is under the control of the exploiter.

So. The memory locations after the variable will be another variable, or possibly a stack frame header including the return address and possibly some saved register contents.

If it's another variable or saved register contents, then the previous contents will be lost, and/or some unpredictable behaviour might happen when the variable is used. It might be a pointer, which may mean that some other data address could be clobbered later in the code. It could be a vector (pointer to some code), but in order to exploit this, you'd have to understand the rest of the code really well. If it's a stack frame (and I've not checked the direction of stack growth so don't know whether it will be the frame for this function or another), then the return address may be damaged, which could be used to control where the code returns to.

The comment from Paul Ducklin from Sophos, re. "The crash, which is a side-effect of a stack overflow, pretty much lets you write to a memory location of your choice," seems an over-reaction, as it is likely that you could overwrite an address following this buffer in the page the stack is in or a contiguously later memory page. Any point after this will probably generate a segmentation or address violation, as soon as it tries to write to an unallocated address. To me, this is not the same as "a memory location of your choice".

You've potentially got some executable code (if that is what the URL contains) stored in a memory location you should not have access to, but it's not in the program text, and I've not yet seen a method described of triggering that code (the return address in a stack frame header is the only one I can see which would affect the execution stream). This does not appear to be a practicle means of injecting code, much more likely some DoS attack against the user running Foxit.

So it is important (all bugs should be regarded as such), and I'm sure there may be some special cases I've not spotted, but on casual inspection it can only be described as a DoS vulnerability with a 'potential' remote execution problem. saying any more would be FUD.

Possibly someone could educate me if I am wrong.

0
6
Facepalm

That was my first thought too. How can any programmer fall foul of such a simple and obvious failure case?

0
0
Headmaster

Re: Significance

"Possibly someone could educate me if I am wrong."

http://www.eecis.udel.edu/~bmiller/cis364/2012s/readings/buff-overflow.html

3
0
Boffin

Re: Significance

Google for ``smashing the stack for fun and profit''.

PDF link here http://www-inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smashing.pdf

5
0
Silver badge
Thumb Up

Re: Significance

Google for ``smashing the stack for fun and profit''.

How I learnt how to do buffer overrun exploits too :)

0
0
(Written by Reg staff) Silver badge

Re: Significance

"If it's another variable or saved register contents, then the previous contents will be lost, and/or some unpredictable behaviour might happen when the variable is used"

Yes, but: doesn't matter, got EIP. You've got control of execution and your own code in memory: spawn a new process to do evil things and watch the victim burn. In a nutshell. It's not quite that trivial. Ideally, you don't want the attacked process to crash (especially if targeting an OS kernel) but it's not the end of the world. For you, anyway.

But, anyone weaponising this particular flaw will need to jump through the usual hoops of buffer overflow exploitation. Your payload may well be in a non-executable memory area so the processor will fault if it and the OS support NX, for example. You'll probably blow away the stack cookie too, if it's there - it's not in this program, though.

And the browser or corporate web proxy may reject or otherwise screw up a stupidly long URL so you can't be too loose with your payload.

However, the goal isn't to pwn everyone using Foxit, just enough of those using the PDF plugin on susceptible systems to make it worthwhile.

See others who have pasted the smashing the stack paper; you guys beat me to it.

C.

0
0
Silver badge

Re: Significance @runwin

OK, I've read the page, and it falls into the "change the return address" scenario that I mentioned. Having read that, and done what I should have done before and worked out the way stacks are stored, it looks as if most systems grow their stack 'down (higher to lower addresses)', and I admit that the return address will be stored in memory with a higher address than the buffer, so could be overwritten.

But I still think for several reasons, that this will be more likely to cause a DoS, rather than a remote code execution problem in this case.

0
1
Silver badge

@deodesigns

In this case, it cannot be the kernel stack.

0
0
Silver badge
Thumb Up

Re: Significance @Gerhard den Hollander

Is this PDF safe to read in Foxit?

1
0
(Written by Reg staff) Silver badge

Re: Peter

"In this case, it cannot be the kernel stack."

This is entirely unrelated to the kernel. It's, as far as I can tell, completely in userspace. The plugin is a DLL but the context is ring-3.

C.

0
0
Silver badge

OK, I got it. Thanks.

I had not considered using NOPs to make the return address less critical, nor the fact that you could find the absolute address of the stack frame relatively easily (although it is compiler specific). That stack_smashing paper is dynamite.

Each exploit has to be taylored to the OS and processor, but I guess that Wintel is a big target.

0
0
Bronze badge

It was only a matter of time, I suppose. The more popular Foxit became, the more likely it was to be examined and found wanting.

0
0
Anonymous Coward

Foxit used to be good before it became bloated.

Switch to Sumatra. Zero bloat and starts instantly.

1
0
Bronze badge
Windows

2:20 PM GMT

and my install of Foxit updated itself - bug fixed??????

Also

BLOATWARE ??!! Compared to Adobe it suffers from anorexia!!!!

1
0
FAIL

Diversity

The problem with Adobe is that it's ubiquitous... When you have one identical piece of software installed on millions of systems it invariably becomes a target, and this will always be a problem because no software is perfect.

Having a variety of different readers out there, with a good healthy split of install base is good for everyone.

Also people being aware of alternatives makes it easier for someone to temporarily switch to something else until a 0day is fixed in their preferred application.

And it also helps against targeted attacks, since the attacker must first try to find out what software their target will be using.

1
0
Anonymous Coward

I use PDF-XChange Viewer from the rather creepily named Tracker Software.

2
0
Thumb Up

"I use PDF-XChange Viewer from the rather creepily named Tracker Software."

Lightweight, fast and can unlock/edit and save edited forms. It's really excellent.

1
0
Bronze badge

The problem with..

The problem with both Foxit and Adobe is that they use the noxious exact font smoothing.

If anyone ever finds a PDF reader that uses old-style pixel alligned screen fonts, let me know.

0
0

Stooped using Foxit

When the Spyware and Malware started creeping in with the installer.

0
0

Thanks to this article and a New Year system refresh (fresh install of Windows 7 from win8 release version before MS started asking for money - not that I hate Windows 8 - I just don't like it enough to pay for it), i put on Adobe reader 11 instead of Foxit, but Jesus, its so slow compared to Foxit.

So, 2013, Disabled Java, almost pissed off enough with Facebook's monetising attempts to close my account, and looking for a new PDF reader...

0
0
This topic is closed for new posts.