iDefense reported multiple buffer overflows in OpenOffice.org's EMF file parser. If a victim opens a malicious EMF file, it could be possible to execute arbitrary code with the permissions of the user running OpenOffice.org.
Created attachment 320049 [details] Upstream patch
Caolan, is the patch in comment #1 final patch used by upstream? It does some nEndPos validation, but does not seem to try to prevent integer overflow in: nEndPos += nStartPos; nStartPos is position in the stream, nEndPos is metafile size read from the file, so this addition may wrap and nEndPos can be lower than nStartPos. So some tests based on nEndPos may go wrong.
Created attachment 321166 [details] final patch Final patch is here, its the same. Might be quite tricky to navigate a .emf past the size tests to get to any (nEndPos - nStartPos) comparisons.
The upstream patch basically does 2 types of changes: - integer overflow checks - checks using nEndPos to determine whether there is enough data in the file before reading larger arrays Second type of changes does not seem to be directly related to what iDefense reports. It seems to rather be a change to make the code bit more correct, and defensive. Without them, hitting EOF in the middle of the larger read seems to be the worst case. If no exception is raised when EOF is hit, values read are undefined, which is not worse than attacker-controlled ones. Please correct me if I wrong in that, as if those checks are security-relevant as well, than "nEndPos += nStartPos" overflow does matter. Thank you!
> The upstream patch basically does 2 types of changes: > - integer overflow checks > - checks using nEndPos to determine whether there is enough data in the file > before reading larger arrays right > Second type of changes does not seem to be directly related to what iDefense > reports. right > It seems to rather be a change to make the code bit more correct, and > defensive. Yup, my understanding is that sj decided to stick some defensive code in there while addressing the (messy set of) iDefense overflow issues.
Ok, thanks, sounds reasonable. If you are in communication with sj, please drop him a note about nEndPos issue, so the code can be made even bit more defensive in the future revisions. Thanks!
Public now via: http://www.openoffice.org/security/cves/CVE-2008-2238.html Fixed upstream in 2.4.2.
openoffice.org-2.3.0-6.17.fc8 has been submitted as an update for Fedora 8. http://admin.fedoraproject.org/updates/openoffice.org-2.3.0-6.17.fc8
openoffice.org-2.4.2-18.1.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/openoffice.org-2.4.2-18.1.fc9
openoffice.org-2.4.2-18.1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
openoffice.org-2.3.0-6.17.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
This issue was addressed in: Red Hat Enterprise Linux: http://rhn.redhat.com/errata/RHSA-2008-0939.html Fedora: https://admin.fedoraproject.org/updates/F8/FEDORA-2008-9333 https://admin.fedoraproject.org/updates/F9/FEDORA-2008-9313