Bug 638376 (CVE-2010-3351) - CVE-2010-3351 bristol: insecure library loading vulnerability
Summary: CVE-2010-3351 bristol: insecure library loading vulnerability
Status: ASSIGNED
Alias: CVE-2010-3351
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: public=20100928,reported=20100914,sou...
Keywords: Security
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-09-28 21:30 UTC by Vincent Danen
Modified: 2019-06-08 13:06 UTC (History)
1 user (show)

(edit)
Clone Of:
(edit)
Last Closed:


Attachments (Terms of Use)

Description Vincent Danen 2010-09-28 21:30:49 UTC
Raphael Geissert conducted a review of various packages in Debian and found that bristol 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/startBristol re-sets LD_LIBRARY_PATH insecurely:

declare -x LD_LIBRARY_PATH=/usr/lib:/usr/local/lib:${LD_LIBRARY_PATH}:${BRISTOL}/lib

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-3351.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598285

Comment 1 Tomas Hoger 2010-09-29 07:43:04 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 2 Gwyn Ciesla 2010-09-29 15:06:31 UTC
Please verify the patch I just commited to rawhide git.  If that looks good, I'll built that and backport the patch to the stable releases.


My local build works.

Comment 3 Tomas Hoger 2010-09-29 15:39:27 UTC
(In reply to comment #2)
> Please verify the patch I just commited to rawhide git.  If that looks good,
> I'll built that and backport the patch to the stable releases.

The fix is not correct, actually harmful, as it adds empty path to LD_LIBRARY_PATH even when it was previously non-empty.

It should be:

LD_LIBRARY_PATH=/usr/lib:/usr/local/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}:${BRISTOL}/lib

instead of:

LD_LIBRARY_PATH=/usr/lib:/usr/local/lib:${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}:${BRISTOL}/lib

(note : before ${LD_LIBRARY_PATH:+:...)

Is there a reason to keep other directories in the list?  /usr/lib is searched by default, /usr/local/lib should not contain anything Fedora package should need.  ${BRISTOL}/lib is /usr/share/bristol/lib, which is not created by bristol rpm.

This should work if you prefer to keep ${BRISTOL}/lib:

LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}${BRISTOL}/lib

Comment 4 Gwyn Ciesla 2010-09-29 16:02:27 UTC
Whoops.  Thanks.

I see no reason not to just drop the setting of LD_LIBRARY_PATH entirely.  I tried that, and bristol still works.


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