Bug 638376 (CVE-2010-3351)
| Summary: | CVE-2010-3351 bristol: insecure library loading vulnerability | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Vincent Danen <vdanen> |
| Component: | vulnerability | Assignee: | Nobody <nobody> |
| Status: | ASSIGNED --- | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | unspecified | CC: | gwync |
| 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: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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}
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. (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 Whoops. Thanks. I see no reason not to just drop the setting of LD_LIBRARY_PATH entirely. I tried that, and bristol still works. |
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