Thread: When your code crashes

What happens when you write code In C and your computer crashes. I run xp and i get that msg box that tells me this program has perforemed an illegal and must shut down.

I'm wonderign because I heard that In C when your code isn't tight, it can write to parts of the memory its not supposed to. Does this mean It can erase data in certain parts of your memory and if so which part. Can it overite parts already in use? Can you lose data. Stuff like that.

I know In linux your compiler will tell you it has a segmentation fault and won't allow you to do continue. So I was just wondering.

On the same note. Playing around with '\a' in a line of C code one time.
actaully seemed to changed the voulum prompt on my box. It never went away until i installed XP again.

So in closing. C is a dangerous language, but just how can it compromise your system???
Thanks

>> What happens when you write code In C and your computer crashes. I run xp and i get that msg box that tells me this program has perforemed an illegal and must shut down. <<

You might be interested to know that you can type drwtsn32 in the run box to get more information.

>> I'm wonderign because I heard that In C when your code isn't tight, it can write to parts of the memory its not supposed to. <<

Yep, it can do that. However, in NT/2000/XP it can typically only hit memory belonging to the current process. But see below.

>> Does this mean It can erase data in certain parts of your memory and if so which part. Can it overite parts already in use? Can you lose data. Stuff like that. <<

Yes, all of that can and does happen. Just typically not totally by accident. Putting crafted data in a buffer overflow can often allow a user to execute the code of their choice. This includes installing spyware, deleting your files, acting as a spam zombie, attacking other computers or simply formatting your harddisk.

>> So in closing. C is a dangerous language, but just how can it compromise your system??? <<

Yes C can be an extremely dangerous language. Thankfully however, it is fairly difficult to unknowingly cause damage when writing a program that you use on your own machine. But install a network enabled program on a few million machines and you can be guaranteed that buffer overruns are going to be exploited in a not so nice way.

All of this applies to nix as much as windows. A segmentation fault or the windows equivalent, an access denied exception(code 5) should be a flag that there is a potential security issue in your program.

That is some scary stuff

anyone have any links about info like this. Like how to write secure code, how a user can put injections of their own in your code and do damage to you os and such? I'd be really interested to know about it.

should I back up my hd when practicing C then. Just in Case? I'm only half joking, seriously should I?

Well you should start by reading this
http://www.dwheeler.com/secure-programs/

Originally Posted by caroundw5h

That is some scary stuff

anyone have any links about info like this. Like how to write secure code, how a user can put injections of their own in your code and do damage to you os and such? I'd be really interested to know about it.

should I back up my hd when practicing C then. Just in Case? I'm only half joking, seriously should I?

Writing safe C applications is really hard and you can almost be sure to make a few mistakes here and there. The best protection is probably to have others look through the code.
Most bufferoverflow attacks use forged strings that lack a terminating \0. This means the function reading in the string will continue to write data behind the buffers' reserved space on the stack. The first thing it will overwrite is the functions return address. An attacker will try to overwrite the address with one that points on the stack itself where the malicious string is located (or i.e. if it's a login function, will probably let it point to a location after login). After the data is read in the function will continue, but not return to where it should.

Of course, in reality it is not that easy. The base stack address depends on a few other factors, i.e. environment variables, the programs path/parameterlist and others. If there is enough space on the stack, an attacker can overcome this by prefixing the malicious code with a lot of noop operations.

Depending on your OS, it might help to use allocated memory. It's location is more random and it is unlikely to come anywhere close to the desired return address.
Also, try not to use potentially dangerous functions like strcpy on unreliable data (i.e. data from the network). Also note that not even strncpy is safe. It only guarantees the input to be truncated after n bytes - it will however not append a terminating \0 if the input was longer than n. This cannot be exploitet to run attacker code, but it can be used to shut down the attacked network service (the service will segfault on Linux boxes, possibly eating a lot of memory before dying). This would be a DOS attack. Defense against it is not easy, but there is software available that protects your stack either by makeing sure that the memory location of the stack is marked as non-executable or by randomizing the location of the stack. So it's still possible to attack and bring down the application, but not to execute malicious code.

Thanks a lot for the input guys. it'll come in helpful.

Start here (more articles in the contents on the left, the article on integer manipulation should be read by all programmers).

Its funny to see microsoft advocate safe coding practices. I'm not bashing them I'm sure its just their haste to get their products to market faster. seriously.