Sanitizers and Sudo
Sudo’s build system has native support for compiling with
Sanitizers when using the
gcc or clang compilers. It is recommended that you use the configure
options described below rather than trying to adjust the
Makefile options. Failure to do so may
result in memory leak false positives.
To build sudo with sanitizer support you must use the
configure option. This will add the
-fno-omit-frame-pointer compiler options in the correct places.
It will also enable
config.h, which prevents some
memory from being reported as leaked at exit time.
To avoid a potential crash in the
crypt() C library function when
ASAN is enabled, it may be necessary to statically link the sudoers
policy module into the main sudo binary. Otherwise, you may see a
crash from ASAN when trying to read a NULL address (this is not a
bug in sudo).
$ ./configure --enable-static-sudoers --disable-shared-libutil \ --enable-sanitizer
--enable-sanitizer will enable both Address
and Undefined Behavior
(UBSan). To enabled a specific sanitizer, pass it as argument to
--enable-sanitizer. For example, to only enable ASAN:
$ ./configure --enable-static-sudoers --disable-shared-libutil \ --enable-sanitizer=address
Sudo’s test suite is run regularly with both ASAN and UBSan enabled. You can run it yourself via:
$ make check
There should be no memory leaks or crashes reported.
A sudo binary built with sanitizer support should only be run in a test environment. Due to some sanitizers’ unchecked use of environment variables, it is trivial to exploit a set-user-ID root executable such as sudo.
A sanitizer-enabled sudo binary should run normally and not report memory leaks on exit.