[chapp]

It's not so hard to find programs that use functions like the gets() one. I agree with you that this tutorial is incomplete, it just gives a very basic idea. However on the other side there is so much to say about BOF that it's not so easy to lay out a thread, especially because XP handles memory differently from Vista or higher for example. To be exaustive, we'd also need to talk about heap overflow.

When i'll have time i'll make a complete tutorial about this

No it isn't hard to find programs that uses gets(), you can just make one on your own. What is hard is to find programs with a considerable user base that are vulnerable. Especially since most compilers will issue warnings when using gets() and they are almost eliminated due to being low hanging fruits. The same thing is true for a lot of format string vulnerabilities.

Talking purely of vulnerabilities, the topic should not include details of operating systems and memory handling in these. A buffer overflow can occur in different areas of the memory and can be considered the same vulnerability with a memory corrupting impact.

[chapp]

It's not so hard to find programs that use functions like the gets() one. I agree with you that this tutorial is incomplete, it just gives a very basic idea. However on the other side there is so much to say about BOF that it's not so easy to lay out a thread, especially because XP handles memory differently from Vista or higher for example. To be exaustive, we'd also need to talk about heap overflow.

When i'll have time i'll make a complete tutorial about this

No it isn't hard to find programs that uses gets(), you can just make one on your own. What is hard is to find programs with a considerable user base that are vulnerable. Especially since most compilers will issue warnings when using gets() and they are almost eliminated due to being low hanging fruits. The same thing is true for a lot of format string vulnerabilities.

Talking purely of vulnerabilities, the topic should not include details of operating systems and memory handling in these. A buffer overflow can occur in different areas of the memory and can be considered the same vulnerability with a memory corrupting impact.

[lady_godiva]

No it isn't hard to find programs that uses gets(), you can just make one on your own. What is hard is to find programs with a considerable user base that are vulnerable. Especially since most compilers will issue warnings when using gets() and they are almost eliminated due to being low hanging fruits. The same thing is true for a lot of format string vulnerabilities.

Talking purely of vulnerabilities, the topic should not include details of operating systems and memory handling in these. A buffer overflow can occur in different areas of the memory and can be considered the same vulnerability with a memory corrupting impact.

I judge upon my experience and even if it is not the gets() function, it is something similar that still allows to exploit a BOF.

About OS what you said is wrong because exploiting a buffer overflow is not just about overflowing the system with a too long buffer. It also involves execution of your own code.

If you craft a BOF that works on XP for example, using the dll trick, it will not work on Vista and higher just to provide an example. So yes, to craft a BOF must have knowledge of the OS you are working with

[chapp]

No it isn't hard to find programs that uses gets(), you can just make one on your own. What is hard is to find programs with a considerable user base that are vulnerable. Especially since most compilers will issue warnings when using gets() and they are almost eliminated due to being low hanging fruits. The same thing is true for a lot of format string vulnerabilities.

Talking purely of vulnerabilities, the topic should not include details of operating systems and memory handling in these. A buffer overflow can occur in different areas of the memory and can be considered the same vulnerability with a memory corrupting impact.

I judge upon my experience and even if it is not the gets() function, it is something similar that still allows to exploit a BOF.

About OS what you said is wrong because exploiting a buffer overflow is not just about overflowing the system with a too long buffer. It also involves execution of your own code.

If you craft a BOF that works on XP for example, using the dll trick, it will not work on Vista and higher just to provide an example. So yes, to craft a BOF must have knowledge of the OS you are working with

No you are not getting my point. If you "judge from your experience" I'd love to see what recent vulnerabilities that was due to use of the gets() function that you have experienced in applications with a considerable user base. I'd guess it's a big fat zero.

You need knowledge of a given layer to exploit a vulnerability. The BOF vulnerability is corruption of memory and exploiting this is different from each platform. Causing a BOF does not require knowledge of system layout, as long as a fixed length buffer is filled with more data then it's length.

[chapp]

No it isn't hard to find programs that uses gets(), you can just make one on your own. What is hard is to find programs with a considerable user base that are vulnerable. Especially since most compilers will issue warnings when using gets() and they are almost eliminated due to being low hanging fruits. The same thing is true for a lot of format string vulnerabilities.

Talking purely of vulnerabilities, the topic should not include details of operating systems and memory handling in these. A buffer overflow can occur in different areas of the memory and can be considered the same vulnerability with a memory corrupting impact.

