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’s offices. The latest schedule can always be seen at softwaregr.org. Meetings are always free and open to the public.