zlibscan : script to find suid binaries possibly affected by zlib vulnerability (fwd)

[Devin Carraway]

The only binaries this script will find are the ones whose vulnerability
would be fixed anyway by updating zlib.

The real trick here is finding binaries that incorporate their own copy
of the zlib code, or link against it statically.  Neither can be
detected readily.  Dumping the symbol table for a given binary (objdump
-t) and looking for inflate_blocks() will do it, but stripped binaries
don't have the symbols.  Dumping the string table and looking for
"inflate:     fixed codes block%s" will do it if debug tracing was
enabled (which it probably wasn't).  Otherwise you can disassemble a
binary (objdump -d) and look for an instruction sequence taken from
zlib, and I wouldn't give high odds to that approach either.

This being OSS, the best approach is to go through the sources, unless
your distro vendor has already done so.  If your vendor's already
identified vulnerable packages in the distro, you can merely check stuff
you've added yourself.

Fortunately, while compression is pretty ubiquitous, most app authors
know to link against zlib rather than copying it in, and most
distributions make particular effort to ensure that things are
dynamically linked.  The list so far has been pretty manageable.

In the kernel, FWIW, the vulnerable sections I've identified are the
JFFS2 flash filesystem, inflate_fs, the PPC boot loader, network
compression (PPP deflate), and FreeS/WAN's IP compression
(CONFIG_IPSEC_IPCOMP).  Of those, the latter two are probably
exploitable.  The others have superuser access as a prerequisite.


-- 
Devin  \ aqua(at)devin.com, 1024D/E9ABFCD2;  http://www.devin.com
Carraway \ IRC: Requiem  GCS/CC/L s-:--- !a !tv C++++$ ULB+++$ O+@ P L+++