iPhone 3.0 security fixes
Safari 4.0.2
It's one of the Safari bugs that interests me today, CVE-2009-1725 or an off-by-one heap memory corruption in Webkit. The patch says it all, really:
http://trac.webkit.org/changeset/44799/trunk/WebCore/html/HTMLTokenizer.cpp
Here's the faulty code:
checkBuffer(10);
// ignore the sequence, add it to the buffer as plaintext
*dest++ = '&';
for (unsigned i = 0; i < cBufferPos; i++)
dest[i] = m_cBuffer[i];
Turns out, that 10 should be an 11 so it is possible to write a semi user-controlled byte off-by-one off the end of a heap chunk. If you know what useful tricks you might do with that in the various heap implementations (Windows, Mac, Linux) -- please leave a comment.
Here's a demo HTML document:
https://cevans-app.appspot.com/static/webkitentityoffbyone.html
It tries to pad the HTML so that the errant byte is written off the end of the heap, instead of into buffer slack. Bear in mind that the most common symptom here is no symptom at all :) In Chrome / Windows, repeated refresh of that URL would occasionally render a random Asian character, but no crash.
4 comments:
(fixing the grammar problems in my first attempt)
The best prospect for exploitation would be if the overwrite is made to happen in a small memory chunk, i.e. much smaller than the host/OS page size. Some stack implementations (the BSDs at least) lay these back-to-back, so it might be possible to clobber an adjacent object - perhaps a function pointer or bit of JIT :)
I strongly doubt that an attack on the heap bookkeeping itself would be feasible with this, at least for anything modern.
@djm: Interestingly, there was a talk at this year's BlackHat by a couple of guys from ISS X-Force: http://www.blackhat.com/presentations/bh-usa-09/MCDONALD/BHUSA09-McDonald-WindowsHeap-PAPER.pdf
It does successfully attack the metadata of certain types of heap chunks (Windows XP / 2003), using just a 1-byte heap overflow.
I stand corrected. Yay for Windows, constantly lowering my expectations.
Post a Comment