Buffer Overflow

[alexander]

Well, i first heard about buffer overflows when the new NT systems were coming out, a friend of mine told me that if you sent a bunch of random data to the print port, eventually you will overfill the buffer, the port will error out and throw you to the command prompt at that box. I ofcourse knew about hacking, but as a dark art that is only accessible to the selected few super genious computer people...

Anyways, i know i should have investigated, but back in the NT times, come on, its laughable, i was like 15, and only had a PC for a few months... But since I have been generally interested in security for the past little while, the whole new world oped to me and i understood how naive i was before...

 

So what is a buffer overflow?

well, in the dawn of the age of internet there was no serious security conter measures, but in the mid nineties a paper made its day view with the hacker community, it was caled "How To Write Buffer Overflows", back then it was an unimaginable concept, yet the paper provided basic code to prove the point... amazing how fast it caught up with the hacker community, soon after, many more different design flaws were found, and to this day, more and more new techniques of exploiting design flaws are being developed.

so lets take a look at astack buffer overflow:

void some_funct(char *a)
{
   char arr[12];
   strcpy(arr, data);
}
void another_funct()
{
   some_funct(ReadDataFromNetwork(sock));
}

so one function reads the data from the network and passes it to the other one to copy it. may seem harmless, but there is a serious problem there, as you know a character array is a series of bytes followed by terminator. Still harmless, well here is where a buffer overflow comes in, remember that the network data is controlled by the haxor, what happens if we push a say 24 characters instead of 12 and let the data overflow the memory allocated for a? well, when some_funct returns it will take the overrun value in the stack, return it , return to the front of the buffer and continue execution. now, now remember that the haxor has the full control of the flow of the program since he controls tha data input, so what will commonly happen is the haxor will insert some crazy assembly code into the buffer, and when the buffer comes back to the front, it will start executing the code that that someone set up (and usually its no a hello world thing if you know what i mean)

 

so what are the conclusions we can draw from there? and what are possible defenses?

that and commenting i will leave for tomorrow, let someone else shine :confused:

 

peace and keep it safe :hyper:

[infamous]

I'm still learning my computer skills so my following question may be a little off base. At any rate, would I be correct in assuming that this procedure is somewhat like setting up a loop function whereby the process is repeated time after time until your PC melts down to the ground..................??? And wouldn't a reboot solve the problem or would one have to restore to a previous time. If that didn't work, I quess it's back to the factory patch.

[Buffy]

...would I be correct in assuming that this procedure is somewhat like setting up a loop function whereby the process is repeated time after time until your PC melts down to the ground..................???

Looks like alexander went beddybye so here's a quick response: No melting-down required. You only have to successfully do it once. If the OS/Network code is not checking for packets bigger than are expected, they'll happily write the code that takes over your computer past the "end" of the buffer, and then its sitting there so it can be executed, which if you've hit the right code, may happen rather quickly. This depends on two key things:

1. the code that is responsible for putting the incoming packets in the buffers isn't checking its data for kosherness ("checking for boundary conditions" in techie terms), and
2. having that over writing happen in a place where it will get executed.

Both of these are unbelievably common:

1. C is the language of choice for writing this stuff, and most compilers don't do checking of indexes into arrays for efficiency. Some do for debugging, but for the release code, the boundary checking is removed (you checked it thoroughly right? Who needs to check it in production where speed is essential especially when you're moving gigabits?)
2. A lot of variables you use are global (see our little discussion of the nefarious nature of globals 5508) which often means they are interspersed with code thats being executed (locals usually go on the stack, isolated from executable code).

And since there's a *lot* of old code in these operating systems that has never been checked, and *lots* of places to try to poke these buffers, there's certainly lots of opportunity for breaking and entering. When you hear about a buffer overflow being "discovered" its usually related to a specific port and/or remote procedure call, but they all use the same mechanism alexander describes above. Simple and scary.

 

So,

And wouldn't a reboot solve the problem or would one have to restore to a previous time.

Nope, because it works before you've realized anything is wrong, and it might have started wiping your disk drive within milliseconds of reception over the net....

 

Crackers are the lowest form of pond scum, :confused:

Buffy

[infamous]

Looks like alexander went beddybye so here's a quick response:

Buffy

Thanks Buffy, I must admit however, there is much about the points you have brought up which I have little or no understaniding. Never-the-less, I will check out the link you so kindly gave and see if I can learn some more about this, Thanks again.............Infy

