Clever attack exploits fully-patched Linux kernel - 'NULL pointer' bug plagues even super max ....

A recently published attack exploiting newer versions of the Linux kernel is getting plenty of notice because it works even when security enhancements are running and the bug is virtually impossible to detect in source code reviews.

The exploit code was released Friday by Brad Spengler of grsecurity, a developer of applications that enhance the security of the open-source OS. While it targets Linux versions that have yet to be adopted by most vendors, the bug has captured the attention of security researchers, who say it exposes overlooked weaknesses.

Linux developers "tried to protect against it and what this exploit shows is that even with all the protections turned to super max, it's still possible for an attacker to figure out ways around this system," said Bas Alberts, senior security researcher at Immunity. "The interesting angle here is the actual thing that made it exploitable, the whole class of vulnerabilities, which is a very serious thing."

The vulnerability is located in several parts of Linux, including one that implements functions known as net/tun. Although the code correctly checks to make sure the tun variable doesn't point to NULL, the compiler removes the lines responsible for that inspection during optimization routines. The result: When the variable points to zero, the kernel tries to access forbidden pieces of memory, leading to a compromise of the box running the OS.

The "NULL pointer dereference" bug has been confirmed in versions 2.6.30 and 2.6.30.1 of the Linux kernel, which Spengler said has been incorporated into only one vendor build: version 5 of Red Hat Enterprise Linux that's used in test environments. The exploit works only when a security extension knows as SELinux, or Security-Enhanced Linux, is enabled. Conversely, it also works when audio software known as PulseAudio is installed.

I had some interesting exposure to Ada. Was working on a big Army contract in the late 90’s; a massive system for the signal core. The thing had been original written in C++ and was supposed to be moved to Ada, which I seem to recall was a general DOD mandate. Some third party vendors were already supplying some stuff (radio transmission/propogation algorithms) in Ada, but it was real buggy, so I actually learned Ada by debugging their stuff. Not sure that’s the best way, but I ended up learning quite a bit about the language and was pretty impressed. The idea of a variable only being able to take on discrete, evenly spaced intervals was interesting. Also the idea of a float (or did they call it a “real”) being equal to another within some range (and of course, the math-major-turned-engineer-turned-programmer in me thinks “balls of radius episelon, cool”). And I don’t think I ever saw exception handling in C++ before seeing it in Ada. Unfortunately (or not), I escaped to the private sector and have toiled in C++ (and more recently .NET) ever since.

Oh, and I toiled in both Smalltalk and Objective C back in graduate school. The former academically and the latter doing research projects on the NextStation (What a hot box that was!)

The thing we all need to remember (but most especially the youngsters here) is that Unix (and C) started out on PDP-11’s. The PDP-11, before there were extended memory bus architectures that allowed the PDP-11 to address more than 64kB of memory, could really only allow the programmer to get at 56kB of the core, since 8kB was mapped for IO.

In other words, things were a tad snug. Little techniques that saved a byte here, a byte there, were used - all the time. On DEC’s own operating systems, they used a reduced character set known as “RAD-50” (short for “RADix 50”) for all filenames - which would allow six characters to fit into four bytes. This meant than for DEC operating systems, the “six.three” filename you first saw in DOS or CP/M systems really came over from the PDP-11 world — where they were able to hold the filename and extension in three bytes.

Same sort of things happened in Unix. It is why Unix has these very terse error messages - strings took up memory. Why there are null-terminated strings - you were going to use either a single byte for a string length (and limit yourself to 255 characters in a length-description string datastructure), two bytes (which would allow you to describe strings as large as your entire memory) or you were going to use a single termination character. They chose 0 because of the PDP-11 instruction set and the fact that the condition codes were set on a move - so as you were copying the string through an indirect register addressing move, you could branch without a test, like this:

(assume you have the source string address in R2, the destination address in R3)

$10: movb (r2)+, (r3)+
bne $10

(continue after the string copy)

If you wanted to use something other than null for the string termination, you’d need to do something like this:

$10: movb (r2), (r3)
cmpb (r2), #terminator
beq $20
inc r2
inc r3
br $10
$20: ; end of loop

See how that one little choice of non-null termination suddenly inflated the code?

The PDP-11 were great machines, but they suffered from memory constraints, just as every other 12 or 16 bit architecture did. The memory architecture was eventually extended to 24 bits (4MB), but you had to jump through the hoops of segmented memory architecture to use it, which I won’t bore you with here.

I maintain that the BEST way for new programmers to learn a large, complicated s/w system is to put them on “patch detail” — first thing the management should do is hand the newbies a bug report of moderate difficult and say “Go fix this. And then TEST it. Then run the patch by a senior engineer and if he/she approves it, come back and get your next bug assignment.”

re: Ada. For me, one of the most impressive arguments in favor of Ada is that the language designer(s) put a lot of emphasis on the detection and handling of data errors. And by that, I mean a lot more than just “this pointer was NIL, or we attempted to divide by zero.” No, Ada had a lot more thought put into exception detection and exception handling than any other language I’ve seen. The software industry has failed over the last 40 years to make substantial and lasting improvements in the way we handle errors and exceptional cases, with Ada as perhaps the only bright spot in this gloomy assessment.

In C, far too often the problem is just vomited up to the operating system and we get blue screens and stack dumps - even when the error started as a data constraint issue that could have been very successfully dealt with wholly within the application. In C++, Java and other languages, we see the “try... catch” paradigm, but this is a very unsatisfying way to handle errors IMO. Your code ends up being festooned with try...catch constructs all over the place, whereas in Ada, you declare exception handlers for various exceptions and then in the bowels of your code, you just signal an exception with a “raise” statement, which jumps out of your current processing context and transfers control to the exception handler. Much cleaner code results.

One could implement something similar in C with setjmp()/longjmp(), but many C programmers, when confronted with these calls and an exception handling system implemented on them, tend to vapor-lock.

Do you really think this was the reason, or just an interesting artifact?

I'm wasn't in 1127 in the '60s so I can't make any authoritative statements, but from the Bell-labs Unix code I've seen null terminated strings get used(or some would say abused) a lot.

For example, if you're reading from a pipeline and you want to sort a set of lines with null terminated strings you can do it in place. Just replace newlines with nulls in your buffer, keep a pointer array sort it and you're done. With Pascal style strings you have a bunch more issues to deal with. You can keep it (somewhat)space efficient by using a structure that contains the length of the string and a pointers to the strings in the buffer. But then you've already used at least 1.5x as much space(i.e. two bytes for length in addition to a 4 byte pointer, assuming a 32bit architecture) and you have to think of a bunch more issues, like now your strings are finite length, if you make two of those pointers point to parts of the same string, how do you know if one string isn't modifying part of the other? etc...). You could also copy every time, which solves the pointer problem at the expense of efficiency.

With null terminated strings you don't have any of these problems. Strings are just delimited memory. If you need to copy them, you do. If you want to edit them destructively in place, go ahead. It's quite simple to implement and quite powerful to use, although it can get you in quite a bit of trouble.

Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.