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.....
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 …
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.
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.
"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?
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.
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.
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.
"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.
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.
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.
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...