First-time Buffer Overflow Attack

First-time Buffer Overflow (stack buffer overflow) Attack

That night, several server processes in a certain service crashed in a short time.

My colleague went up and found that core dump occurred when processing requests from the same IP address in Dongguan.

Well, it was strange. At that time, we first contacted our O & M colleagues to temporarily disable the connection to the IP address on several servers of the service.

I also went up and checked the core file with GDB. After reading trace back, we basically know that it is a problem when processing a type of message request. Then I checked some temporary variables at that time and understood them.

After receiving this type of request message from the client, enter the processing function. The server performs some calculation based on a field in the request message. The calculation result is placed in an array declared in a function with a length of 100.

The length of the calculated result is related to the length of the field in the request message. The longer the data in the request message, the longer the calculation result.

The debugger shows that the computing result was 576 bytes at the time, and the number of 100 bytes is obviously not assembled (normal clients do not send more than this length ), cause the stack space to be written ....

Isn't this a buffer overflow attack that I often hear about? As long as it overrides the return address of this function call, it can return and execute the attacker's code. The server-side processes basically run with the root permission. Therefore, attackers can do many things.

But fortunately, the buffer overflow is classic, and the C/C ++ pioneers also have some countermeasures. The GCC compiler has doneStack-smashing protector mechanism, insert some canary (Canary) after the single-byte array, because when you are working in the mine, the canary will be used for warning. If the canary is dead, if canary is removed, the system checks the canary before returning the function execution. If the function is tampered with, the system stops executing the program and avoids attackers from executing the code.

So this log appears in our program:

"*** Stack smashing detected ***

And the process crashes, proving that GCC protection works. The buffer overflow attack fails.

The stack-smashing protector mechanism of the GCC compiler is enabled by the compilation option-fstack-protector (or-fstack-protector-All). Before that, we did not intentionally add this compilation option, fortunately, UBUNTU
In Linux, the-fstack-Protector option is enabled by default.

Http://soc.if.usp.br/doc/gcc-4.1-doc/gcc.html:

On Ubuntu the default is-Fstack-Protector,
Turn it off use-Fno-Stack-Protector.

After the event, you can fix the problem by adding a simple length check. Because this code comes from a common basic library in the service area, I guess other server processes that are directly connected to the client also have similar problems. Although the email was copied to the dashboard, it did not attract much attention. Soon after, other groups found similar problems .....

In fact, there are places in the code that access the array at ordinary times. You can consider the boundary check to prevent similar problems from programming specifications.

Bytes -------------------------------------------------------------------------------------------------

For more blog posts, please subscribe to RSS. For more Weibo posts, please follow @ Qianli lone row nerd