jabberd2, when expat is used, do not properly detect recursion during entity expansion, which allows context-dependent attackers to cause a denial of service (memory and CPU consumption) via a crafted XML document containing a large number of nested entity references, aka the "billion laughs attack." References: [1] http://en.wikipedia.org/wiki/Billion_laughs [2] http://www.webcitation.org/5wwJidGdh
This issue affects the versions of the jabberd package, as present within EPEL-5 and EPEL-6 repositories. This issue affects the versions of the jabberd package, as shipped with Fedora release of 13 and 14.
The CVE identifier of CVE-2011-1755 has been assigned to this issue.
Created attachment 496732 [details] Proposed patch from Tomasz Sterna of jabberd2 upstream
And relevant correction from Jamie Strandboge of Ubuntu Security Team regarding the patch in previous comment (updated patch version also attached in next comment): > Great to hear that! > In the meantime I reached Tomasz Sterna who provided a patch for jabberd2 > (attached). There is a typo in the jabberd2 patch I discovered while backporting it to 2.0s11. The patch has this: +#if XML_MAJOR_VERSION > 0 +/* XML_StopParser is present in expat 2.x */ +#define HAVE_XML_STOPPARSER +#endif + So the check and the comment don't go together, and indeed, according to the changelog, 2.0s11 has expat 1.95.7. This should obviously be changed to '#if XML_MAJOR_VERSION > 1'. Attached is a lightly tested patch with this change along with massaging for 2.0s11. Using the reproducer, I see the patch is working via the c2s log: Tue May 3 21:53:51 2011 [notice] [13] [127.0.0.1, port=52834] connect Tue May 3 21:53:51 2011 [notice] [13] [127.0.0.1, port=52834] error: Stream error (Expected stream start) Tue May 3 21:53:51 2011 [notice] [13] [127.0.0.1, port=52834] disconnect Prior to the update, c2s would not disconnect and be DoSd. -- Jamie Strandboge | http://www.canonical.com
Created attachment 496733 [details] Corrrected previously added patch. Correction by Jamie Strandboge of Ubuntu.
(In reply to comment #7) > There is a typo in the jabberd2 patch I discovered while backporting it > to 2.0s11. The patch has this: > > +#if XML_MAJOR_VERSION > 0 > +/* XML_StopParser is present in expat 2.x */ > +#define HAVE_XML_STOPPARSER > +#endif > + > > So the check and the comment don't go together, and indeed, according to > the changelog, 2.0s11 has expat 1.95.7. This should obviously be changed > to '#if XML_MAJOR_VERSION > 1'. > Reply from Tomasz Sterna of jabberd2 upstream regarding the above: ================================================================== Dnia 2011-05-04, Εro o godzinie 05:13 -0400, Red Hat Security Response Team pisze: > To Tomasz Sterna regarding the small issue with the jabberd2 patch, > Jamie mentioned earlier -- Tomas could you comment if you (jabberd2 > upstream is OK with the updated patch version) and that being the > one intended to be applied by jabberd2 upstream? It's hard to verify, because Expat documentation is non-existant, but assuming the comment that the XML_StopParser() function is present in 2.x release of Expat, I'm going to release the updated patch with: #if XML_MAJOR_VERSION > 1 -- Tomasz Sterna Instant Messaging Consultant : Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/
This is now public with the fixed 2.2.14 version: http://codex.xiaoka.com/svn/jabberd2/tags/jabberd-2.2.14/ChangeLog
Created jabberd tracking bugs for this issue Affects: epel-5 [bug 709794] Affects: epel-6 [bug 709795] Affects: fedora-all [bug 709796]
Created attachment 502318 [details] upstream patch Taken from the upstream svn repository (r937 is the commit to fix the flaw).
Thanks very much for reporting this issue and the great preliminary support! I've updated jabberd to 2.2.14 in Rawhide, F15, F14 and EPEL-6. For F13 and EPEL-5, I backported the fix. Any concerning update can be found here: https://admin.fedoraproject.org/updates/search/CVE-2011-1755 Feel free to test those updates and may also give some karma. :)
Updates are stable in the meanwhile for almost all branches if I see correctly. What's the proper procedure to proceed with this bug? Am I able to close this issue with the stable updates?
Hi, Dominic, thank you for checking with us. (In reply to comment #14) > Updates are stable in the meanwhile for almost all branches if I see correctly. > What's the proper procedure to proceed with this bug? Am I able to close this > issue with the stable updates? This bug will be closed by Red Hat Security Response Team member once the issue has been addressed in all affected products (there is yet one Red Hat specific unfixed one). Once that one has addressed the issue too, we will close this entry. Hope this helps. Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team
This issue affects the versions of the jabberd package, as shipped with Red Hat Network Satellite Server version 5.0.2, 5.1.1, 5.2.1, 5.3.0, and 5.4.0. -- This issue affects the versions of the jabberd package, as shipped with Red Hat Network Proxy Server version 5.0.2, 5.1.1, 5.2.1, 5.3.0, and 5.4.0.
Statement: Vulnerable. This issue has been addressed in Red Hat Network Satellite Server v 5.4.1 via RHSA-2011:0882 https://rhn.redhat.com/errata/RHSA-2011-0882.html and in Red Hat Network Proxy Server v5.4.1 via RHSA-2011:0881 https://rhn.redhat.com/errata/RHSA-2011-0881.html. This issue is not planned to be fixed in Red Hat Network Satellite Server versions 5.0.2, 5.1.1, 5.2.1, 5.3.0 and not planned to be fixed in Red Hat Network Proxy Server versions 5.0.2, 5.1.1, 5.2.1, and 5.3.0.
This issue has been addressed in following products: Red Hat Network Proxy v 5.4 Via RHSA-2011:0881 https://rhn.redhat.com/errata/RHSA-2011-0881.html
This issue has been addressed in following products: Red Hat Network Satellite Server v 5.4 Via RHSA-2011:0882 https://rhn.redhat.com/errata/RHSA-2011-0882.html
Kudos to the Red Hat team and community for their efforts in resolving Bugzilla Issue #700390. To effectively tackle this network configuration bug during installation, detailed information, including reproduction steps, system specs, and logs, is essential. Exploring alternative approaches and encouraging active collaboration between users and developers will contribute to a swift resolution. Grateful for Red Hat's transparent bug tracking system and looking forward to progress on this issue. https://www.laptopicker.com/best-laptop-for-pentesting/