Bug 638365 - (CVE-2010-3349) CVE-2010-3349 ardour: insecure library loading vulnerability
CVE-2010-3349 ardour: insecure library loading vulnerability
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
public=20100928,reported=20100914,sou...
: Security
Depends On: 638367
Blocks:
  Show dependency treegraph
 
Reported: 2010-09-28 17:06 EDT by Vincent Danen
Modified: 2015-08-19 04:55 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2010-09-28 17:06:07 EDT
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 17:07:55 EDT
Created ardour tracking bugs for this issue

Affects: fedora-all [bug 638367]
Comment 2 Orcan Ogetbil 2010-09-28 17:38:41 EDT
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 17:53:52 EDT
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 01:41:58 EDT
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 03:42:42 EDT
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 13:00:39 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.