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.
How can overflowing a memory allocation possibly change EIP?
See buffer overflows (http://en.wikipedia.org/wiki/Buffer_overflow) to understand how they pose a security problem.
Microsoft, in MSDN, suggest secure string manipulation functions
QuoteSecurity 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.
I tried out using those functions in MASM32 a short while ago.
http://www.masmforum.com/simple/index.php?topic=1207.0
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.
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.
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.
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.
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.
:bg
Yes,
Quote
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.
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.
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.
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.
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?
Ping uses part of the underlying socket support. In the ICMP (internet control message protocol) there's an ECHO command - this is all it does. You don't need any 'special' software, it's like TCP or UDP - you expect it to be there.
Of course, just to make things difficult, it could be disabled :bdg
So Hutch, the discussion about ArgClC being possibly exploitable was a little unclear: should we be using GetCL and 128-byte strings for command-line apps?
Are you really going to trust anything he says, at this point? He is just going to get defensive and yell at people.
Paul
Well I hope nobody needs to get defensive or anything. :toothy
ArgClC works great; no doubt about that. It's still unclear to me exactly what is being said in this thread is all, so that's why I asked. :)
Mark,
the trick is to simply check the length of the buffer supplied by GetCommandLine() before anything tries to work on the data in the buffer. A buffer overflow can only work if the data supplied is larger than an algorithms published size limit. The vast majority of command line utilities are never exposed to security threats and it is a mistake to imposed a pile of security junk when its not needed in most instances. A command line parser is a different animal to a buffer size check and a buffer size check is no more than testing for the buffer length with a zero terminated string.
I added a later version in masm32 version 9.0 called "getcl_ex" that calls the left to right argument scanner "ArgByNumber" which will handle far larger buffers than the 32k limit of a command line so if you need to track down the details of a command line based buffer overflow, it will routinely do this if you need to.
Paul Brennick,
If you want to try and snipe at me, don't do it in the Campus or it will be removed.
Okay, another time, another place.
Paul
Quote from: hutch-- on March 24, 2006, 12:18:48 AM
...and a buffer size check is no more than testing for the buffer length with a zero terminated string.
Sounds good to me, a quick & easy solution. It's hard not to be "anal" about security features in this day and age. :wink