Bug 638365 (CVE-2010-3349) - CVE-2010-3349 ardour: insecure library loading vulnerability
Summary: CVE-2010-3349 ardour: insecure library loading vulnerability
Alias: CVE-2010-3349
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 638367
TreeView+ depends on / blocked
Reported: 2010-09-28 21:06 UTC by Vincent Danen
Modified: 2019-09-29 12:39 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2019-06-10 10:57:16 UTC

Attachments (Terms of Use)

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
    export LD_LIBRARY_PATH=/usr/lib/foo:${LD_LIBRARY_PATH}

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:

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:


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.

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