Multiple use-after-free vulnerabilities in libxml2 2.5.10, 2.6.16, 2.6.26, 2.6.27, and 2.6.32, and libxml 1.8.17, allow context-dependent attackers to cause a denial of service (application crash) via crafted (1) Notation or (2) Enumeration attribute types in an XML file, as demonstrated by the Codenomicon XML fuzzing framework.

libxml2 before 2.7.8, as used in Google Chrome before 7.0.517.44, Apple Safari 5.0.2 and earlier, and other products, reads from invalid memory locations during processing of malformed XPath expressions, which allows context-dependent attackers to cause a denial of service (application crash) via a crafted XML document.

Dmitri Gribenko discovered that the soffice script in the Openoffice.org package contained an insecure setting for the LDLIBRARYPATH, which could be abused by an attacker to execute arbitrary code.

The vulnerability is due to an insecure change to LDLIBRARYPATH, and environment variable used by ld.so(8) to look for libraries in directories other than the standard paths. When there is an empty item in the colon-separated list of directories in LDLIBRARYPATH, ld.so(8) treats it as a '.' (current working directory). If the given script is executed from a directory where a local attacker could write files, there is a chance for exploitation.

Currently in our soffice script we do...

LDLIBRARYPATH=$mypath${LDLIBRARYPATH+:$LDLIBRARYPATH}

while we should do...

LDLIBRARYPATH=$mypath${LDLIBRARYPATH:+:$LDLIBRARYPATH}

so if someone currently does export LDLIBRARYPATH= then our LDLIBRARYPATH ends up as LDLIBRARYPATH=/path: which has an empty entry which effectively means LDLIBRARYPATH=/path:.

Acknowledgements:

Red Hat would like to thank Dmitri Gribenko for reporting this issue.