Versa Newsletter - Feb 14, 2002 (1 of 2)

February 14, 2002

The following is a free email newsletter highlighting the latest trends and issues in network security. This newsletter is written for IT professionals, network security professionals, and those interested in learning more about the security industry.

[Please see the end of the newsletter for subscription information.]
--------------------------------------------------------------------------------


A few days ago, CERT posted a report on numerous vulnerabilities in many implementations of the SNMP protocol. Many very large vendors were affected by these vulnerabilities, including Microsoft and Cisco. We would like to warn all of our readers of the seriousness of this issue, and suggest that they examine their networks for any devices that may be using SNMP. Information and patches should be available from the individual device vendors. We also recommend the implementation of proper router and firewall rulesets that will limit the exposure of SNMP services.

SNMP is a common management protocol used by most network attached devices like routers and switches. It can also be used to get status from host computers like workstations and servers. Full details of this vulnerability are availible from CERT at http://www.cert.org/advisories/CA-2002-03.html.

We hope you enjoy our most recent newsletter, and as always we welcome any comments or suggestions you may have.

Signed,
The eEye Digital Security Team


IN THIS ISSUE

1. TECH TALK
 • The Pitfalls of Writing Global Software
 
2. NEWS AND ARTICLES
 • Newsbytes: Will Microsoft's Trustworthy Computing Sell?
 • Computer World: Coming Retractions
 • Report: Key Government Computers Remain Vulnerable
 
3. READER Q&A
 • Running a Retina® Scan Over a Slow Modem
 
4. ANNOUNCEMENTS
 • Retina® Wins Network World's Blue Ribbon Award
 • Custom Filters Available for Iris™
 • eEye Alert: ISS BlackICE Kernel Overflow Exploitable
 
5. ETCETERA
 • The Year of the Bug
 • PCWorld.com: A History of Hacking



TECH TALK

The Pitfalls of Writing Global Software
Without a doubt, a major focus within the IT industry over the past several months has been security. In the case of some software companies, corporate officers have pledged to make security a top priority, and engineers are being taught the basics of writing secure code. But even with so many eyes on security lately, how have recent vulnerabilities such as the .ida (Code Red) been able to slip by? For a handful of these vulnerabilities, the problems were not a result of poor security policies or lack of testing, but a result of a deeper technical issue that stemmed from the desire to make software truly "global".

Recent vulnerabilities of interest have left software open to buffer overflows. A "buffer overflow" results from problems in string handling, and can occur whenever a computer program tries copying a string or buffer into a buffer that is smaller than itself. If the destination buffer is overflowed sufficiently, it will overwrite various pieces of crucial system data. Most good engineers can spot the flaws that allow generic buffer overflows. Good coding practice (such as using strncy, instead of strcpy, and _snprintf instead of sprintf) can prevent most buffer-overlow vulnerabilities, and there are analysis tools to help look for these vulnerable functions among other things. Most of the knowledge about how to write buffer-overflow-free code is based on applications that deal strictly with single-byte strings, and this knowledge is sufficient to protect most existing software.

Vulnerabilities like .ida, however, were a result of the way applications handled multi-byte strings. A multi-byte string is typically used with applications that deal with many different written languages. For most languages, such as English, a software program can represent all possible characters in the alphabet with a single byte. For example the letter 'a' would translate into (hex) '/x41', 'b'into '/x42', etc. Using single-bytes to represent characters limits a language to an alphabet of 256 characters. The need for multi-byte strings arises when other languages, such as Japanese, have a more extensive alphabet (more than 256 characters) and thus require more bytes to handle all of the characters. A string representing one Japanese character may look like '/x?', therefore making the data twice as large.

Software programs have the option to store data in a multi-byte format so that the code can work for multiple languages. The name 'eeye' contains characters that can all be represented as single-byte, and when stored as single-byte looks like '/x65/x65/x79/x65'. However, a program working with multi-bytes would take the string 'eeye' and convert it to '/x00/x65/x00/x65/x00/x79/x00/x65'. Our string is now twice the size that it was.

While data created internally by the software rarely exceeds buffer limits, data supplied by the software user must always go through a series of checks to make sure the length will not exceed the size of the buffer reserved to store it. When most programmers and source code auditing tools are checking the lengths of buffers to protect from buffer overflows, the checking is done before the multi-byte conversion functions are used. Consider the following example:

---
A program has a buffer that can store 10 characters. A user tries to enter a name that is 20 characters long. The software programmers are smart enough to make sure that the user supplied data is smaller in size then the buffer they are going to move that user data to, so the program detects this and only copies the first 10 of the user's 20 character name into the buffer (and then throws away the extra 10 characters). The program detected the discrepancy correctly, preventing an overflow of the program buffer. A problem can arise, however, when the user-supplied data needs to be used elsewhere in the program, and this time the data must be in a multi-byte format. After the 10 character single-byte data is retrieved, the first step is for it to be translated (using a standard function call) this into a 20 byte multi-byte format. Now the code is double the original size, and if an attempt is made to copy the data back into the 10-character buffer, a buffer overflow occurs.
---

The known buffer overflow vulnerabilities regarding multi-byte handling problems such as this have belonged almost exclusively to Microsoft products. This is because most Microsoft products, including the core operating system functionality, were built originally for the English language but have grown to include extensive support for different languages. Here are two recent examples of vulnerabilities that dealt with multi-byte stings:
Microsoft IIS .ida Buffer Overflow
In this vulnerability, the IIS web server was taking user-supplied data and turning it into multi-byte format. The overflow occurred when IIS tried to double the size of the user supplied data and store it in a buffer that was half the size.
http://eeye.com/html/Research/Advisories/AD20010618.html
Windows XP Shell Extension Overflow
This vulnerability happened when Windows was passing user-supplied data past a certain shell URL handler, hcp://.
http://www.securityfocus.com/archive/1/241589
There have been a handful of local XP buffer overflow vulnerabilities discovered by eEye. These have not been released because they are not exploitable, and therefore are not a security risk; however, all were multi-byte buffer overflows, further illustrating that multi-byte bugs are probably the among the worst technical problems plaguing Microsoft at the moment.