Oxcug
Oxcug

Reputation: 6604

Socket program seg faulted: *** stack smashing detected ***

So I have a person that I allowed to test out my Socket program and they got it to segfault with the message:

*** stack smashing detected ***: ./myProgram terminated

Which as I understand it, is a gcc compiler feature that detects when the stack gets unstable and kills the program. The problem is not the stack smashing, but the way that it happened. Apparently my program is vulnerable to remote code execution. He was connected via telnet.

I believe he used telnet to cause my socket program to segfault. What I don't know is how he did it and how to prevent it. My socket program is handling the buffering with a 1024 byte long char[]. And even if I tried with a 5 byte buffer and the message get's split up when it's over 5 bytes in that case.

So in summation I'm wondering if anyone knows how to "inject code" via telnet or some other method when the socket being connected to is custom written. And also how to prevent it from happening.

Edit:

Here's my source code: https://github.com/theMonster/ModularServer

Upvotes: 0

Views: 1100

Answers (2)

Daniel Pryden
Daniel Pryden

Reputation: 60957

In Chatroom::recievedCommand you several times allocate buffers on the stack as char tmp[1024]; and then write text into them using sprintf, with no guarantee that the data written will be less than 1024 bytes.

This is pretty much the canonical example of a buffer overrun. OWASP has a whole page explaining the dangers here, and there's also lots of existing questions about this sort of thing on Stack Overflow. A quick search turned up understanding the dangers of sprintf(…) which is probably useful as well.

Upvotes: 1

Kerrek SB
Kerrek SB

Reputation: 477060

The simple answer is that your program has a bug.

You cannot "inject code" into a correctly written program.

Fix the bug, and attacks will go away. Typically the bug is of the form that your program behaves correctly for only some kinds of input but not for others, presumably because you either don't check all possible return paths from functions or don't check conditions on data sizes and array lengths and things like that.

There are static and dynamic analysis tools that may be able to point you to a specific problem (such as Valgrind, ASan and UBSan), but mostly you need to approach programming with the right attitude, be methodical and pay sufficient attention to detail.

Upvotes: 1

Related Questions