Bug 638365 (CVE-2010-3349)

Summary: CVE-2010-3349 ardour: insecure library loading vulnerability
Product: [Other] Security Response Reporter: Vincent Danen <vdanen>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED UPSTREAM QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: 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:
Bug Depends On: 638367    
Bug Blocks:    

Description Vincent Danen 2010-09-28 21:06:07 UTC
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

Comment 1 Vincent Danen 2010-09-28 21:07:55 UTC
Created ardour tracking bugs for this issue

Affects: fedora-all [bug 638367]

Comment 2 Orcan Ogetbil 2010-09-28 21:38:41 UTC
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?

Comment 3 Vincent Danen 2010-09-28 21:53:52 UTC
Yes, that is exactly correct.  With that colon at the end there, ld.so essentially treats it as "/usr/lib/ardour2:.".

Comment 4 Orcan Ogetbil 2010-09-29 05:41:58 UTC
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?

Comment 5 Tomas Hoger 2010-09-29 07:42:42 UTC
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}

Comment 6 Vincent Danen 2010-09-29 17:00:39 UTC
(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.

Comment 7 Product Security DevOps Team 2019-06-10 10:57:16 UTC
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.