|Summary:||CVE-2007-5495 setroubleshoot insecure logging|
|Product:||[Other] Security Response||Reporter:||Mark J. Cox <mjc>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||unspecified||CC:||dwalsh, jdennis, kreilly, sgrubb|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-05-29 07:52:44 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||421791|
Description Mark J. Cox 2007-09-12 18:48:53 UTC
reported via secalert By default, the sealert program writes diagnostic messages to the file /tmp/sealert.log. It does not check to ensure that this file does not already exist, or that it is not a symbolic link. An unprivileged local attacker can exploit this flaw to cause arbitrary files writable by other users to be overwritten when those users run sealert. The sealert program is run automatically, without user action, as part of the default RHEL 5 GNOME desktop session. It does not appear to be possible for the attacker to cause arbitrary data to be written to sealert.log, but the previous contents of the file are erased.'
Comment 1 John Dennis 2007-09-13 16:47:20 UTC
This is already addressed in the current upstream, the file is no longer created.
Comment 2 Steve Grubb 2007-09-13 19:02:43 UTC
What about RHEL5.1's version?
Comment 3 John Dennis 2007-09-14 22:35:46 UTC
The RHEL 5.1 version is the same as 5.0. It would be trival to patch RHEL to turn off creation of this log file. The only way for security sensitive information to be written to the file would be if the verbose debug logging was turned on, but that requires root privledge to modify the configuration. Tracebacks due to program exceptions which might be written to the file do not contain user data.
Comment 7 Mark J. Cox 2008-05-21 14:17:39 UTC
Comment 8 Tomas Hoger 2008-05-25 18:33:57 UTC
John, can you please clarify which upstream setroubleshoot version first fixed this flaw? I see /tmp/sealert.log defined in config.py in 1.8.11 and is no longer set in 1.9.4, but I fail to find versions in between to check which version was the first to include this change.
Comment 9 John Dennis 2008-05-27 15:20:49 UTC
No, I don't recall the exact version this first appeared in. If it's important I could research it.
Comment 10 Tomas Hoger 2008-05-27 16:03:08 UTC
Probably not if you agree with the assessment that fix occurred somewhere in between 1.8.11 and 1.9.4, so that I managed to identify the right change that was used to resolve this issue. Is there any place where all previous upstream versions can be found?