[alexander]

here is a really good source of info about a buffer overflow: http://en.wikipedia.org/wiki/Buffer_Overflow

 

and usually no reasonable hacker would ever think about just wiping a hard drive if they discover a buffer overflow problem, come on, you want a shell to the box, its more use too...

oh and there are many buffer overflow problems with windows, mostly unix systems tend to be a lot more secure in that sense, written a bit better, but not to say that volnurabilities in software dont make it unsecure...

[Buffy]

A simpler picture might help:

 

Here's a picture of your computer memory:

        Buffer               Program code
|----------------------------||-------------------------|
v                            vv                         v
I'm a happy message00000000000Here's my code to execute

Now you see here if the program is working right, it probably only expects to get something over the network that will fill in the "Buffer" part, and not go into the "Program Code" part. But here's what happens when an evil program sends a message that is too long and "overflows the buffer":

        Buffer               Program code
|----------------------------||-------------------------|
v                            vv                         v
Garbage filled in herexxxxxxxxEvil codexxxxx to execute
^                                          ^
|-------- worm sends too long a string------|

Then when the system decides for whatever reason to jump to the beginning of the Program Code, the Nefarious Evil Code starts executing. Since code and global variables (the "Buffer" usually go together) this usually happens pretty darn quickly after you've overflowed the buffer...

 

Make any more sense?

 

Cheers,

Buffy

[Buffy]

That's a good page alexander: I'd been spacing out the stack trick, but that's one that has some OS-level protections as Unix (but I don't think Windows) prevents jumps into allocated stack space. I'm not an OS hacker though: I just drive 'em, I don't care how they *work* :confused:

 

Cheers,

Buffy

[alexander]

thanks for the picture, it is perfect, except that if you are going all the way, you may actually show some buffer information and some real assembly code, and it would be the best :naughty:

[Buffy]

thanks for the picture, it is perfect, except that if you are going all the way, you may actually show some buffer information and some real assembly code, and it would be the best :hammer:

Ha! That was for Infy's edification and I was *sure* including a bunch of octal codes would completely confuse him. :umno:

 

Its been so long since I coded in machine code or even assembler anyway.... :naughty:

 

Why do you have that row of light switches on that computer?

Buffy

[Pret]

_____Well, that, infact is a crisp outline of Buffer overflow. Something that needs to be noted here is that, technically speaking Buffer Overflows remain and will remain for ages until someome writes the OS code in higher level languages (type-safe). C, C++, etc are middle-level (my usage) languages and are type-unsafe, by which, it means these languages can be manipulated to co-ordinate, reference and move around a very large number of bits than their out-of-date memory management systems can handle.

 

_____On the other hand high-level languages viz, C# and Java are type-safe. These languages know what kind of data they are handling. More over these languages have error-handling and bounds-checking mechanisms. When a C code expects NULL from the user and the user gives some-chunk-of-data, the code goes beserk. Where as, in Java, the default catch is called and the program remains stable.

 

_____When your Windows box says, "dumb.exe has performed an illegal operation and needs to close", you have probably (succesfully, in case you are ttrying to find an exlpoit) hit a buffer overflow condition. Most Windows exploits result because of Buffer Overflows.

 

_____I guess i din't go too far talking about Windows and stuff. Got more to say and shall do so after someone comments, because, you see i'm new to this place and i shy to say, i still haven't got the drift of this community.:umno:

 

exploiting buffer overflows is infact an art! :naughty:

[Buffy]

Two quick points:

1. Boundary checking is expensive. Do one check on every buffer when you are reading a gigabit input stream with packets only a handful of bytes long and you're talking about doubling your overhead. No one wants to do this in production. So:
   
2. Even the newer languages (and C++ does indeed do this boundary checking now in most compiler implementations) have a way to *turn it off* for production.

You can be paranoid and say you want it all the time, but when push comes to shove, you'll always pick the one that lets you spend less money on hardware to support the volume you need to handle. Always.

 

Rubber meets road,

Buffy

[alexander]

at this point it is impossible to write code that may not be cesseptible to buffer overflow, it has been demonstrated with higher level languages too, VB, python, perl and java to name a few... so nobody is safe, suggestion, write safe secure code, if impossible to do so, then make it darn close...