February 14, 2002
In This Issue
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 strncpy, instead of strcpy, and _snprintf instead of sprintf) can prevent most buffer-overflow 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 among the worst technical problems plaguing Microsoft at the moment.

What we can learn from Microsoft's troubles is that there is no standard formula for writing secure code, and not all software vulnerabilities can be prevented in the same way. New types of vulnerabilities can arise at any time, and engineers must always be aware of the security risks that can plague their past, present, and future code. No software can ever be perfect, but proactive and continuous education about classes of vulnerabilities can help reduce the risk of unnecessary software bugs.

Mark Maiffret
Chief Hacking Officer
eEye Digital Security

News & Articles
The following articles represent the opinions of their respective authors. They do not necessarily represent the opinions of eEye Digital Security.

Newsbytes: Will Microsoft's Trustworthy Computing Sell?
"A shift in corporate strategy by Microsoft to emphasize security in its products could bomb with consumers and hurt the market for third-party security products and services, experts said today." Full Article

Computer World: Coming Retractions
"Department of Corrections: A few weeks back, I wrote about how virus problems at the U.S. District Court's offices..." Full Article

Report: Key Government Computers Remain Vulnerable
"Government computers that handle trillions of dollars in tax refunds and Social Security benefits remain vulnerable to cyber attacks." Full Article

Reader Q&A

Q: I have a very slow modem connection, and when running a scan with Retina my audits do not always finish completely. Is there something I can do to make Retina work better in my environment?

A: On a slower modem connection, users may experience delays that can result in network data transmit timeouts. If this applies to you, you can change Retina's 'Speed' setting to a lower speed to get better scan results. Adjust the Speed option under Tools -> Options.

Have a question you would like answered? Send it to versa@eEye.com, and win an eEye t-shirt if we select your question for an upcoming newsletter.

Announcements

Retina® Wins Network World's Blue Ribbon Award
In its February issue, Network World wrote: "In our testing, we reviewed products from eEye Digital Security, Nessus, Symantec, Internet Security Systems, NetIQ, Network Associates, PatchLink and Harris.
"We evaluated how each identified our network vulnerabilities; what resources it required to run and then scale to a larger network; its reporting tools; what it offered as security recommendations and autofix features; and installation and ease of use.
"eEye Digital Security's Retina is the Blue Ribbon Award winner...Retina won for speed and quick-fix features..." Full Article

Custom Filters Available for Iris™
The filters are available to all Iris users free of charge, and allow users to easily configure Iris to only capture specific network traffic. The five filters currently available are: SNMP, UPNP, AOL Instant Messenger, Nimda, and CodeRed.

Once downloaded, the filters should be placed in the Iris folder, and they will appear in Iris' Filters menu. Full Article

eEye Alert: ISS BlackICE Kernel Overflow Exploitable
A few days ago there were posts on several security mailing lists stating that BlackICE was vulnerable to a Denial of Service attack that could result in the BlackICE service crashing and/or blue-screening the remote system. We at eEye have found that the vulnerability indeed exists and is exploitable, thereby allowing an attacker to remotely compromise users of BlackICE. Full Article

Etcetera

The Year of the Bug
NIPC has put together a list of last year's software vulnerabilities, complete with vendor, operating system, common name, and risk level. Not exactly a bedtime story, but we thought some of you might find it interesting. See the complete CyberNotes PDF here: More

PCWorld.com: A History of Hacking
An oldie but a goodie. "From phone phreaks to web attacks, hacking has been a part of computing for 40 years". More

HOW TO SUBSCRIBE
To subscribe to this and other eEye newsletters, please visit: http://www.eeye.com/html/resources/newsletters/subscribe.html

FEEDBACK
The eEye newsletter staff welcomes any comments, questions or suggestions from our readers. We hope that you will not hesitate to contact us with any feedback you may have. Send all feedback to versa@eeye.com.

DISCLAIMER
The information within this newsletter may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk.

NOTICE
Permission is hereby granted for the redistribution of this newsletter electronically. It is not to be edited in any way without the express consent of eEye. If you wish to reprint the whole or any part of this newsletter in any other medium excluding electronic medium, please email versa@eeye.com for permission.