[prev in list] [next in list] [prev in thread] [next in thread]
List: oss-security
Subject: [oss-security] CVE-2020-2771, CVE-2020-2851, CVE-2020-2944 - Multiple vulnerabilities in Oracle Sola
From: Marco Ivaldi <marco.ivaldi () mediaservice ! net>
Date: 2020-04-15 14:42:34
Message-ID: 1CB288AE-6F16-46CD-9E4A-B0CAA8EEA58D () mediaservice ! net
[Download RAW message or body]
[Attachment #2 (text/plain)]
Hello,
Please find attached 3 recent advisories for the following vulnerabilities, fixed in \
Oracle's Critical Patch Update (CPU) of April 2020:
CVE-2020-2771. A difficult to exploit heap-based buffer overflow in setuid root whodo \
and w binaries distributed with Solaris allows local users to corrupt memory and \
potentially execute arbitrary code in order to escalate privileges.
CVE-2020-2851. A difficult to exploit stack-based buffer overflow in the \
_DtCreateDtDirs() function in the Common Desktop Environment version distributed with \
Oracle Solaris 10 1/13 (Update 11) and earlier may allow local users to corrupt \
memory and potentially execute arbitrary code in order to escalate privileges via a \
long X11 display name. The vulnerable function is located in the libDtSvc library and \
can be reached by executing the setuid program dtsession.
CVE-2020-2944. A buffer overflow in the _SanityCheck() function in the Common Desktop \
Environment version distributed with Oracle Solaris 10 1/13 (Update 11) and earlier \
allows local users to gain root privileges via a long calendar name or calendar owner \
passed to sdtcm_convert in a malicious calendar file.
For further details and some background information, please refer to:
https://techblog.mediaservice.net/2020/04/cve-2020-2944-local-privilege-escalation-via-cde-sdtcm_convert/
https://github.com/0xdea/exploits/blob/master/solaris/raptor_sdtcm_conv.c
https://0xdeadbeef.info/
PS. It looks like Bugtraq is not accepting posts anymore: it finally happened, the \
end of an era...
--
Marco Ivaldi, Offensive Security Manager
CISSP, OSCP, QSA, ASV, OPSA, OPST, OWSE, LA27001, PRINCE2F
@Mediaservice.net S.r.l. con Socio Unico
https://www.mediaservice.net/
["2020-05-cde-sdtcm_convert.txt" (text/plain)]
@Mediaservice.net Security Advisory #2020-05 (last updated on 2020-04-15)
Title: Local privilege escalation via CDE sdtcm_convert
Application: Common Desktop Environment 1.6 and earlier
Platforms: Oracle Solaris 10 1/13 (Update 11) and earlier
Other platforms are potentially affected (see below)
Description: A local attacker can gain root privileges by exploiting a
buffer overflow in CDE sdtcm_convert
Author: Marco Ivaldi <marco.ivaldi@mediaservice.net>
Vendor Status: Oracle <secalert_us@oracle.com> notified on 2019-12-08
CERT/CC notified on 2019-12-09 (tracking VU#308289)
CVE Name: CVE-2020-2944
CVSS Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H (Base Score: 8.8)
References: https://github.com/0xdea/advisories/blob/master/2020-05-cde-sdtcm_convert.txt
https://www.oracle.com/security-alerts/cpuapr2020.html
https://www.oracle.com/technetwork/server-storage/solaris10/
https://www.mediaservice.net/
https://0xdeadbeef.info/
1. Abstract.
A buffer overflow in the _SanityCheck() function in the Common Desktop
Environment version distributed with Oracle Solaris 10 1/13 (Update 11) and
earlier allows local users to gain root privileges via a long calendar name or
calendar owner passed to sdtcm_convert in a malicious calendar file.
The open source version of CDE (based on the CDE 2.x codebase) is not affected,
because it does not ship the vulnerable program.
2. Example Attack Session.
bash-3.2$ cat /etc/release
Oracle Solaris 10 1/13 s10x_u11wos_24a X86
Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights reserved.
Assembled 17 January 2013
bash-3.2$ uname -a
SunOS nostalgia 5.10 Generic_147148-26 i86pc i386 i86pc
bash-3.2$ id
uid=54322(raptor) gid=1(other)
bash-3.2$ gcc raptor_sdtcm_conv.c -o raptor_sdtcm_conv -Wall
bash-3.2$ ./raptor_sdtcm_conv
raptor_sdtcm_conv.c - CDE sdtcm_convert LPE for Solaris/Intel
Copyright (c) 2019-2020 Marco Ivaldi <raptor@0xdeadbeef.info>
Using SI_PLATFORM : i86pc (5.10)
Using SI_HOSTNAME : nostalgia
Using stack base : 0x8047fff
Using rwx_mem address : 0xfeffa004
Using payload address : 0x8047dff
Using strcpy() address : 0xfefe26a0
Preparing the evil calendar file... Done.
Exploiting... Please answer "n" when prompted.
Loading the calendar ...
[...]
Do you want to correct it? (Y/N) [Y] n
# id
uid=0(root) gid=1(other) egid=12(daemon)
3. Affected Platforms.
All platforms shipping the Common Desktop Environment based on the CDE 1.x
codebase are potentially affected. This includes:
* Oracle Solaris 10 1/13 (Update 11) and earlier [default installation]
The open source version of CDE (based on the CDE 2.x codebase) is not affected,
because it does not ship the vulnerable program.
4. Fix.
Oracle has assigned the tracking# S1239395 and has released a fix for all
affected and supported versions of Solaris in the Critical Patch Update (CPU)
of April 2020.
As a workaround, it is also possible to remove the setuid bit from the
vulnerable executable as follows (note that this might prevent it from working
properly):
bash-3.2# chmod -s /usr/dt/bin/sdtcm_convert
Please note that during the audit many other potentially exploitable bugs have
surfaced in sdtcm_convert and in the Common Desktop Environment in general.
Therefore, removing the setuid bit from all CDE binaries is recommended,
regardless of patches released by vendors.
5. Proof of Concept.
An exploit for Oracle Solaris 10 1/13 (Update 11) Intel has been developed as a
proof of concept. It can be downloaded from:
https://github.com/0xdea/exploits/blob/master/solaris/raptor_sdtcm_conv.c
Copyright (c) 2020 Marco Ivaldi and @Mediaservice.net. All rights reserved.
["2020-06-cde-libDtSvc.txt" (text/plain)]
@Mediaservice.net Security Advisory #2020-06 (last updated on 2020-04-15)
Title: Stack-based buffer overflow in CDE libDtSvc
Application: Common Desktop Environment 2.3.1 and earlier
Common Desktop Environment 1.6 and earlier2020-06-cde-libDtSvc.txt
Platforms: Oracle Solaris 10 1/13 (Update 11) and earlier
Other platforms are potentially affected (see below)
Description: A difficult to exploit stack-based buffer overflow in the
libDtSvc library distributed with CDE may allow local users to
corrupt memory and potentially execute aritrary code in order
to escalate privileges
Author: Marco Ivaldi <marco.ivaldi@mediaservice.net>
Vendor Status: Oracle <secalert_us@oracle.com> notified on 2019-12-15
CERT/CC notified on 2019-12-15 (tracking VU#308289)
CVE Name: CVE-2020-2851
CVSS Vector: CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H (Base Score: 7.8)
References: https://github.com/0xdea/advisories/blob/master/2020-06-cde-libDtSvc.txt
https://www.oracle.com/security-alerts/cpuapr2020.html
https://sourceforge.net/p/cdesktopenv/wiki/Home/
https://www.oracle.com/technetwork/server-storage/solaris10/
https://www.mediaservice.net/
https://0xdeadbeef.info/
1. Abstract.
A difficult to exploit stack-based buffer overflow in the _DtCreateDtDirs()
function in the Common Desktop Environment version distributed with Oracle
Solaris 10 1/13 (Update 11) and earlier may allow local users to corrupt memory
and potentially execute arbitrary code in order to escalate privileges via a
long X11 display name. The vulnerable function is located in the libDtSvc
library and can be reached by executing the setuid program dtsession.
Note that Oracle Solaris CDE is based on the original CDE 1.x train, which is
different from the CDE 2.x codebase that was later open sourced. In detail, the
open source CDE is not affected by this specific vulnerability, but following
our report some additional work has been done by its maintainers to properly
check bounds in the libDtSvc library. Most notably, insecure calls to strncat()
that caused buffer overflows have been fixed.
2. Example Attack Session.
In order to reproduce this bug, the following commands can be used:
bash-3.2$ cat /etc/release
Oracle Solaris 10 1/13 s10x_u11wos_24a X86
Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights reserved.
Assembled 17 January 2013
bash-3.2$ uname -a
SunOS nostalgia 5.10 Generic_147148-26 i86pc i386 i86pc
bash-3.2$ id
uid=54322(raptor) gid=1(other)
bash-3.2$ grep 10.0.0.24 /etc/hosts
10.0.0.24 aaaa:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
[activate a valid display on 10.0.0.24:0]
/usr/dt/bin/dtsession -display \
aaaa:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa:0
Segmentation Fault
3. Discussion.
The overflow occurs in the following code snippet of Oracle Solaris CDE (the
Ghidra decompiler is probably doing something wrong as some variables seem to
overlap, however its output is good enough for the purpose of this discussion):
char * _DtCreateDtDirs(int param_1)
{
...
char local_f0 [104];
char local_88 [112];
char *heap_path2;
char *tmp_ptr1;
char *home;
undefined *local_c;
undefined local_8 [4];
...
if (param_1 != 0) {
strcpy(local_f0,*(char **)(param_1 + 0x80));
strcpy(local_88,*(char **)(param_1 + 0x80));
...
}
An X11 display data structure is passed to the _DtCreateDtDirs() function as
its only parameter (param_1 in the pseudocode above). It contains the X11
display name at offset 0x80. This display name is copied into the stack buffers
local_f0 and local_88 using the insecure function strcpy() twice, therefore two
overflows occur.
Based on the inferred stack layout, the following local variables are
overflowed into before the saved return address can be reached:
heap_path2
tmp_ptr1
home
local_c
local_8
This complicates exploitation, in particular because the heap_path2 and
tmp_ptr1 pointers get in the way. A skilled attacker might be able to overwrite
all variables with safe data and leverage memory corruption to obtain arbitrary
code execution. However, there is an additional challenge: the ability to
control a hostname to be passed in the X11 display name string. In our PoC
above we have edited /etc/hosts, but this is obviously not possible for an
unprivileged local attacker. A DNS server under the control of the attacker may
be used for this purpose, but such an approach would introduce a number of
additional complications.
That said, as a rule of thumb all memory corruption issues have the potential
to become serious security vulnerabilities until otherwise proven. Therefore,
we recommend to treat this bug as a potential security vulnerability and to fix
it as such.
4. Affected Platforms.
All platforms shipping the Common Desktop Environment are potentially affected.
This includes:
* Oracle Solaris 10 1/13 (Update 11) and earlier [default installation]
According to the CDE Wiki, the following platforms are officially supported:
* All Official Ubuntu variants 12.04 - 18.04
* Debian 6, 7, 8, 9
* Fedora 17 at least
* Archlinux
* Red Hat
* Slackware 14.0
* OpenBSD
* NetBSD
* FreeBSD 9.2, 10.x, 11.x
* openSUSE Tumbleweed (gcc7)
* openSUSE Leap 4.2 (gcc4)
* SUSE 12 SP3 (gcc4)
* Solaris, OpenIndiana
5. Fix.
The maintainers of the open source CDE 2.x version have issued the following
patches:
https://sourceforge.net/p/cdesktopenv/mailman/message/36900154/
https://sourceforge.net/p/cdesktopenv/code/ci/6b32246d06ab16fd7897dc344db69d0957f3ae08/
Oracle, which maintains a different CDE codebase based on the 1.x train, has
assigned the tracking# S1240932 and has released a fix for all affected and
supported versions of Solaris in the Critical Patch Update (CPU) of April 2020.
As a workaround, it is also possible to remove the setuid bit from the
vulnerable executable as follows (note that this might prevent it from working
properly):
bash-3.2# chmod -s /usr/dt/bin/dtsession
Please note that during the audit many other potentially exploitable bugs have
surfaced in libDtSvc and in the Common Desktop Environment in general.
Therefore, removing the setuid bit from all CDE binaries is recommended,
regardless of patches released by vendors.
Copyright (c) 2020 Marco Ivaldi and @Mediaservice.net. All rights reserved.
["2020-07-solaris-whodo-w.txt" (text/plain)]
@Mediaservice.net Security Advisory #2020-07 (last updated on 2020-04-15)
Title: Heap-based buffer overflow in Solaris whodo and w commands
Application: Setuid root whodo and w binaries distributed with Solaris
Platforms: Oracle Solaris 11.x (confirmed on 11.4 X86)
Oracle Solaris 10 (confirmed on 10 1/13 X86)
Other platforms are potentially affected (see below)
Description: A difficult to exploit heap-based buffer overflow in setuid
root whodo and w binaries distributed with Solaris allows
local users to corrupt memory and potentially execute arbitrary
code in order to escalate privileges
Author: Marco Ivaldi <marco.ivaldi@mediaservice.net>
Vendor Status: <secalert_us@oracle.com> notified on 2019-08-23
CVE Name: CVE-2020-2771
CVSS Vector: CVSS:3.0/AV:L/AC:H/PR:L/UI:R/S:C/C:L/I:N/A:N (Base Score: 2.5)
References: https://github.com/0xdea/advisories/blob/master/2020-07-solaris-whodo-w.txt
https://www.oracle.com/security-alerts/cpuapr2020.html
https://www.oracle.com/technetwork/server-storage/solaris11/
https://github.com/illumos/illumos-gate/blob/61aaa916808c601f9ee36d96c05ee9dac211d09e/usr/src/cmd/whodo/whodo.c
https://github.com/illumos/illumos-gate/blob/61aaa916808c601f9ee36d96c05ee9dac211d09e/usr/src/cmd/w/w.c
https://www.mediaservice.net/
https://0xdeadbeef.info/
1. Abstract.
A difficult to exploit heap-based buffer overflow in setuid root whodo and w
binaries distributed with Solaris allows local users to corrupt memory and
potentially execute arbitrary code in order to escalate privileges.
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:~$ cp /usr/bin/sleep \
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA \
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA \
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA \
raptor@stalker:~$ exec -a '- \
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB \
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB \
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB' \
./AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA \
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA \
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA \
256 & [switch to another shell]
raptor@stalker:~$ whodo -l # or w
12:43pm up 5 day(s), 20 hr(s), 36 min(s) 5 user(s)
User tty login@ idle JCPU PCPU what
raptor vt/7 Tue 2pm 6days 1:49 1:49 /usr/lib/tracker-miner-apps
Segmentation Fault
3. Discussion.
A detailed analysis of the buffer overflow in whodo follows. The w binary is
also affected by this bug, because the two programs share a large portion of
their codebase. Therefore, similar considerations apply to w.
The overflow happens as follows (the Illumos source code available on GitHub
has been used as a reference for this analysis, even though it doesn't exactly
match the code of the binaries shipped with commercial Solaris versions):
* The psinfo structure info is populated by reading /proc/<pid>/psinfo
* The char array info.pr_fname[16] is copied into the char array
up->p_comm[80+1]
* As a side note, the call to strncpy() at lines 344-345 incorrectly uses the
size of the source buffer instead of the size of the destination buffer, but
in this case this programming mistake doesn't cause a problem, because the
source buffer is always smaller than the destination buffer:
(void) strncpy(up->p_comm, info.pr_fname,
sizeof (info.pr_fname));
* The char array up->p_args[80+1] is then populated at line 418 based on the
char array info.pr_psargs[80] as follows:
(void) strcpy(up->p_args, info.pr_psargs);
* If up->p_args begins with "?" or "- " (or, more correctly, with "-" followed
by any byte <= 0x20), the following code branch at lines 423-425 is taken:
(void) strcat(up->p_args, " (");
(void) strcat(up->p_args, up->p_comm);
(void) strcat(up->p_args, ")");
* In detail, the following chars are appended to the string:
" (" + up->p_comm [maximum size excluding NULL-terminator is 15] + ")" + NULL
* Therefore, it is possible to overflow the up->p_args buffer at most as
follows:
* Buffer is 81 bytes: "- " + "B"x77 + " ("
* Overflow is 17 bytes: "A"x15 + ")" + NULL
The uproc structure is declared at lines 106-119:
struct uproc {
pid_t p_upid; /* user process id */
char p_state; /* numeric value of process state */
dev_t p_ttyd; /* controlling tty of process */
time_t p_time; /* ticks of user & system time */
time_t p_ctime; /* ticks of child user & system time */
int p_igintr; /* 1=ignores SIGQUIT and SIGINT */
char p_comm[PRARGSZ+1]; /* command */
char p_args[PRARGSZ+1]; /* command line arguments */
struct uproc *p_child, /* first child pointer */
*p_sibling, /* sibling pointer */
*p_pgrplink, /* pgrp link */
*p_link; /* hash table chain pointer */
};
A 17 bytes overflow past the p_args buffer is not large enough to reach
critical control structures and directly take control of the program flow.
However, we are able to overflow into the p_child and p_sibling members of the
uproc structure up, assuming 64-bit addressing. With 32-bit addressing we
should be able to corrupt additional pointers, i.e. p_pgrplink and p_link.
A skilled attacker might be able to leverage the corruption of these pointers
to obtain arbitrary code execution. However, he or she would face a number of
additional challenges:
* The target program uses privilege bracketing with the PRIV_PROC_OWNER
privilege. This privilege allows a process to send signals to other
processes, inspect, and potentially modify (with some additional
restrictions) the process state in other processes, regardless of ownership.
Therefore, it's theoretically possible to write a shellcode that activates
the privilege and dumps the memory of a privileged process (e.g. "passwd")
via /proc/<pid>/mem, without ever executing an actual shell. However, this
must be done before privileges are relinquinshed at line 455. This leaves
only a limited amount of code paths to leverage our corrupted structure
(namely, the main loop through /proc starting at line 315 and ending at line
452).
* The char array info.pr_psargs[80] is cleaned up by the clnarglist() function
at line 417: non-printable ASCII chars (c < 0x20 and c > 0x7e) get replaced
with a "?" and must therefore be considered badchars. Luckily this
restriction does not apply to the part of the buffer that causes the actual
overflow, but only bytes that are valid in file names can be used in our
malicious buffer.
* The ")" + NULL chars at the end of the evil buffer might cause unforeseen
problems during exploitation.
* Additional security measures such as Address Space Layout Randomization
(ASLR) might get in the way of reliable exploitation.
Based on this analysis, our conclusion is that this bug not exploitable on
Solaris 11.x and 10 in order to escalate privileges. That said, as a rule of
thumb all memory corruption issues have the potential to become serious
security vulnerabilities until otherwise proven. For instance, it might very
well be possible to exploit this bug on systems that don't implement privilege
bracketing, such as Solaris 9 and earlier. Therefore, we recommend to treat
this bug as a potential security vulnerability and to fix it as such.
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)
Other Oracle Solaris versions (including those that run on the SPARC
architecture) and Illumos distributions are also likely affected.
5. Fix.
Oracle has assigned the tracking# S1199548 and has released a fix for all
affected and supported versions of Solaris in the Critical Patch Update (CPU)
of April 2020.
As a temporary workaround, it is possible to remove the setuid bit from whodo
and w executables as follows (note that this might prevent them from working
properly):
bash-3.2# chmod -s /usr/sbin/whodo /usr/bin/w
Copyright (c) 2020 Marco Ivaldi and @Mediaservice.net. All rights reserved.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic