Buffer Overflow

[Effigy]

Hello all, I am curious about buffer overflow vulnerabilities in network applications. Specifically I am interested in how to prevent them. I am no expert at network programming but I do somewhat understand that many programs are susceptible to buffer overflow attacks that allow a hacker to execute remote code or crash a program.

Does anyone have an example on how to prevent this, (or for curiosity sakes demonstrate a vulnerable program and exploit of it)

Also any information on other internet hacking attacks and how they may be prevented would be appreciated.

[okasvi]

doesnt freeing memorybuffer or reallocating it work?

[va!n]

just take a look to the example posted by "tranquil"... his routine works very fine instead a lot of other posted examples!
viewtopic.php?t=12231&highlight=network

[Killswitch]

Odly enough a team of italian hackers found a buffer overflow in my Webserver application - I was dead chuffed that someone thought that my little program was important enough to break .

[Num3]

Odly enough a team of italian hackers found a buffer overflow in my Webserver application - I was dead chuffed that someone thought that my little program was important enough to break .

LOL

Now that it's hacked you should release the source code

[Killswitch]

I did, no one took any notice

[Karbon]

Preventing buffer overflows is fairly simple in theory. Never allocate a memory buffer based on data you don't directly control. Don't allocate a buffer blindly and copy data into it - check the size of the data before copying!

When using CopyMemory(*SourceMemoryID, *DestinationMemoryID, Length)

Make sure that *DestinationMemoryID points to something that can accept Length bytes of data!

Check, double check, then triple check...

[Rescator]

Good advices Karbon.

Never trust user or "outside" data.
So only use a reported filesize for reference,
but never for allocation etc.

Use a fixed size buffer, and do buffered read and handling of the data.
Always specify lengths, especially with strings, do not blindly accept binary 0 as the end marker of a string.
Specify the max length that your string buffers or data buffers can handle.
Buffer overflows is the main weakness of most software, so make sure they don't happen!

Validate numbers/info. In other words if you only accept datasize between 0 to 1024,
then make sure to check if it is not <0 >1024
Yeah, make sure you don't fall into -1 etc traps.

Do not trust the server, or a peer client software to be correct.
Max string length may be 255 for example, but a exploit might make strings that are 2048 or even half a megabyte large.
Use buffered reads, with fixed size buffers, or size limited buffers.
If the strig or data is to large, employ buffered reads,
or simply truncate (discard) the data that is beyond the limit per the standards.

And I'll repeat again. When using string functions, (yes even PureBasic's that also do checks on it's own)
specify the max size when possible.

Also remember, sometimes an attacker may not try to inject data,
they may just be attempting Denial Of Service (DOS) in some form,
causing your software to crash.

Develop each part on it's own.
That means finish oe part of tye program and move to the next.
Try to verify that data between procedures and library functions are within limits, that way if you have messed up a check somewhere the procedure will notice and either truncate the data, or set the size or value to 0.

And even more importantly, don't assume that any data is correct,
always assume that corrupt data "can" occur and ensure the program is able to deal with it.

Like program startup, do not assume that the ini file or registry entry is valid.
Always check that a value is withing the accepted range of your program.
Like for example 0 or 1 settings.

If myflag>1 or myflag<0
myflag=0
endif

rather than reading the value directly into myflag,
if you can't handle/check data validity everywhere
(due to code complexity or performance issues)
then at least make sure to "force" the data to be valid upon collecting it.
The little example above is a typical one I use for most ini/settings files,
it ensures that the data is within the range the program expect,
if myflag contained 4 for example, it would be forced to 0 automaticaly,
thus avoiding a possible crash or worse.

[Effigy]

Great Info,

Thanks all, it would be still cool to see how a buffer overflow can lead to remote execution. But I now have a great place to start securing my program.

Thanks alot!

PS. I'm writing a program that extends the usefullness of WINVNC SC the sc stands for single click. If you haven't used it, it allows remote users to initiate a remote connection from there end to you, therefore mostly by passing firewall concerns (at least at the users end) so you can take control of their PC's.

My program is just going to extend the use of that program adding features like, time tracking, remote reboots and reconnect etc.