Bug 644561 (CVE-2010-4000)
| Summary: | CVE-2010-4000 gnome-shell: insecure library loading vulnerability | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Vincent Danen <vdanen> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED UPSTREAM | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | unspecified | CC: | otaylor, security-response-team |
| 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: | 2019-06-10 10:57:21 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: | 644948 | ||
| Bug Blocks: | |||
This issue has been assigned the name CVE-2010-4000. Created gnome-shell tracking bugs for this issue Affects: fedora-all [bug 644948] Was fixed months go upstream, so doesn't affect Rawhide. In my opinion the severity of this is quite low; while empty LD_LIBRARY_PATH element is certainly a problem - what we're really talking about is: - If someone is running the preview version of gnome shell - And launches a terminal within it - And working within a directory that someone else has write access to Then that "attacker" would be able to fool the user into executing arbitrary code, yes. I don't generally expect people to be using gnome-shell previews on systems with multiple untrusted users. Owen, does this mean that F14 has the fix, or would it still be vulnerable? I know GNOME Shell isn't the default in F14, but it's more than just a preview there isn't it? Could you clarify? If it is clearly marked as a preview, then I have no problem ignoring this. If not, then we should correct it, but I wouldn't do an update for it alone (i.e. if GNOME Shell gets updated for some other reason, we could/should include the fix). (In reply to comment #4) > Owen, does this mean that F14 has the fix, or would it still be vulnerable? > > I know GNOME Shell isn't the default in F14, but it's more than just a preview > there isn't it? Could you clarify? If it is clearly marked as a preview, then > I have no problem ignoring this. > > If not, then we should correct it, but I wouldn't do an update for it alone > (i.e. if GNOME Shell gets updated for some other reason, we could/should > include the fix). GNOME Shell in Fedora 14 is a snapshot from July 12 (so including this bug.) Unfortunately, changes to underlying libraries since that point have made it impossible to update Fedora 14 to a newer version, so it's pretty much frozen in time. Any updates would essentially be patches against that old version. (I'm just ignoring ABRT reported crashers, for example.) I don't know if we explicitly described the gnome-shell version in Fedora 14 as a preview, but it wasn't in the default package set, and it's not very usable. I think most people that committed enough to tracking the bleeding edge of GNOME and Fedora will have upgraded to rawhide by now. Fair enough. This is pretty low impact. If you do update GNOME Shell in F14, can you include the fix for this? It's pretty minor and straightforward, so there should be no regressions. Certainly don't go and push an update for this alone. But if one does happen, including this would be great. Of course, if there are no plans to update GNOME Shell in F14 at all, feel free to close it. 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. |
Ludwig Nussel discovered that gnome-shell 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/gnome-shell re-sets LD_LIBRARY_PATH insecurely: 163 if os.path.exists(mozjs_libdir + '/libmozjs.so'): 164 env['LD_LIBRARY_PATH'] = os.environ.get('LD_LIBRARY_PATH', '') + ':' + mozjs_libdir ... 206 return subprocess.Popen(args, env=env) A solution is to patch the script to test if LD_LIBRARY_PATH is previously set: if os.environ.get('LD_LIBRARY_PATH'): env['LD_LIBRARY_PATH'] = os.environ.get('LD_LIBRARY_PATH', '') + ':' + mozjs_libdir else: env['LD_LIBRARY_PATH'] = mozjs_libdir