C programmers mistakes.

[Farabi]

Hi. My friend from jakarta come to my home today asking about how to made a bug exploits. I note a interesting topic on our discuss.

This bug name is buffer overflow, and also he give me an example of C code we should avoid. I cannot post the code for you and I dont remember how the code is.

First try he execute a program like this:

test.exe aaaaa

The program is work fine, no error report show. And then he execute the program like this:

test.exe aaaaaaaaaaaaa

then an error message appear:
"Instruction at 0x61616161 is invalid" or something like that.
Do you know what it mean?

If you create a C server program with a fixed allocated buffer, my friend can remote it and exploiting it for his own use.

How to exploit it is very simple based on my knowledge. By entering a value like this on the program parameter 0x6161616161[color=0ffh]xxxxxxxx[/color][color=0ff00h]yyyyyyyy[/color], you will change the EIP with yyyy value. So everytime the program have a buffer overflow error, the next instruction executed is address pointed on yyyy.

So if you made a program just make sure you use GloballAlloc and always check the length of the memory before copy it into another place of memory.

[AeroASM]

How can overflowing a memory allocation possibly change EIP?

[Eóin]

See buffer overflows to understand how they pose a security problem.

[greenant]

Microsoft, in MSDN, suggest secure string manipulation functions

Security Alert  Using this function incorrectly can compromise the security of your application. The first argument, lpString1, must be large enough to hold lpString2 and the closing '\0', otherwise a buffer overrun may occur. Buffer overruns may lead to a denial of service attack against the application if an access violation occurs. In the worst case, a buffer overrun may allow an attacker to inject executable code into your process, especially if lpString1 is a stack-based buffer. Consider using one of the following alternatives: StringCbCopy, StringCbCopyEx, StringCbCopyN, StringCbCopyNEx, StringCchCopy, StringCchCopyEx, StringCchCopyN, or StringCchCopyNEx. You should review Security Considerations: Windows User Interface before continuing.

[GregL]

I tried out using those functions in MASM32 a short while ago.

http://www.masmforum.com/simple/index.php?topic=1207.0

[hutch--]

It looks reasonably straight forward to solve any problems like this, control the length of the input to ensure that no more than a certain amount of text data can be entered into a program.

If for example this is command line which is one way to input data, if you set a buffer to 260 bytes, truncate any extra data and then test the input to see if it makes sense. If the arg is for a file name, test if the file exists.

Its normal to test or restrict input data for a program just to avoid input mistakes and this will depend on what data the app is designed to allow. If it requires numbers only for example, scan for numbers to a buffer length limit and if there are other characters or the length is too large, don't accept the input.

[sluggy]

A vast majority of buffer overflows are caused by passing buffer type variables on the stack (strings are actually buffers too). BO's can also be caused by over filling fixed length buffers that have been declared in the data sections of your code.
Overflowing alloc'ed memory is not such a problem and is far more difficult to exploit because the alloced memory is situated *above* the executing code, not below it, so usually overflowing it will just corrupt the data in the next alloced chunk should you have one. This could still cause issues, but is considerably harder to create an exploit for.

The first rule is: *never* trust input data.

[Jibz]

Buffer overflows are usually easy enough to fix, the problem is finding them. It is quite possible to make the same mistake in other languages than C too .. for example consider the ArgCl function from the MASM32 library.

[tenkey]

That's why I always state that C and ASM have the same level of security. You can forget to check bounds when needed, especially if you are too focused on efficiency or simplicity.

[Farabi]

Hi. I saw a list of OS he can remote, one of it are windows server 2000 and some type of linux server OS but I cannot remember it. And also, he is telling me about overun buffer or something. Im not too good at hacking.

[hutch--]

 :bg

Yes,

for example consider the ArgCl function from the MASM32 library.

I confess to having only written that algo a bit over 6 years ago and that it has been superceded by another that was written shortly after. With a documented command line limit of 128 bytes and a 192 byte internal stack based buffer, I cannot see any real problems with it even though it was not written in the era where stack overflows were understood as exploits.

When I get round to it I will do another command line algo that is table based to handle far longer command lines and it is not big deal to handle stack overflow exploits.

I don't see command line as a major problem with this type of exploit as to use a command line, you need to have access at the executable file to use it. It could be a problem with Windows based CGI programs as it is user input to "running" programs that are usually targets of stack overflow exploits.

[Jibz]

The finger worm was from 1988 .. the "Smashing the Stack for Fun and Profit" article was from 1996 .. I don't think buffer overflow vulnerabilities were a big secret in 1999, where they accounted for more than 50% of all major security bugs resulting in CERT/CC advisories (Viega/McGraw).

I know we've been over it before, and while it may not present much of a problem, it is still my view that in a general purpose library which potentially gets used by a lot of people, you should fix issues like this. It's not that hard to add a little bounds checking to the string copy.

Anyway .. I didn't mean to start of a lengthy discussion about this again. It's your library, and you are of course free to decide which issues are worth fixing :U.

[hutch--]

i am happy enough to fix most things if they are broken but I am not a fan of "function creep" which is something like progressive change over time to the loss of previous documented behaviour. I have seen a lot of code broken that way and I do my best not to do it. I left the older command line version in the library for exactly that reason.

What I will do when I get a bit more time to play with it is an entirely different design that is based off a table as I understand that there are changes in later Windows versions where you can pass up to 32k on the command line and while I don't see a lot of use for it, perhaps CGI, its easy enough to scan it against a table which makes the seperation of many different formats apart from space delimited arguments possible.

[Jibz]

I see .. well, backward compatibility is a good reason -- better leave it as it is then, in case there is some software out there that depends on it crashing if passed a long command line :green.

[Farabi]

Hi. I got one question. If I use ping, what software accept the data and sending back data to give sign if the test was complete?