Bug 638365 (CVE-2010-3349)
| Summary: | CVE-2010-3349 ardour: insecure library loading vulnerability | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Vincent Danen <vdanen> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED UPSTREAM | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | unspecified | CC: | green, hdegoede, oget.fedora |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-06-10 10:57:16 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 638367 | ||
| Bug Blocks: | |||
Created ardour tracking bugs for this issue Affects: fedora-all [bug 638367] thanks for the report. Let me understand the issue better. When $LD_LIBRARY_PATH is empty, the line export LD_LIBRARY_PATH=/usr/lib/ardour2:$LD_LIBRARY_PATH becomes just export LD_LIBRARY_PATH=/usr/lib/ardour2: This means that the current working directory is added to LD_LIBRARY_PATH. An attacker places a malicious library where the user is likely to execute /usr/bin/ardour2 and then boom! Is this correct? Yes, that is exactly correct. With that colon at the end there, ld.so essentially treats it as "/usr/lib/ardour2:.". I contacted upstream about this. On the other hand, having a second thought, this sounds rather like a bug in ld to me. Any ideas why an empty item is treated as a dot '.' as opposed to null? This one-liner should work as an alternative to if-else-fi fix:
export LD_LIBRARY_PATH=/usr/lib/foo${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
(In reply to comment #4) > I contacted upstream about this. On the other hand, having a second thought, > this sounds rather like a bug in ld to me. > > Any ideas why an empty item is treated as a dot '.' as opposed to null? I don't know if it's necessarily a bug or expected behaviour, however there is some discussion about whether or not to change it: http://www.openwall.com/lists/oss-security/2010/09/29/1 In the meantime, correcting this would be ideal as I think we would want to follow upstream on this, and they would need to weigh in on the discussion. This CVE Bugzilla entry is for community support informational purposes only as it does not affect a package in a commercially supported Red Hat product. Refer to the dependent bugs for status of those individual community products. |
Raphael Geissert conducted a review of various packages in Debian and found that ardour contained a script that could be abused by an attacker to execute arbitrary code [1]. The vulnerability is due to an insecure change to LD_LIBRARY_PATH, 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 LD_LIBRARY_PATH, 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. In Fedora, /usr/bin/ardour2 is replaced with a custom script that then calls /usr/libexec/ardour2. This script re-sets LD_LIBRARY_PATH insecurely: export LD_LIBRARY_PATH=/usr/lib/ardour2:$LD_LIBRARY_PATH A solution is to patch the script to test if $LD_LIBRARY_PATH is set first before attempting to modify it: if [ -z ${LD_LIBRARY_PATH} ]; then export LD_LIBRARY_PATH=/usr/lib/foo else export LD_LIBRARY_PATH=/usr/lib/foo:${LD_LIBRARY_PATH} fi This issue has been assigned the name CVE-2010-3349. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598283