Hi, FWIW, here are two releases from Marco that might shed more light:
https://techblog.mediaservice.net/2020/01/local-privilege-escalation-via-cde-dtsession/ https://github.com/0xdea/advisories/blob/master/2020-02-cde-dtsession.txt which includes a link to the Solaris POC. -jon On 1/14/20 5:37 PM, Jon Trulson wrote: > Hi, > > This is a quick release of CDE 2.3.2. It is the same as CDE 2.3.1, > except that a patch has been applied to correct some potentially > exploitable buffer overruns in dtsession and DtSvc. dtsession runs > SUID root. > > This release of CDE was timed to occur after the embargo period > defined by the release of related patches by Oracle for their version > of CDE, which was to have occurred at 1PM today (Jan 14). > > The currently unreleased POC (Proof of Concept) exploit code only > works on the Oracle version of CDE. It exploits stack based buffer > overflows in dtsession to provide a root shell to a local unprivileged > user. > > Oracle is using the v1.x source base, where we are using the 2.x > base. In the Solaris version, these overflowed variables reside on > the stack. In our CDE, they reside on the heap, which makes things > somewhat more difficult to exploit. > > There are 3 vulnerabilities, of which only two would apply to us. > > For this reason, a patch has been pushed to master that should address > these issues. Since master is not yet stable enough for a release, we > (Peter and I) decided a 2.3.2 release with this patch was warranted > just to be overly cautious. > > To be clear: Current opensource CDE is not vulnerable to the POC, and > of the 3 issues, only two could be exploited in previous versions with > a significant amount of work. However for someone with the skills and > the time... > > Here is a link to the master commit if you are curious: > > https://sourceforge.net/p/cdesktopenv/code/ci/6b32246d06ab16fd7897dc344db69d0957f3ae08/ > > The real horror here is that the original programmers clearly did not > understand how strncat() works :) > > What follows is the text of the commit: > > dtsession, DtSvc: fix CVE-2020-2696/VU#308289 > > Marco Ivaldi <marco.iva...@mediaservice.net> has identified 3 > vulnerabilities in CDE. > > Two of them could affect our CDE (open-source version), while the 3rd > (sdtcm_convert) is Solaris specific. > > The two vulnerabilities, both of which affect dtsession could allow a > local privilege escalation to root. A POC exists for Solaris. The > POC will not function on our CDE for two main reasons: > > - the POC is Solaris specific > - The overflowed variables in question are allocated on the heap, > whereas in Solaris these variables are located on the stack. > > The first vulnerability allows an extra long palette name to be used > to cause a crash via insufficient validation in > SrvPalette.c:CheckMonitor(). > > The second, which has not yet been assigned a CERT CVE resides in > SmCreateDirs.c:_DtCreateDtDirs() in libDtSvc. Due to insufficient > bounds checking, a crash or corruption can be achieved by using a very > long DISPLAY name. > > This one is considered difficult to exploit, and no POC code is > available at this time. CDE 2.x code-bases are also listed as not > vulnerable, however some work has been done anyway to do some proper > bounds checking in these functions. > > The following text portions are copied from the relevant advisories, > which have not been released as of this writing. > > NOTE: Oracle CDE does NOT use CDE 2.3.0a or earlier as mentioned > below. They are completely different code-bases): > > Regarding CVE-2020-2692: > > A buffer overflow in the CheckMonitor() function in the Common > Desktop Environment 2.3.0a and earlier, as distributed with Oracle > Solaris 10 1/13 (Update 11) and earlier, allows local users to gain > root privileges via a long palette name passed to dtsession in a > malicious .Xdefaults file. > > 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. Most notably, the vulnerable buffer in the Oracle Solaris > CDE is stack-based, while in the open source version it is > heap-based. > > Regarding the DtSvc bug, which does not currently have a CERT CVE: > > 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. > > The open source version of CDE (based on the CDE 2.x codebase) is > not affected. > > Enjoy... > > > -- > Jon Trulson > > "Entropy. It isn't what it used to be." > -- Sheldon > > > _______________________________________________ > cdesktopenv-devel mailing list > cdesktopenv-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel -- Jon Trulson "Entropy. It isn't what it used to be." -- Sheldon
_______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
