Description: In one of their more "aggressively technical" episodes, Steve and Leo discuss the pernicious nature of software security bugs from the programmer's perspective. They explain how "the system stack" functions, then provide a detailed look at exactly how a small programming mistake can allow executable code to be remotely injected into a computer system despite the best intentions of security-conscious programmers.

This is Security Now! with Steve Gibson, Episode 39 for May 11, 2006: Buffer Overruns. Security Now! is brought to you by Astaro, makers of the Astaro Security Gateway, on the web at www.astaro.com.

And so essentially what happens is a programmer ends up relying upon the function of many subsystems that they themselves did not write. And so they're having to assume and presume – I mean, they have to – that those things are working correctly. So in many cases it's not even their fault, although their application, which relies on these subsystems, ends up bearing the brunt of responsibility because, you know, it was their application that had the problem, even though the actual flaw may have been sort of somewhere else or in their communication with these other subsystems. So this component programming model that we see more and more often is part of the problem.

You know, my programs, the stuff I write, are pretty simple. And I happen to be sort of a dinosaur, as we know, writing these things in Assembly language. To a much lesser degree I depend upon other things because I'm writing simple programs, and I'm sort of staying away from, you know, these really huge projects which are really no longer feasible for one person. We're talking in modern corporations producing programs they've got teams of programmers. And there's another problem is, when it's just me writing a program, I know all aspects of what I'm writing. I've got it outlined, I've got it in my head, you know, I wrote it all. So there's no communication problem between me and myself. But in team efforts you do have sort of, you know, this person will be writing this chunk of the system, and somebody else will be writing another chunk which is very different. And these separately written chunks have to interact. Well, they'll produce specifications typically for the way their parts fit together. But mistakes in that communication, it's like, oh, I thought you were going to this. And the problem, of course, is when these mistakes are not found, there's presumptions that people made and, again, these boundaries between separate pieces of work, whether it's a commercial component library or it's something that somebody else in your own organization working on the same project wrote. Any kind of misunderstandings can cause sort of a mismatch.

And what we're going to look at here in detail is exactly, I mean, really exactly how that happens. But so it really does – it does sort of blur the lines of responsibility. And it explains why, even with the best of intentions, I mean, even people now focused on security, if other portions of the system were written without a focus on security, which really does require a special sort of mindset, or if they were written before security was an issue and they're still being used, this is a problem.

So, I mean, a perfect example is, you know, at the beginning of the year we all tumbled around on that Windows Metafile issue. And assuming, you know, Microsoft's stance, they understood now that what they were doing before should absolutely no longer have still been done, but it was still being done. So there was old code that had been moved along from Windows 98 and NT up into modern times, where security is a much bigger issue today than it was before. And there was a gotcha, you know, in the process.

So my point is that anyone writing code is trying to get it to work. In most situations they're in a team, they're under deadline pressure, these programs always take longer to write than anyone expects, just because that's the nature of the beast. People are putting in long hours, and they're desperate to check that code in and say, okay, I'm done with my part, or this is now working. And so everything about that process is getting it to work as opposed to looking at how to break it, which is a fundamentally different, I mean, radically different way of looking at the same code. And that, of course, is the perspective of the malicious hacker who is trying to find a way into a system, trying to find a way to break code, is the hacker is looking at it not thinking how wonderful it is that it works. They're specifically looking for ways to get it not to work, ways where assumptions which the programmer had, or the team, or the programmer communicating to something they didn't write, a third-party object or module or component, where those assumptions have broken down. And in those little interstices you can get a foothold and cause security problems. That's literally what it's about.

And so let's talk about exactly what this is, how it's possible for hackers outside of a system to basically inject their code into the system. To understand this it's necessary, I mean, at the level of detail that I think people will really be fascinated by, it's necessary to understand something known as “the stack.” You know, computers have memory. And it's possible to ask the computer to give you a block of memory, sort of borrow it from the system for your own uses, for whatever purpose, like to store data in, to accept input from a user, to assemble something that you're going to send out, for whatever reason, a so-called buffer of memory. And then when you're done with it you free it, or release it back to the system.

So in the main flow of the code you call the subroutine to, for example, uppercase a buffer. It does whatever work it needs, maybe borrowing some of the memory from the program's stack as a scratchpad for doing whatever it's doing. It then releases that memory, which puts the stack pointer back where it was when it first got control. Then the subroutine returns, using the value stored on the stack, returns to where it was called from. So that's the whole mechanism.

So, okay. So imagine that some code, a program, wants to accept some data from another program, from a user, from a script running on a web page, from wherever. It wants to make sure, though, that the data that it's receiving will fit within the buffer that it's allocated. And so say the programmer says, okay – say that it's a URL that is going to be accepted at this part of the code. The programmer thinks, okay, how long can a URL probably be? Well, maybe a thousand characters. You know, that's a really long URL, even by today's standards. So the programmer allocates a thousand-character buffer by moving the stack pointer down, as we've seen, and then has access to the thousand characters from where the stack pointer is upwards. So that's sort of the programmer's scratchpad area.

Now the programmer – say that this URL has a length, it's provided with a length, and then the data. Well, the programmer checks the length that is declared to make sure that it's less than a thousand characters long to make sure that the data will fit within this buffer. And if so, then the programmer might call another subroutine to copy the provided data into the buffer. Well, if the programmer made a mistake, and just not even thinking about it was thinking that the value being provided was a signed value, which really doesn't make any sense because it makes no sense to have a negative length on data. Data is always going to be an unsigned length. So, but just because the programmer's used to typing INT, INT, INT, which stands for integer, which is inherently a signed value, instead of UINT, which is unsigned integer, if the programmer declared this value, suspected – or, sorry, expected that the value were going to be signed, or just didn't think about it, then if somebody malicious declared the value to be -5, then when the programmer compares the length to the length that's being declared for this URL to the buffer size he's allocated, 1,000, you know, is -5 less than 1,000? Well, yes, it is, if it's a signed value, because -5 is less than 1,000.

Now, back in the dawn of Windows, literally Windows 3.1, way back, you know, the early Windows, before we had graphics accelerator chips, the very clever guys who wrote GDI, the Graphics Device Interface portion of Windows, they, in order to make the display work quickly, they would put code on the stack, that is, literally, Windows would write a program to move data quickly from one place on the screen to another, back before the hardware in the display adapter would do that for them. So there is some history of code running, I mean good code, deliberate code, running on the stack. But in general, and certainly much more so in modern times, the stack should really only contain data. It ought to be temporary variables. It ought to be subroutine return addresses, as we were talking about, or buffers that are being allocated by the program for its temporary use, which it then releases. So there really isn't a reason to allow the stack to be executable.

Well, a very cool feature in the latest processor hardware from AMD and Intel is available to essentially mark the stack as non-executable code – wait a minute, sorry, non-executable memory. So that if a buffer overrun occurred, and the processor attempted to jump into the data on the stack, they would immediately throw up a system exception and not allow that to continue, thus completely shutting down the whole buffer overrun problem.

Now, this Data Execution Prevention has been available since Service Pack 2. Only the newer Intel and AMD hardware supports it. There's a sort of a weaker, software-only version which can be turned on, which provides some protection. The other problem is that there are some programs that won't run if their stack is locked down and not allowed to execute because of some of the tricks that the programmers or the compiler are playing. So there's a little bit of a transition phase here where – and Windows handles that because, if you've got one of these DEP-enabled processors, and you've got it turned on, you are able to make exceptions for known programs that have a problem with this.