Solaris xlock Information Disclosure

2020.01.19
Credit: Marco Ivaldi
Risk: Low
Local: Yes
Remote: No


CVSS Base Score: 3.6/10
Impact Subscore: 4.9/10
Exploitability Subscore: 3.9/10
Exploit range: Local
Attack complexity: Low
Authentication: No required
Confidentiality impact: Partial
Integrity impact: Partial
Availability impact: None

@Mediaservice.net Security Advisory #2020-01 (last updated on 2020-01-15) Title: Low impact information disclosure via Solaris xlock Application: Setuid root xlock binary distributed with Solaris Platforms: Oracle Solaris 11.x (confirmed on 11.4 X86) Oracle Solaris 10 (confirmed on 10 1/13 X86) OpenIndiana Hipster 2019.10 and earlier Other platforms are potentially affected Description: A low impact information disclosure vulnerability in the setuid root xlock binary distributed with Solaris may allow local users to read partial contents of potentially sensitive files Author: Marco Ivaldi <marco.ivaldi@mediaservice.net> Vendor Status: <secalert_us@oracle.com> notified on 2019-09-24 CVE Name: CVE-2020-2656 CVSS Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N (Base Score: 4.4) References: https://github.com/0xdea/advisories/blob/master/2020-01-solaris-xlock.txt https://www.oracle.com/security-alerts/cpujan2020.html https://www.oracle.com/technetwork/server-storage/solaris11/ https://www.oracle.com/technetwork/server-storage/solaris10/ https://www.openindiana.org/ https://github.com/oracle/solaris-userland/tree/master/components/x11/app/xlock/sun-src https://www.mediaservice.net/ https://0xdeadbeef.info/ 1. Abstract. A low impact information disclosure vulnerability in the setuid root xlock binary distributed with Solaris may allow local users to read partial contents of sensitive files. Due to the fact that target files must be in a very specific format, exploitation of this flaw to escalate privileges in a realistic scenario is unlikely. 2. Example Attack Session. In order to reproduce this bug, the following commands can be used: raptor@stalker:~$ cat /etc/release Oracle Solaris 11.4 X86 Copyright (c) 1983, 2018, Oracle and/or its affiliates. All rights reserved. Assembled 16 August 2018 raptor@stalker:~$ uname -a SunOS stalker 5.11 11.4.0.15.0 i86pc i386 i86pc raptor@stalker:~$ id uid=100(raptor) gid=10(staff) raptor@stalker:~$ tail -1 /etc/passwd user.mode:x:101:10::/export/home/user:/usr/bin/bash raptor@stalker:~$ ln -s /etc/shadow .Xdefaults raptor@stalker:~$ Xorg :1 & raptor@stalker:~$ xlock -name user -display :1 Unknown mode: xlock: bad command line option "$5$rounds=10000$wHWiSUhf$NKjMUwIRiVVB/GYx.HZvnMhou9RUT.qaiJhKg265um7:18160::::::" 3. Discussion. The detected information disclosure happens because xlock does not drop root privileges and follows a malicious symlink to an arbitrary file when opening the ~/.Xdefaults configuration file with the XrmGetFileDatabase() function of libX11. Subsequently, xlock's CheckResources() function prints partial contents of the last line of the file that matches the following pattern (the resource-name string can be specified with the -name command line switch of xlock): [resource-name].mode:[sensitive data] For instance, if a username in the shadow file ends with the string ".mode" (e.g. "user.mode" as shown in the above example) it is possible for a low privileged user to exploit this flaw in order to reveal the corresponding password hash. Similar results can be achieved in case of usernames that end with the following strings: * ".font": the password hash is included in an error message printed by xlock * ".info": the password hash is displayed as part of xlock's unlock dialog * ".validate": the password hash is displayed as part of xlock's unlock dialog Instead of creating a symlink, an attacker could exploit this flaw by directly setting the XFILESEARCHPATH or XUSERFILESEARCHPATH environment variables to point to /etc/shadow. In this case, the password hash associated with usernames that end with the ".display" string can also be recovered. The XAPPLRESDIR environment variable can also be manipulated to achieve similar results. Finally, the directive #include "/etc/shadow" in a configuration file can also be used to trick xlock into opening the /etc/shadow file. Other exploitation vectors may be available. 4. Affected Platforms. This bug was confirmed on the following platforms: * Oracle Solaris 11.x (confirmed on 11.4 X86) * Oracle Solaris 10 (confirmed on 10 1/13 X86) * OpenIndiana Hipster 2019.10 and earlier Other Oracle Solaris versions (including those that run on the SPARC architecture) are also likely affected. 5. Fix. Oracle has assigned the tracking# S1212411 and has released a fix for all affected and supported versions of Solaris in their Critical Patch Update (CPU) of January 2020. Oracle's patch is available in the solaris-userland open source repository on GitHub (see commit "30352568 problem in X11/XCLIENTS"): https://github.com/oracle/solaris-userland/commit/0b48514166d1fedf21c75a2c1af2afe55e087f23 OpenIndiana's patch is available in the oi-userland repository on GitHub (see commit "xlock: Sync with solaris-userland (security) #5421"): https://github.com/OpenIndiana/oi-userland/pull/5421/commits/dd92fe1f71bd25432a3b7559717d23047099437f As a temporary workaround, it is also possible to remove the setuid bit from the xlock executable as follows (note that this might prevent it from working properly): bash-3.2# chmod -s /usr/bin/xlock Copyright (c) 2020 Marco Ivaldi and @Mediaservice.net. All rights reserved.


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2020, cxsecurity.com

 

Back to Top