Blocking Buffer Overflow AttacksAn easily avoided attack takes advantage of programming errors.by Rik FarrowNetwork Magazine11/01/99, 3:00 a.m. ET
Getting the return address to point to the right location is one part of the art of buffer overflow exploits. Commonly, an offset argument lets the attacker
try different locations merely by applying different values to adjust the position of the modified return address.
The other part covers the code itself. On Unix systems, this is relatively simple. A short program (which can be copied outright from existing exploits) executes a local program, most commonly the Unix command interpreter /bin/sh. If the attacker already has interactive access, the result often is an interpreter run with superuser privileges. If the attacker is remote, the TCP connection used to initiate the attack becomes connected to the shell program and often has superuser access.
DOING WINDOWS
The code is more complex for Windows exploits. Under Windows, doing anything requires more code than a similar Unix exploit. But attackers can take advantage of knowledge gained in writing viruses. For example, there is a way to discover the address of useful library routines that can be used to download the executable program of the attackers choice, save it as a file, then execute it, all in less than 500 bytes of code. In this case, the buffer overflow is more like the Internet Worm, in that the overflow code itself serves to download the real exploit (which might be Back Orifice or any number of the 100 or so Trojan Horses for Windows). So, while writing the Windows exploit is more difficult than writing the Unix version, the result is that an HTTP request is used to download any application the attacker desires. Victims of buffer overflow attacks may or may not notice anything amiss. On Unix systems, failed attacks often leave behind core files, the result of programs that crashed when the offset value was not correct. On Windows boxes, successful attacks might result in registry changes, the brief appearance of a window, or the invocation of a browser when the user was not expecting it. Virus checking software will pick up many of the Trojan Horses that might be installed during such an attack. Firewalls may or may not protect against these attacks. The most common firewalls used today, stateful inspection firewalls, will pass most buffer overflow exploits. Application gateway firewalls will often prevent buffer overflow exploits, but only if the application gateway was written correctly and the firewall configured to actually use the application gateway (it is optional on most firewalls and sometimes disabled because application gateways are slower and may block traffic that merely resembles an attack). Perhaps buffer overflow attacks are only fascinating to gearheads, but they are becoming boring to security professionals, who know that they can be prevented. And what can you do? Run the minimum number of services, disable automatic execution of software upon the receipt of e-mail, do not blindly start up software such as NetMeeting, and install security patches as soon as possible. Perhaps you will be lucky enough to be bored about security as well.
Resources
An article on buffer exploits, The Tao of Windows Buffer Overflows, can be found at www.cultdeadcow.com/ cDc_files/cDc-351/ . Be warned: the article contains R-rated language. Rootshell, a site you can safely visit and search for buffer overflow exploits, can be reached at www.rootshell.com . L0pht, which includes a search facility as well as some anti-hacking tools, is located at www.l0pht.com .
Rik Farrow is an independent security consultant. He can be reached at rik@ spirit.com. His Web site, www.spirit.com , contains security links and information about network and computer security courses.
|