Bug 719698 (CVE-2011-2516)

This issue affects the versions of the xml-security-c package, as shipped with Fedora release of 14 and 15.

--

This issue affects the versions of the xml-security-c package, as present within EPEL-5 and EPEL-6 repositories. Please schedule and update.

Created attachment 511759 [details]
Local copy of buff_overflow.cpp from [3]

Created attachment 511760 [details]
Local copy of reproducer.tar.gz from [3]

Created xml-security-c tracking bugs for this issue

Affects: epel-all [bug 719701]
Affects: fedora-all [bug 719702]

To make the reproducer in attachment 511760 [details] compile in Fedora 15, modify the Makefile:

-LIBS = lxerces-c -lxml-security-c
+LIBS = lxerces-c -lxml-security-c -lcrypto

I've backported the patch to 1.5.1 and 1.6.0 and pushed the changes
to appropriate branches.

However the reproducer produces loads of errors under valgrind, even with 1.6.1. Can someone please verify if the patch actually does anything.

http://koji.fedoraproject.org/koji/taskinfo?taskID=3186240
http://koji.fedoraproject.org/koji/taskinfo?taskID=3186244
http://koji.fedoraproject.org/koji/taskinfo?taskID=3186248
http://koji.fedoraproject.org/koji/taskinfo?taskID=3186259

Hi Antti,

  thank you for your work on these.

(In reply to comment #6)
> I've backported the patch to 1.5.1 and 1.6.0 and pushed the changes
> to appropriate branches.
> 
> However the reproducer produces loads of errors under valgrind, even with
> 1.6.1. Can someone please verify if the patch actually does anything.

When simplified what the patch does is to double the space for "outputStr[MAXB64BUFSIZE]" buffer (from 1024 to 2048 bits). This may not be
viewed as a complete solution (proper way how to address this issue). But the
reasons, why this patch is changing the behaviour in that way are at:
[1] https://issues.apache.org/jira/secure/ViewProfile.jspa?name=pzanoni
[2] https://issues.apache.org/jira/secure/ViewProfile.jspa?name=cantor.2%40osu.edu
[3] https://issues.apache.org/jira/secure/ViewProfile.jspa?name=cantor.2%40osu.edu

and mainly:
[4] https://issues.apache.org/jira/secure/ViewProfile.jspa?name=cantor.2%40osu.edu

Interesting bits from [4]:
Verification should work with any key sizes. Signing uses a buffer that's double the current size (should handle enormous/impractical keys), and detects when the result is too large to handle and fails instead of crashing. We can change the API in the future to improve this.

So I would say what the current patch is doing is:
1) fixing the verification scenario,
2) doubling the buffer size for signing case. Larger (8192 and more) bits
   RSA keys will still report an error. Processing of them shouldn't
   crash, but valgrind may still print error messages for those. Since there
   is limitation in the API, this can't be (for now without XMLSig v2.0 being
   present) fixed better.

Hope this helps, Jan.

> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=3186240
> http://koji.fedoraproject.org/koji/taskinfo?taskID=3186244
> http://koji.fedoraproject.org/koji/taskinfo?taskID=3186248
> http://koji.fedoraproject.org/koji/taskinfo?taskID=3186259

Ouch, looks like the links in [1] up to [4] aren't doing what I originally
intended. Provided are the corrected ones:

[1] https://issues.apache.org/jira/browse/SANTUARIO-271?focusedCommentId=13032512&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13032512

[2] https://issues.apache.org/jira/browse/SANTUARIO-271?focusedCommentId=13032552&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13032552

[3] https://issues.apache.org/jira/browse/SANTUARIO-271?focusedCommentId=13036123&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13036123

and mainly:

[4] https://issues.apache.org/jira/browse/SANTUARIO-271?focusedCommentId=13037430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13037430

Thanx Jan.

Unfortunately I have been unable to reproduce the strcpy memory error reported in https://issues.apache.org/jira/browse/SANTUARIO-271 thus I have simply followed the upstream advice and backported the patch to 1.6.0 and 1.5.1. The devel branch has been updated to 1.6.1 by Steve Traylen.

The updates for EL4-6 and F14-15 have been pushed to bodhi, feel free to give negative karma if the backported patch breaks anything:

https://admin.fedoraproject.org/updates/search/CVE-2011-2516

Thanx for help.

Closing bug because fixed packages have been pushed to stable repositories for all supported distros (el4, el5, el6, fc14, fc15).

This is fixed for fedora, but does not seem to be fixed for el*, We dont use bodhi for el* :)

Fedora EPEL *does* use bodhi. At least fixed xml-security-c packages are available from EPEL repository:

http://download.fedora.redhat.com/pub/epel/4/x86_64/repoview/xml-security-c.html

AFAIK xml-security-c is not part of official RHEL.
(At least the sources are not available from ftp.redhat.com).

If I'm wrong please reopen and assign to whoever is resposible for pushing EPEL updates to RHEL. Thank you.

I think there was some confusion as we usually refer to EPEL for RHEL4 as EPEL4 rather then el4.  We do not have xml-security-c in RHEL.

However, this bug wasn't assigned to you either, it was assigned to the SRT.  Please do not close our bugs (feel free to close the trackers that are assigned to you).  Thanks.