* We have been asked to treat this as a CONFIDENTIAL issue until
* upstream releases a fix package. Please do not share any information
* from within this bug, until the Security team makes this bug public.
* Thank you.
From the inbound email:
We've been notified by xmlsec upstream about the issue in xmlsec
reported by Nicolas Grégoire that causes xmlsec to create or overwrite
arbitrary file when trying to verify signature of the XML file. This
happens when XML includes XSLT transform using output extension (xmlsec
must have XSLT support enabled, which is default), file name and
content is chosen by the XML file author.
Upstream git has the fix already:
Issue should be considered public only once new upstream xmlsec version
is released later this week.
Aleksey and Nicolas pointed out few possible mitigations that programs
using xmlsec library can use:
- disable XSLT transform it no used in struct xmlSecTransformCtx
- explicitly call xsltNewSecurityPrefs() and forbid any access
Hi, Daniel and Dane.
Given the short time line before this is planned to go public, it would be fantastic if we could either:
- Create an ebuild for 1.2.16-r1 including a patch based on the commit at $URL, or
- Create an ebuild for 1.2.17, that we can test after it is released.
If you are able to do this before this issue is made public, please attach the ebuild to this bug *without* committing to CVS. Thank you.
This now public.
Tested on x86, looks good over here.
x86 stable. Thanks Andreas.
amd64 done, thanks Agostino
Thanks, folks. GLSA request filed.
security: Any reason to keep this open?
xslt.c in XML Security Library (aka xmlsec) before 1.2.17, as used in WebKit
and other products, when XSLT is enabled, allows remote attackers to create
or overwrite arbitrary files via vectors involving the libxslt output
extension and a ds:Transform element during signature verification.
This issue was resolved and addressed in
GLSA 201412-09 at http://security.gentoo.org/glsa/glsa-201412-09.xml
by GLSA coordinator Sean Amoss (ackle).