Yesterday SoftwareGR hosted Dr. Richard Enbody from MSU. He spoke about security, and
he quoted the above security rule from the book Writing Secure Code by Michael Howard and David LeBlanc (sample chapter.)
The main topic of the talk was recent research performed by Richard’s team to develop a new security feature called Secure Bit.
One of the biggest classes of vulnerabilities out there is the buffer overflow.
Richard showed a list of vulnerabilities taken from CERT’s homepage the preceding day and showed us a slide full of recently discovered buffer
overflows. He told us he’s always been able to fill a slide using just the first page.
Buffer overflows are caused by feeding the software some carefully crafted
input that allows a malicious user to redirect the flow of execution. Richard’s
research discovered that a vulnerability can be present even when the user
can’t inject bad code – it turns out that taking over the execution is
sufficient. Read more about buffer overflows on Wikipedia.
We heard about an interesting technique for finding these vulnerabilities:
fuzzing. This is a way of partially automating an attack. It works by feeding
the target software a randomized stream of inputs and waiting until a
fault occurs. These faults (and the recent inputs) can be logged and analyzed to discover an attack – for both attacking systems and for fixing your own. Richard’s team developed an ingeniously simple defense against buffer
overflows, called Secure Bit. It is a very simple algorithm:
- Label all input as tainted.
- Forbid jumps to a tainted address.
This is accomplished with a combination of software and hardware changes.
Richard adds a single bit to every word stored which indicates whether the
input is tainted or not (called the secure bit). This addition can be done at
the operating system level and is a relatively simple change. In the Linux
kernel Richard’s team was able to make it happen in 4 lines of code. The jump
protection is added at the hardware level in the processor. This was tested by
making the change in a CPU emulator.
The simplicity of this approach means that the instruction set doesn’t have to
change and the code stays binary-compatible. For this to be installed on a
system, all it would need is the updated hardware and the kernel – no
other software needs to be aware of it.
Richard’s test system ran Red Hat, and they tested out a number of known
exploits against vulnerable targets and demonstrated that the Secure Bit
approach does protect against malicious code execution.
Read all about it on Richard’s web site.
Software GR meets on the
fourth Tuesday of the month from 6PM to 8PM at Atomic Object offices. The latest schedule can always be seen at softwaregr.org. Meetings are
always free and open to the public.
