877 bytes, patch
|Details | Diff | Splinter Review|
1.05 KB, text/html
I don't know how easy it would be to actually create an exploit for this, but the code certainly looks wrong. A simple fix should be to move the check for out-of-memory before the line that writes the null-terminator.
Attachment #514026 - Flags: review?
Attachment #514026 - Flags: review? → review?(sdwilsh)
Assignee: nobody → jfkthame
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment on attachment 514026 [details] [diff] [review] patch, check for OOM before writing the null terminator r+a=me. Please land this! And probably on branches too!
Comment on attachment 514026 [details] [diff] [review] patch, check for OOM before writing the null terminator The same patch applies to 1.9.2 and 1.9.1 (just moved into the netwerk/mime/src directory); requesting approval to land on branches as well.
Pushed to trunk: http://hg.mozilla.org/mozilla-central/rev/f8279991d58f
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Comment on attachment 514026 [details] [diff] [review] patch, check for OOM before writing the null terminator Approved for 22.214.171.124 and 126.96.36.199, a=dveditz for release-drivers
There are locations where stomping a null byte can make all the difference in the world, but with things like ASLR it would seem pretty hard to make a reliable exploit out of this. Especially if you're running close to OOM. Is this really a plausible attack ('critical') or more theoretical ('moderate' or 'low')?
I agree totally that without either a separate address leak bug or the target using a non-ALSR'ed platform reliable exploitation of this sort of bug is unlikely. Windows XP is still both supported and widely used though :-( (I've just rebooted an XP vm a couple of times and attached olly to firefox, the stack appears to be at a static base. I don't really know much about windows though, or whether stuff like EMET would help that?) I'll offer another possible way to leverage this bug to achieve code execution: Given the base address of the stack, a byte of a function pointer or return address on the stack can be set to 0x00. Successful exploitation would require finding a suitable pivot (or 'ROP gadget' if you want) at such an address such that the instruction sequence at that address was, for example, something like 'sub esp, 0xXX; ret', where 0xXX would move esp into a stack buffer you control. Coupled with a ret-to-lib DEP defeat this would yield arbitrary execution. I would say that almost all 'critical' memory corruption bugs would still require either an address leak or to be on a non-aslr'ed platform to be turned into a reliable exploit (without a heap spray.) I'd say this was a critical bug, but it's not my decision :-)
(What is certainly true is that it would be a lot of effort to turn this from the theoretical attack outlined above to a plausible one)
(I might have mis-interpreted your point, sorry, you're also quite right that even triggering this code (getting exactly the right ::Clone call to fail) would be pretty hard too!)
BUG 443299 was a pretty similar bug for which a PoC exploit was written though :-)
I also have a few scripts for monitoring the fragmentation of process address spaces which you'll almost certainly need to get this working at the moment. I'll attach them if needed/wanted
Pushed to 1.9.1 and 1.9.2 branches: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f51e2d406a0c http://hg.mozilla.org/releases/mozilla-1.9.2/rev/eaca9531b263
Target Milestone: --- → mozilla2.0
You need to log in before you can comment on or make changes to this bug.