We need to track this security issue.
Red Hat has provided these details: We have received following report of the vulnerability affecting Xorg and XFree86 X servers. - --- snip --- I have found a small vulnerability on Xorg (tested on xorg-x11-server-Xorg version 1.1.1-48.13.el5) that can be exploited by a malicious user to disclose the existence of files in directories not accessible by the user. By looking at the error messages returned when supplying an arbitrary file or directory in the "X :1 -sp <file>" command, a malicious user can identify the existence of files and directories in access restricted directories. If the user receives a "error opening security policy file <file>" the file/directory is not present on the system. However, if a "<file>: invalid security policy file version, ignoring file" error message is returned, the file/directory is present on the system. - --- snip --- Reporter prefers to remain anonymous. We have assigned CVE id CVE-2007-5958 to this issue. Impact seems to be limited to disclosure of file existence in some directory, which is not accessible to the attacker. We are not currently aware of any more severe impact or the way to turn this to more complete exploit. This issue affects all X server versions we ship back to XFree86 4.1.0.
This should not be an issue in git master branch since Eamon Walsh's last merge of XACE/SELinux changes, which removed the SecurityPolicy file and the -sp flag (commit 8b5d21cc1d1f4e9d20e5d5eca44cb1e60a419763) - we still need to fix 1.4.1 though for X.Org, and have patches for vendors who support earlier releases.
Created attachment 13291 [details] [review] proposed patch We already have the Fopen() function in the X server which releases X privileges before opening a file. Considering that SecurityPolicy is publically readable on most systems, usiing Fopen() instead of fopen() is probably enough. I've tried other files that can be specified by the user on the command line without beeing able to find the same kind of issues (ie the error message doesn't leak any information if the specified file is in a directory that's not readable by a regular user.
The patch should probably change fclose() to Fclose(), for non-saved-setuid systems (i.e. not Linux, BSD, Solaris or other SVR4) - for those with saved setuid, Fclose just calls fclose() so it doesn't matter.
Yes you're right.
Created attachment 13299 [details] [review] Updated patch Matthieu's patch + fclose -> Fclose change
XFree86 4.2 doesn't know about Fclose/Fopen yet. So the solution would be to add the missing functions to os/utils.c?
(In reply to comment #7) > XFree86 4.2 doesn't know about Fclose/Fopen yet. So the solution would be to > add the missing functions to os/utils.c? > That's one solution. Another one is to change the way errors are reported when reading the SecurityPolicy file so that it doesn't provide any information on why it failed if the effective uid is different from the real uid.
Thanks. Luckily adding Fopen()/Fclose() on Linux is rather easy. :-)
Patch has been committed to server-1.4-branch: 19b95cdd1d14a1e7d1abba1880ab023c96f19bf5 and this is now public.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.