Like what you see? Get it in one document for easy printing!
Click Here!
Use coupon code "certiguide" to save 20%!
(Expires 2004/12/31)

Test yourself better with 300 extra Security+ questions!
Get It Here!

Custom Search

Table Of Contents  CertiGuide to Security+
 9  Chapter 1:  General Security Concepts (Domain 1.0; 30%)
      9  1.4  Attacks
           9  1.4.12  Software Exploitation

Previous Topic/Section
1.4.12  Software Exploitation
Previous Page
Pages in Current Topic/Section
Next Page
Naïve Web Applications
Next Topic/Section

Buffer Overflows

A particular type of software exploitation that frequently makes the news these days is that of a buffer overflow. Generically speaking a buffer overflow occurs when an input string is used to copy more data into a memory buffer than the program was programmed to handle. Software coders are famous for checking to see if something works and being blind to what happens “if” – in this case, the IF is, a user provided more data for one of these memory copy functions, than the programmer expected. The footnote has a great overview90. The most recent PITA virus in the buffer overflow category is Code Red91.

The most famous buffer overflow occurred on November 2, 1988. The “Morris worm” caused incredible damage by exploiting a buffer overflow condition in the UNIX program fingerd (a “daemon”, aka server service) for the popular UNIX “finger” utility.

Once a cracker has found a program with a buffer overflow problem, they can either:

  • Send large amounts of random data to the program, causing that program to crash. If the program is a server that doesn’t automatically restart, that may cause a Denial of Service condition.

  • Send specially crafted data, designed to overwrite portions of the program in memory, and alter its functionality (as did the Morris worm). If the program is running with Administrator or UNIX root privileges, this enables the attacker to cause arbitrary commands to be executed with these higher privileges. For instance, they might copy or delete files, run code to cause a worm to propagate, change the system configuration settings, etc.

Sometimes buffer overflow exploits are automated in a “rootkit” or exploit script used by a script kiddie. Other times, they’re exploited by hand, by a more skilled, programming savvy tech.

Sapphire Worm

In this book we have stressed the importance of monitoring for patches. You may be thinking something to the effect of “yeah, yeah, I’ll remember that for the Security+ test.” This is a great time to point out that we are also attempting to make sure you are ready for the real world.

Consider the following facts:

NGS Software
92 announces on the 22nd of July 2002 a software specific flaw in the very popular database MS-SQL2000. Two days later, Microsoft posts “MS02-039 Buffer Overruns in SQL Server 2000 Resolution Service Could Enable Code Execution (Q323875)93. The firm rates this as critical, and beyond the technical why should you care, if there is a patch.

Almost 6 months later eEye Digital Security posts an advisory on the 25th of January 2003 an analysis of the MS SQL Sapphire worm
94. eEye comes up with this name to make clear it is different from a previous SQL issue and states: “This worm has been dubbed the "Sapphire Worm" by eEye due to the fact that several engineers had to be pulled away from local bars to begin the investigation/dissection process.”

The next day, Sunday the 26th of January 2003, The New York Times reports in a headline filed by the Associated Press: “Attack Snarls Web Traffic, E - Mail, ATMs”. The reports details grim global reports including “Bank of America Corp. one of the nation's largest banks, said many customers could not withdraw money from its 13,000 ATM machines because of technical problems caused by the attack.” And this national bank is not alone, as the article reveals with “Customers of the Canadian Imperial Bank of Commerce in Toronto also were unable to withdraw money using ATM machines for part of Saturday, said Rick Broadhead, a technology analyst who was among those unable to get to his cash.” Want to blame lazy IT people in North America? Try again. In the same article we see…

“Millions of Internet users in South Korea were stranded; service was restored but remained slow. Problems also were reported with Finnish telephone service and Japanese Internet connections”.

The brief quotes only highlight the global nature and severity of the impact of not updating patches what we’re available for almost six months. An article in BusinessWeek suggests that this is just the beginning of “SuperWorms” Your authors are not you’re companies’ management team. We cannot force you to make keeping updates current on your systems. And if that isn’t the top priority of you’re management team, show them this text. If the message doesn’t get across, start looking for a new job. . As the footnote points out, failure to patch could leave you on the short end of a Negligence lawsuit95. If you don’t see the value in updates, you’re not ready for security, as a certification or as part of you’re work.








Previous Topic/Section
1.4.12  Software Exploitation
Previous Page
Pages in Current Topic/Section
Next Page
Naïve Web Applications
Next Topic/Section

If you find useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider buying an inexpensive PDF equivalent of the CertiGuide to Security+ from (Use coupon code "certiguide" by December 31, 2004 to save 20%!) Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $

Home - Table Of Contents - Contact Us

CertiGuide for Security+ ( on
Version 1.0 - Version Date: November 15, 2004

Adapted with permission from a work created by Tcat Houser et al. Version Copyright 2004 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.