Stack-based buffer overflow flaws were found in the way xml-security-c, a C++ implementation of the XML Digital Signature specification, performed creation and verification of XML Signatures, when large RSA keys (length >= 8192) were used. A remote attacker, using sufficiently long RSA key, could use this flaw to cause an application linked against the xml-security-c library to crash (denial of service), or, potentially, it to execute arbitrary code with the privileges of the user running the application.
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 
Created attachment 511760 [details]
Local copy of reproducer.tar.gz from 
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.
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:
Interesting bits from :
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.
Ouch, looks like the links in  up to  aren't doing what I originally
intended. Provided are the corrected ones:
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:
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:
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.