I judge upon my experience and even if it is not the gets() function, it is something similar that still allows to exploit a BOF.

About OS what you said is wrong because exploiting a buffer overflow is not just about overflowing the system with a too long buffer. It also involves execution of your own code.

If you craft a BOF that works on XP for example, using the dll trick, it will not work on Vista and higher just to provide an example. So yes, to craft a BOF must have knowledge of the OS you are working with

No you are not getting my point. If you "judge from your experience" I'd love to see what recent vulnerabilities that was due to use of the gets() function that you have experienced in applications with a considerable user base. I'd guess it's a big fat zero.

You need knowledge of a given layer to exploit a vulnerability. The BOF vulnerability is corruption of memory and exploiting this is different from each platform. Causing a BOF does not require knowledge of system layout, as long as a fixed length buffer is filled with more data then it's length.

[lady_godiva]

Fine then, craft a BOF for XP and one for Vista and you'll see the difference yourself. You must have at least a basic knowledge of how memory is handled, without saying that each system might use different representation of memory address (eg little endian). I'm sorry but saying that you do not need system knowledge, even in the most general case, is a big mistake.

For those application, you are free to believe me or not but surely due to professional reasons, i won't show you those applications even if they are fixed now. Please, read carefully as i said gets() like function as gets() is not the only function that can be exploited. By the way you do not need me to provide you this data. If you ever read security statics, you will see that BOF over the last 25 years are near top positions. I believe it is also pointless to say that even programs to handle SSH can be exploited with BOF.

If you know something about software enineering, you know that manteinance is the most long part of the process ranging for 5 to 15 years. So nowadays programs have in high percentage been written from 5 to 15 years ago and weather you like it or not, C and C++ were (and still are) very popular and only nowadays people pay attention to security. Despite that nowadays there are many inexperienced programmers that do not care/know about security and this is the reason why reading OWASP you see those top vulnerabilities.

[chapp]

Fine then, craft a BOF for XP and one for Vista and you'll see the difference yourself. You must have at least a basic knowledge of how memory is handled, without saying that each system might use different representation of memory address (eg little endian). I'm sorry but saying that you do not need system knowledge, even in the most general case, is a big mistake.

Code:

int main(int ac, char * av){ char buffer[8]; strcpy(buffer, av[1]); return 0; }

You are still not following my point although I am pretty sure we agree. The program above, run on ARM, MIPS, i386, AI64 or AMD64 no matter what operating system in between, will cause a buffer overflow if I run it with:
$ ./app AAAAAAAAAAAAAAAA

I would indeed supply different arguments in order to exploit it to execute arbitrary code on different systems.

For those application, you are free to believe me or not but surely due to professional reasons, i won't show you those applications even if they are fixed now. Please, read carefully as i said gets() like function as gets() is not the only function that can be exploited. By the way you do not need me to provide you this data. If you ever read security statics, you will see that BOF over the last 25 years are near top positions. I believe it is also pointless to say that even programs to handle SSH can be exploited with BOF.

I do follow regular mailing lists as FD and bugtraq as well as vulnerability databases like OSVDB and I must admit that it sure is some time ago I ran into a bof due to "gets() alike" functions.

Even though I guess you are exaggerating the 25 years it's a bit off. I know the vulnerability of a stack based buffer overflow were exploited before, but general awareness were not really big before Aleph1's article in phrack around '96. Buffer overflows in heap section was not documented until years after.

If you know something about software enineering, you know that manteinance is the most long part of the process ranging for 5 to 15 years. So nowadays programs have in high percentage been written from 5 to 15 years ago and weather you like it or not, C and C++ were (and still are) very popular and only nowadays people pay attention to security. Despite that nowadays there are many inexperienced programmers that do not care/know about security and this is the reason why reading OWASP you see those top vulnerabilities.

I don't disagree with you about BOF being one of the most common vulnerabilities, I disagree with you how they occur in modern software, even with a code base that exceeds +10 years in age. They are usually due to logic not use of standard C functions.

[lady_godiva]

We agree on how you overflow the buffer, on the rest we do not. A popular ssh software was vulnerable to overflow and that was not so long ago. More over please consider that it happens many times that organizations write their one programs so it is not so rare to find such vulnerability.

This discussion ends here as it's not the subject of the topic, if you feel like going on, pm me and i'll be happy to go on

[chapp]

double post. Will post answer here.