Hide Forgot
Common Vulnerabilities and Exposures assigned an identifier of CVE-2009-1725 to the following vulnerability: KDE Konqueror allows remote attackers to cause a denial of service and potentially execute arbitrary code via a buffer overflow due to improper handling of numeric character references. This issue was first discovered in WebKit and fixed in KHTML (trunk, 4.3 branch and 3.5 branch) a few hours ago: http://websvn.kde.org/?view=rev&revision=1002162 http://websvn.kde.org/?view=rev&revision=1002163 http://websvn.kde.org/?view=rev&revision=1002164 I am already working on Fedora updates.
kdelibs-4.2.4-6.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/kdelibs-4.2.4-6.fc11
kdelibs-4.2.4-6.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/kdelibs-4.2.4-6.fc10
kdelibs3-3.5.10-13.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/kdelibs3-3.5.10-13.fc11
kdelibs3-3.5.10-13.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/kdelibs3-3.5.10-13.fc10
webkit changeset: http://trac.webkit.org/changeset/44799
PoC: ---- http://trac.webkit.org/browser/trunk/LayoutTests/fast/parser/eightdigithexentity.html?rev=44799&format=txt Expected PoC output: -------------------- http://trac.webkit.org/browser/trunk/LayoutTests/fast/parser/eightdigithexentity-expected.txt?rev=44799&format=txt
Direct link to run the testcase in Konqueror: http://trac.webkit.org/export/46476/trunk/LayoutTests/fast/parser/eightdigithexentity.html
kdelibs-4.2.4-6.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
kdelibs-4.2.4-6.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
kdelibs3-3.5.10-13.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
kdelibs3-3.5.10-13.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
Created attachment 356315 [details] Proposed patch for review Proposed patch attached to this bug, please review it. What was wrong? 1. size of ushort QChar -> changed to unsigned int (same as in WebKit) 0x00FFFFFF has been truncated to 0x0000FFFF 2. so there wasn't possible to check if entity is bigger than 0x0010FFFF BTW: how to credit WebKit people in KHTML code as I used the code?
Official statement from Red Hat Security Response Team regarding this issue: ---------------------------------------------------------------------------- Not vulnerable. This issue did not affect the versions kdelibs package, as shipped with Red Hat Enterprise Linux 3, 4, or 5. Explanation: ------------ The relevant parseEntity() routine, responsible for processing HTML entity content in KHTML, contains additional checks for the length of provided numeric (decimal, hexadecimal) and name representation of the HTML entity, which are preventing the occurrence of this flaw.
The exact code rows are: ----------------------- 639 case Hexadecimal: 640 { ... 642 int ll = kMin<uint>(src.length(), 8); 658 case Decimal: 659 { ... 661 int ll = kMin(src.length(), 9-cBufferPos); 678 case EntityName: 679 { 680 int ll = kMin(src.length(), 9-cBufferPos); 694 // be IE compatible and interpret even unterminated entities 695 // outside tags. like "foo  stuff bla". 696 if ( tag == NoTag ) { 697 const entity* e = kde_findEntity(cBuffer, cBufferPos); 698 if ( e && e->code < 256 ) { 699 Entity = SearchSemicolon; 700 break; The above lines ensure, the resulting buffer is always at most 9 characters long, so checkBuffer(10) is sufficient check. In case longer entities are provided, they are handled as undefined HTML entities and [] sign is used for displaying them: 732 // ignore the sequence, add it to the buffer as plaintext ... 742 Entity = NoEntity; 743 EntityChar = QChar::null; Note: It's possible to experience the crash by removing the above "kMin" checks, rebuild kdelibs and provide HTML entity string longer than 10 characters.
OK, so the upstream commit which bumped the buffer size to 11 is nonsense? jreznik says he has a fix to made the testcase pass, I guess that one should just be committed upstream (and possibly included in the Fedora KDE 4.3.0 update sets) as a regular bugfix, as it's just a minor rendering fix, not a security fix (as per the above analysis).
Yes, upstream commit is nonsense as there's different handling in WebKit. For rendering patch - it should be OK but upstream doesn't care about this issue as there's little possibility to find affected websites. Even Firefox is not handling it. The question is if we really want it in Fedora then.
This issue does NOT affect the version of WebKit-gtk package, as shipped with Fedora 10 (WebKit-gtk-1.0.0-0.15.svn37790.fc10.*) and the version of webkitgtk package, as shipped with Fedora 11 (webkitgtk-1.1.8-1.fc11.*). This issue does NOT affect the version (qt4-4.2.1-1) of qt4 package, as shipped with Red Hat Enterprise Linux 5. This issue affects the versions of qt-4.5.2 package, as shipped with Fedora 10 (qt-4.5.2-1.fc10.2.src.rpm) and Fedora 11 (qt-4.5.2-1.fc11.2.src.rpm). Please fix.
it's fixed in qt-4.5.2-2. I will push it in F10/F11 update today
Reopening to track the QtWebKit version of the issue. This is strange, I thought I checked Qt 4.5.2 and found this already fixed there. I must have either forgotten or not looked properly.
qt-4.5.2-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/qt-4.5.2-2.fc11
qt-4.5.2-2.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/qt-4.5.2-2.fc10
qt-4.5.2-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
qt-4.5.2-2.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
Looks like this got taken care of eons ago, closing.