=====================================

Looking for Vulnerabilities

(Antonomasia <ant@notatla.demon.co.uk>)

============================================

Our approach has been to look for a few common mistakes in programs

(and scripts) of interest (mainly setuid, setgid programs and network

servers).

The common flaws are:

1) unsafe temporary files

2) dependence on the environment

3) buffer overflows

With shell scripts it has just been done by inspection, after finding

the ones likely to be interesting with 'find' and 'grep'.

Examples such as this one

find /somewhere -some-options > /tmp/rm$$

rm `cat /tmp/rm$$`

show that the user is risking the removal of files he doesn't intend

if /tmp/rm$$ exists already having been prepared by an attacker.

With binaries, the first two faults listed above tend to be visible

under commands like:

strings - prog | \

egrep '[Tt][Mm][Pp]|popen|^system|chown|chmod|%s/|/%s|%s.*>|/usr|usr/'

These match references to "/tmp" and similar names and the tmpnam() C

function. The " -c", system and popen strings are famously dangerous in

these programs for the following reasons:

they give commands to the shell (to be avoided)

the PATH (and other environment) gets used

input might include shell metachars (and limited taint-checking here

by the programmer is often flawed)

chown and chmod have obvious security implications so it is nice to know

when a program uses them. The %s constructions suggested above are

often used in data given to a shell. So when you suspect that the shell

is being used these often indicate what the shell is likely to be doing.

When you see text like "/some/program -opts %s %s >/dev/null 2>&1"

This suggests a command similar to ./snmpcheck AAA BBB';/bin/sh #'

as a way to get a root shell. The program is obsolete on the platform

where this was observed.

Sometimes this does not work well, the program may be well-enough

written to drop privileges before calling external programs. Further

greps looking for the setuid family of system calls, umask, chdir, PATH,

and anything else prompted by earlier observations may shed some light

on the proceedings. On small programs you can read the entire strings

output (perhaps varying the minimum string length). I normally pipe

this through "uniq -c" to reduce the length slightly.

For perl CGI scripts the constructs system("something"); and

open(H, "command|"); are dangerous and should be viewed similarly.

Failure to set a umask or specify a mode for a file can be a fault as

the setuid program may create world-writable files as root. With a

little care you can overwrite the file of your choice: perhaps a startup

file called from a script like

[ -f /usr/sbin/foo/file ] && . /usr/sbin/foo/file

where a mode of 666 does not prevent the content being executed.

Use of a wrapper program to list UID, GID, CWD and the environment can

help expose the way something is called. It also helps if it lists all

parent processes leading back to init. Sometimes you see shell scripts

disguised as C programs where there are popen() calls with long

pipelines such as "ps|grep|cut" in them. If the PATH has not been set

this could be easy to compromise. Another feature I've seen in code

like this is that programs are setuid something non-root. This means

that although nobody can get root access this way there is still the

chance of adjusting the programs unless ro mounts or non-traditional

filemodes are employed.

Buffer Overflows

For testing local setuid programs it may be necessary to copy the

program to a non-suid file because on many modern systems setuid

programs will not dump core and you will want to look at the corefiles.

Some programs will (in production versions) refuse to dump core anyway

via setrlimit().

Beside stdin, you have influence over a number of other inputs such as

the command-line arguments, environment variables and current directory.

Passing a large string to the program (a few thousand chars) may cause

a segmentation fault and core dump if the data is being read unsafely.

Depending on how the program works you might need to test this over a

network connection (or getpeername() may prevent the faulty code from

being reached) or you might simply run the program under a debugger

with "break gets" if it is that blatantly wrong.

##############################################################

# Antonomasia ant notatla.demon.co.uk #

# See http://www.notatla.demon.co.uk/ #

##############################################################