CVE-2010-3689: Path Traversal
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.
Other sources
soffice in OpenOffice.org (OOo) 3.x before 3.3 places a zero-length directory name in the LDLIBRARYPATH, which allows local users to gain privileges via a Trojan horse shared library in the current working directory.
Affected Software
Event History
Frequently Asked Questions
What is the severity of CVE-2010-3689?
CVE-2010-3689 is classified as a high severity vulnerability due to the potential for arbitrary code execution.
How do I fix CVE-2010-3689?
To fix CVE-2010-3689, update OpenOffice.org to a version that corrects the insecure LD_LIBRARY_PATH setting.
What systems are affected by CVE-2010-3689?
CVE-2010-3689 affects multiple versions of OpenOffice.org as well as Debian and Ubuntu Linux distributions.
Can CVE-2010-3689 be exploited remotely?
CVE-2010-3689 requires local access to exploit the vulnerability, making it less likely to be exploited remotely.
Is there a workaround for CVE-2010-3689?
A potential workaround for CVE-2010-3689 is to manually adjust the LD_LIBRARY_PATH variable or restrict access to the soffice script until an update is applied.