Bug 644933 (CVE-2010-3999)
| Summary: | CVE-2010-3999 gnucash: insecure library loading vulnerability | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Vincent Danen <vdanen> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | unspecified | CC: | info, notting, vkrizan |
| 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: | 2010-12-22 15:41:54 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 644934 | ||
| Bug Blocks: | |||
Created gnucash tracking bugs for this issue Affects: fedora-all [bug 644934] Affects: fedora-all [bug 644934] Fixed in Fedora 13 and 14, and EPEL 4 and 5. I don't seem to remember any notice on the usual gnucash channels (bugzilla, mailing lists,...) regarding this issue. I have just stumbled upon this one here by accident. Just for your reference, I have committed a fix to the upstream gnucash source that will skip the unsafe file from installation altogether. As you say, it's only used by developers and packagers for running tests. I'm assuming this is the upstream fix? http://svn.gnucash.org/trac/changeset?old_path=%2Fgnucash%2Ftrunk&old=21552&new_path=%2Fgnucash%2Ftrunk&new=21553 Yes, that's the one. Perfect, thank you for the confirmation. |
Ludwig Nussel discovered that gnucash contained a script that could be abused by an attacker to execute arbitrary code. 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/gnc-test-env re-sets LD_LIBRARY_PATH insecurely: 106 (display 107 (adapt-dirsep 108 (get-dir-adder "LD_LIBRARY_PATH" library-dirs "/.libs" path-sep-str))) which could result in something like this if called with, say, --library-dir /foo: LD_LIBRARY_PATH="/foo/.libs:${LD_LIBRARY_PATH}" export LD_LIBRARY_PATH; I'm not sure what the best solution here to fix this flaw is, however it looks as though gnc-test-env is only required for building gnucash, so it should probably be removed from the RPM package (it isn't something an end-user would be running normally).