Marco Ivaldi <marco.ivaldi@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 this function.
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.
There was code (_DtSimpleError() and _DtSimpleErrornoError()) that
only used snprintf when USE_SNPRINTF was defined, which it never was
of course. We just remove the 2 checks and always use [v]snprintf.
With this patch, CDE (autotools) builds and runs on fbsd 12 now.
fbsd11 should work too, but not yet tested.
You must use gmake - ie:
./configure MAKE=gmake
gmake
Seems all of the BSD's will need to use gmake for now.
Certain programs like dtlogin and tt_type_comp need access to the
system's cpp command to process certain files at runtime. tradcpp is
not installed on most systems, and is intended for use as a imake-cpp
replacement which is all we are using it for. We still need an
honest cpp for the CDE components to use.
Now, we look in various places for a 'cpp' command and set CPP_COMMAND
to it's value. This way tt_type_comp and other CDE programs can do
required processing at runtime.
There is a problem with CPP_PROGRAM - using $CPP or $GENCPP (tradcpp)
always fails in tt_type_comp with the error:
"nclude ", line 8: syntax error
If I define it to /lib/cpp (previous hardcoded value) then it seems to
work fine. Only the dtinfo and dtinfo_start ptypes use #include, and
therefore show this error. Needs investigation.
Also, restructure some of the dependencies in the lib/tt binaries. We
will link with libtt (which will include libtirpc as a dependency),
and XTOOLLIB - all the right X11 stuff without needing to add it to
every OS. Removed several uneeded OS specializations ("if LINUX",
etc) as a result.
This means that when linking against libtt, libtirpc should also
automatically be linked in if we determined that we are using tirpc.
This avoids having to link every program that uses libtt (almost all
of them) from having to have a $(TIRPCLIB) added to their link
commands.
We take advantage of subdir-object and just build the subdir source
files directly as normal dependencies of libDtSvc in the top level
Makefile.am.
This means the intevening subdirectory Makefiles are no longer needed,
and no need to replicate flags and the like between the
subdirectory Makefile.am files.
Also, no need to build fake .a libs we can't really use.
configure: remove AC_OUTPUT_FILES related the the lib/DtSvc/*
subdirectories. They are no longer needed.
We were building subsets of this library as archive.a objects, then
trying to combine them into a shared object. This warnings, and link
failures due to the lack of 0fPIC when building the archive libraries.
Now, we do not buld archive libraries, and the main libDtSvc.so
library is build by adding all of the .lo file in the component
subdirectories.
In a future commit, we could just remove the SUBDIR builds (DtUtil1,
etc) and build the sub objects directly.
cppfile.inc - don't set BUIT_SOURCES or CLEANFILES here as they
overwrite (or in case of the CLEANFILES +=...) ignore the settings.
Do those in the Makefile.am always.
We still need a better way to preprocess generic files. cppfile.inc
will only work for one file per Makefile...
There are/were two dproto.h files, one in DtSearch, one in raima. The
one in raima is the one we want, so replace the global Dt/dproto.h
with it. Also correct a prototype declaration error in that file.
Delete the dproto.h file in DtSearch, it's garbage and unused.
Next, redo the way yacc is used. Autotools does "the right thing" by
simply including the .y file in *_SOURCES and using
BUILT_SOURCES/CLEANFILES to manage it. No need for special rules to
handle yacc and lex.
Some files were trying to access the global includes directy in the
build area with things like #include <api/c/tt_c.h>, which is now
wrong. Se we fix all of those up. tt_c.h and tttk.h are now global,
so we no longer need to root around various build dirs to find them.
TT builds again.
Ok - so one of the steps in building CDE is an early phase called the
includes phase (make includes). At this point, all of the public
header files are exported to exports/include/Dt, DtI, ...
Then, the software is built using that include dir.
This of course does not work in autotools. Much of the software does
things like #include <Dt/something.h>, so in order for the build to
succeed, this behavior must be represented/replicated in some way.
It seems the usual way of dealing with this is to place all public
headers (and in some projects, ALL headers) into a toplevel include
directory.
We now do this for all public headers - they have been moved from
wherever they were and placed in the appropriate spot in includes/
This will break the Imake 'make includes' phase unless the Imakefiles
are fixed (remove the HEADERS = stuff, and the incdir defines). This
has not been done at this point since in reality, once autotools works
properly, there will be no need for the Imake stuff anymore, and I
intend to get rid of it.
This is just a warning for now - Imake builds in this tree will now
fail at the 'includes' stage.
This commit is only the migration. In upcoming commits, libtt will be
fixed so that the hack being used before to get around this problem is
removed as there will no longer be any need.
And then the autotools work continues...
Jon Trulson