Slashdot Mirror
New Hack Exploits Common Programming Error
buzzardsbay writes "TechTarget's security editor, Dennis Fisher is reporting that researchers at Watchfire Inc. have discovered a reliable method for exploiting a common programming error, which until now had been considered simply a quality problem and not a security vulnerability. According to the article, the researchers stumbled upon the method for remotely exploiting dangling pointers by chance while they were running the company's AppScan software against a Web server. The good folks at Watchfire will detail the technique in a presentation at the Black Hat Briefings in Las Vegas in August, Fisher writes."
it's one thing to find a major exploit, but a whole new class of exploits?
welcome back to the days of sql slammer and code red folks. buffer overflows have been analyzed to death, but this is just the beginning
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
Unfortunately, that solution breaks down when you have multiple different pointer variables pointing to the same location. This will happen in any graph-like data structure more advanced than a tree. You can get around it by adding a level of indirection from handles to pointers, and making the handle-pointer mapping nodes reference counted (note that reference count cycles are not possible using this strategy), but that can have a significant performance hit, and requires quite a bit of refactoring.
The OS has very little to do with it. It's the hardware, specifically the MMU, which will do this checking. If you are using something like OpenBSD, then it will not let a page be both executable and writeable at the same time, but that requires doing some messy things with segments on x86 (unless you have a new chip with page-level execute permissions). On most x86 hardware, if memory is readable, it is executable, and anything you allocate with malloc() and friends will have read/write/execute permissions.
I am TheRaven on Soylent News
Nobody said it couldn't be exploited before this. It's been known for quite a while that this is an exploitable problem. The point is that it can now be predictably exploited.
If you actually knew what you were talking about, however, I wouldn't have had to tell you that.
Because the other 95% saw that you take too long to write code and your code executes too slowly and you are going to be fired because of it.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
People have been 'sploiting this kind of thing for years as far as I know.
Perhaps you're confusing dangling pointers with buffer overflows. Buffer overflows occur when you put too much data into a pre-allocated buffer, overwriting the return address of the current function with a return address pointing to your malicious code. Dangling pointers are simply pointers pointing to invalid types. Before, it was thought that dangling pointers were not exploitable, because you had to know the actual type of the destination object, which was thought to be difficult. However, this group has discovered a way to reliably discover the destination type, allowing them to overwrite it with malicious code.
We all know what to do, but we don't know how to get re-elected once we have done it
Apache doesn't really work in a way that leaves dangling pointers to exploit in the first place (resource pools). And since this requires code to be loaded at a specific point in memory, which then must be executed, it's going to be webserver-build and OS-specific, which leaves Apache in a good position since that varies across distributions and versions; the attack will be useless if grsecurity or other address randomization technique is used.
IIS 5.1 and 6.0 is a smaller target space of possibilities.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Unfortunately, that solution breaks down when you have multiple different pointer variables pointing to the same location.
Okay sure, the FreeFoo() logic will not, by itself, take care of the case where you have multiple pointers. Only the pointer you actually use to free the object would be automatically nulled.
As you note, it is possible to pass around "handles" and make the handles safe, and as you note, there can be a performance hit.
But if you have a clean code design, you will have an expected lifetime for those extra pointers, and when you are done using a pointer, you can NULL that pointer. When you are done, you should have only one pointer left pointing to the object, and when you call FreePfoo(), you will then have zero pointers left pointing to the now-freed object.
Another simple trick you can use: at the beginning of your structure, place a member variable called "signature" or something like that, and set it to some unique value. Then, in FreePfoo(), zero out the signature before you call free(). Then start each function that uses a PFOO with an assert() that checks that the signature is sane. Even if you have a dangling pointer, and even if that pointer can still be used to reference your structure after you free() the structure, the assert() will fail. If you like you can put the "signature" member under #ifdef so that you don't even compile it in unless asserts are enabled.
The last major application I developed, I used the above tricks. The most important data structures each had their own unique signature. Functions that took a PFOO started with a call to AssertValidPfoo(pfoo), which would check the signature and also perform every other sanity check I could think of upon the FOO and the pointer (and which would not be compiled for a release build). Once the compile succeeded with no errors or warnings, I would run a test and immediately get an assert() if I had a code bug. Once I fixed the code to no longer assert(), in general my code Just Worked.
Asserts are like unit tests that run every time you run your code, and don't cost anything in the final release build. I love asserts.
Does this sound like more work than a garbage-collected language like Java or Python? Well, it is. C is just plain a lower-level language and you need to do more stuff by hand.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
No, it's a syntax error. "The other 95% of programmers" refers to the complete set of programmers, less excluded subset. He defined that subset as himself, instead of himself plus others who can code properly; improper usage of "The other" is what caused his dependent clause to be false.
Note that I'm using dependency grammar here (to which class algebraic grammar belongs). Followers of looser grammatical theories may find the statement technically correct since his meaning was clear. However,this is predominatly a tech site, it follows that dependency grammars should rule the roost.
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
Not to mention that Java isn't exactly perfectly safe, either.
This really is just another example of why unit testing should be required.
Now, however, they can change the value of the dangling pointer and when IIS does the jump this time, it executes their exploit code instead.
They are not saying they "change the value of the dangling pointer".
From the FA: "The problem before was, you had to override the exact location that the pointer was pointing to. It was considered impossible. But we discovered a way... The long and short of it is, if you can determine the value of the pointer, it's game over."
There are theoretically two ways to exploit a dangling pointer - change the address that it points to (which they don't do), or discover the address it is pointing to, and put some code there (considered impossible). Most likely, it is pointing to memory space within the program that once held valid executable code. They say this "was considered impossible, but we discovered a way". So I suspect they just stuck a jump instruction at the location the pointer was pointing to instead of trying to cram executable code into an unknown sized space. The jump would of course be to some space they allocated, with a known size, big enough to hold their exploit. Determining the value of the dangling pointer would be easy enough - you would get a message when it crashed that the app tried to access invalid memory at addr: 0x????????. Just stick a jump at that location - then get a big warm hug from Microsoft when you show them how you did it.
Various version of Window support DEP (Data Execution Protection?), and for Server 2003 with the lastest SP, I believe all of Windows itself runs under DEP. You have the option to enforce DEP on all running software, but chances are something you need will break. I don't know if it's possible to enforce DEP on some application and not others.
Socialism: a lie told by totalitarians and believed by fools.
As someone who's written 2 pieces of OSS with 100% code coverage in unit tests, and probably the most secure C http server (comes with over 75% coverage). I have to say: "It's not quite that simple". Testing does not negate design, and designing for security is non-trivial and takes a certain mind-set ... and while a lot of people say they want security, almost none are actually prepared to buy it (with either money, lack of features, whatever).
Hell, one of the biggest advancements in security in recent years is SELinux, and I see almost nothing but complaints about how it "is less usable, so we just turn it off". Summary: We are still dealing with security problems because that's what the majority of the market wants, welcome to democracy and the free market.
Actually usage of strncpy() almost certainly guarantees you have bugs, IMNSHO. You need a real managed string API. Assuming the programer can keep track of three distinct pieces of information like "size, length and pointer" is just a losing bet. All of the applications (including mine) that have had security guarantees with money have internally used a real managed string API.
ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
But that's actually Windows supporting the NX bit on certain recent CPUs. It *needs* hardware support to work properly.
There is a software substitute which takes effect in case your CPU doesn't support the NX bit, but that only prevents some attacks and *won't* stop execution of code in data pages.
I don't know if it's possible to enforce DEP on some application and not others.
And the answer is yes, it is possible. Windows runs DEP in either an Always-on, Always-off, Opt-in or Opt-out modes. Opt-out lets you enable DEP by default and then override it for specific programs which break, and Opt-in lets you disable it by default and then enable it for specific programs which'll benefit such as a web server.
Sure almost every *chip* is capable of preventing simultaneous write and execute... but it is rare for the OS to be configured that way due to the surprising number of applications that want to write on code. VMs, in particular - Java, flash, .NET, custom library loaders in databases and web-servers, script interpreters in any sufficiently fancy application often optimize by throwing in a little code generation. ... big applications want it for performance reasons.
While, in theory, all this stuff can be done by only writing on code when it is created or loaded - and then changing the flags back to execute-only to run it... but big apps frequently want fine-grained control over which code to rewrite, and even the ability to patch instructions that another CPU might be about to execute.
Why is this needed? Take an example - a VM wants to be able to recompile frequently executed code *after* startup - probably at a function/method level since code all over the place might be calling into any particular class implementation. Having recompiled the subject code - all the code running should be migrated over to the new faster implementation. If you have to *stop* the system every time you do this, a lot of the performance advantages of dynamic recompilation get eaten - and it totally bollixes 'realtime' implementations (so do most of the garbage collecters, but not *all* thankfully).
So Either - the instructions that are calls to the old code have to actually be indirect off of function-pointers - always even for non-virtual code, and some big virtual function tables merely need to be updated on recompilation, or you allow static invocations - and have rewrite the call instructions underneath the running CPUs.
Thing is - na indirect (or virtual) function call *is* slower than a direct one - an extra memory access is required, and in big apps it is not reasonably to assume that code will usually be in cache - an extra dependent memory access is *not* the 'one tick' that some theorists claim - it can hit many hundreds of ticks in pathological situations - without even hitting disk.
So... while they don't *have* to have write on code
Mozilla has considered dangling pointer use to be "probably exploitable to run arbitrary code" for a long time. I even blogged about that fact, describing what types of dangling point use are most likely to be exploitable. If other software companies refuse to prioritize those bugs until the reporter supplies a demonstration exploit that launches calc.exe or Calculator.app, they've been asking for trouble for years.
The shareholder is always right.
I guess the issue is, since they say "predictably" instead of "always", that there's a decent probability when one takes automation of the exploit into account. Try this enough times, and eventually you get it to work. It only takes the one time to "pwn" the server.
Well, no - a dangling pointer implies two different pointers referencing the same memory area. Since many objects have pointers to other objects, if you can change one object by modifying fields through the other pointer (either the dangling pointer or the memory area doubly referenced), you can change one of those object pointers to point to a location on the stack; then using common buffer overflow techniques, you can put code on the stack and modify a return address to point to that code.
I wouldn't say such an approach can ALWAYS be used to compromise a machine, but it is much more generic than the (also quite possible) C++ (and similar language) specific method using pointers to vtables and such.
I've always assumed that if you can get a program to crash, you can probably get it to execute arbitrary code. One way of avoiding such techniques (other than writing correct code) is to use hardware support. The No-Execute page flag is one good start; having separate control-flow and data stacks would be another (where the control-flow stack would only be accessible through special instructions). Randomizing the location of the stack and the heap, and possibly make the memory allocation routine be less optimal and more random would also help a lot. Having a tagged memory architecture would be helpful as well (pointers to code could ONLY be manipulated through special instructions, and trying to load the wrong type of memory would cause a hardware exception).
I'm not enough of a Perl expert to say anything about its implementation requirements, but there's nothing in the either original or Extended Pascal that requires code execute on the stack, at least not on most machines. If this technique is used it is almost always simply an implementation choice, nothing more.
The place where this sort of trickery is useful in Pascal is when a routine passes a routine at an "inner" lexical scope to another routine. In order for the passed routine to access variables in its outer scope it needs a pointer to the stack frame of the containing (in the lexical sense) routine. This cannot be assumed to have anything to do with the routine that ends up calling the passed routine.
One way to implement this is to have the code passing the routine to another routine build a stub on the stack that sets up the pointer properly before calling the real routine. The address of this stub is then passed instead of the actual routine's address.
A much better way in most cases is to pass both the address of the routine and the pointer to the stack frame, either as two separate parameters or else as a pointer to a structure that contains both. (On OpenVMS, for example, such structures were called Bound Procedure Values or BPVs.) The routine that ends up calling the passed routine then uses the pointer in the bound procedure value to set things up for the actual routine before calling it.
The main problem with this approach is that it is incompatible with how most non-lexically-scoped languages pass references to routines around. It can be done in such a way that things work as long as the passed routine doesn't actually use any variables in the outer scope, which is usually good enough. In any case, the risks of having the compiler always put code on the stack would seem to me to be much greater than this small inconvenience.
I once wrote a routine (in VAX assembly) that acted as a shim between a Pascal routine passing a procedure or functon paramter to a routine in another language. This code used the BPV to construct a stub on the stack which it then passed along. This let me call, say, an quadrature routine written in FORTRAN with the function being integrated coded in Pascal. I used this trick very sparingly, however.
As for Java, I'm not sure "interesting" is the right term. I've read through some descriptions of the tricks it uses and they frankly scare me.
http://gcc.gnu.org/onlinedocs/gccint/Trampolines.h tml
It usually involves stack execution, but that can apparently be avoided with a little extra cost. It's not language specific, but compiler-specific.
xkcd is not in the sudoers file. This incident will be reported.