A Bit of History

A Bit of History

Before I discuss canonicalization issues in depth and show how you can handle such problems, let s look at some past canonicalization vulnerabilities, which are described in the following sections.

Bypassing AOL Parental Controls

America Online (AOL) 5.0 added parental controls so that parents could disallow their children from accessing certain Web sites. When a user typed a URL in the browser, the software checked the Web site name against a list of restricted sites, and if it found the site on the list, access to that site was blocked. Here s the flaw: if the user added a period to the end of the host name, the software allowed the user to access the site. My guess is that the vulnerability existed because the software did not take into consideration the trailing dot when performing a string compare against the list of disallowed Web sites, and the software stripped out invalid characters from the URL after the check had been made.

The bug is now rectified. More information on this vulnerability can be found at www.slashdot.org/features/00/07/15/0327239.shtml.

Bypassing Napster Name Filtering

Bypassing the Napster filters is my favorite canonicalization bug because it s so nontechnical. Unless you were living under a rock in early 2001, you ll know that Napster is a music-swapping service that was taken to court by the Recording Industry Association of America (RIAA), which viewed the service as piracy. A U.S. federal judge ordered Napster to block access to certain songs, which Napster did. However, this song-blocking was based on the name of the song, and it wasn t long before people realized how to bypass the Napster filters: simply by giving the song a name that resembles the song title but that is not picked up by the filters. For example, using the music of Siouxsie and the Banshees as an example, I might rename Candyman as AndymanCay (the pig latin version), 92 degrees as 92 degree$, and Deepest Chill as Deepest Chi11. This is a disclosure vulnerability because users who should not have access to files do have access. In this case, Napster s lack of a secure canonicalization method for filenames resulted in the inability to enforce a court-mandated security policy.

You can read more about this issue at news.cnet.com/news/0-1005-200-5042145.html.

Bypassing eEye s Security Checks

This example is ironic because the vulnerabilities were found in a security product, SecureIIS, designed to protect Microsoft Internet Information Services (IIS) from attack. Marketing material from eEye (www.eeye.com) describes SecureIIS like so:

SecureIIS protects Microsoft Internet Information Services Web servers from known and unknown attacks. SecureIIS wraps around IIS and works within it, verifying and analyzing incoming and outgoing Web server data for any possible security breaches.

Two canonicalization bugs were found in the product. The first related to how SecureIIS handled specific keywords. For example, say you decided that a user (or attacker) should not have access to a specific area of the Web site if he entered a URL query string containing action=delete. An attacker could escape any character in the query string to bypass the SecureIIS settings. Rather than entering action=delete, the attacker could enter action=%64elete and obtain the desired access. %64 is the hexadecimal representation of the letter d.

The other bug related to how SecureIIS checked for characters used to traverse out of a Web directory to other directories. For example, as a Web site developer or administrator, you don t want users accessing a URL like www.northwindtraders.com/scripts/process.asp?file=../../../winnt/repair/sam, which returns the backup Security Accounts Manager (SAM) database to the user. The traversal characters are the two dots (..) and the slash (/), which SecureIIS looks for. However, an attacker can bypass the check by typing www.northwindtraders.com/scripts/process.asp?file=%2e%2e/%2e%2e/%2e%2e/winnt/repair/sam. As you ve probably worked out, %2e is the escaped representation of the dot in hexadecimal!

You can read more about this vulnerability at www.securityfocus.com/bid/2742.

Vulnerability in Apple Mac OS X and Apache

The version of the Apache Web server that ships with Apple s Mac OS X operating system contains a security flaw when Apple s Hierarchical File System Plus (HFS+) is used. HFS+ is a case-insensitive file system, and this foils Apache s directory-protection mechanisms, which use text-based configuration files to determine which data to protect and how to protect it.

For example, the administrator might decide to protect a directory named scripts with the following configuration file to prevent scripts from being accessed by anyone:

<Location /scripts>     order deny, allow     deny from all </Location> 

A normal user attempting to access http://www.northwindtraders.com/scripts/index.html will be disallowed access. However, an attacker can enter http://www.northwindtraders.com/SCRIPTS/index.html, and access to Index.html will be allowed.

The vulnerability exists because HFS+ is case-insensitive, but the version of Apache shipped with Mac OS X is case-sensitive. So, to Apache, SCRIPTS is not the same as scripts, and the configuration script has no effect. But to HFS+, SCRIPTS is the same as scripts, so the protected index.html file is fetched and sent to the attacker.

You can read more about this security flaw at www.securityfocus.com/archive/1/190036.

Zones and the Internet Explorer 4 Dotless-IP Address Bug

Security zones, introduced in Internet Explorer 4, are an easy way to administer security because they allow you to gather security settings into easy-to-manage groups. The security settings are enforced as the user browses Web sites. Each Web page is handled according to specific security restrictions depending on the page s host Web site, thereby tying security restrictions to Web page origin.

Internet Explorer 4 uses a simple heuristic to determine whether a Web site is located in the more trusted Local Intranet Zone or in the less trusted Internet Zone. If a Web site name contains one or more dots, such as http://www.microsoft.com, the site must be in the Internet Zone unless the user has explicitly placed the Web site in some other zone. If the site has no dots in its name, such as http://northwindtraders, it must be in the Local Intranet Zone because only a NetBIOS name, which has no dots, can be accessed from within the local intranet. Right? Not quite!

This mechanism has a wrinkle: if the user enters the IP address of a remote computer, Internet Explorer will apply the security settings of the more restrictive Internet Zone, even if the site is on the local intranet. This is good because the browser will use more stringent security checks. However, an IP address can be represented as a dotless-IP address, which can be calculated by taking a dotted-IP address that is, an address in the form a.b.c.d and applying the following formula:

Dotless-IP = (a 16777216) + (b 65536) + (c 256) + d

For example, 192.168.197.100 is the same as 3232286052. If you enter http://192.168.197.100 in Internet Explorer 4, the browser will invoke security policies for the Internet Zone, which is correct. And if you enter http://3232286052 in the unpatched Internet Explorer 4, the browser will notice no dots in the name, place the site in the Local Intranet Zone, and apply the less restrictive security policy. This might lead to a malicious Internet-based Web site executing code in the less secure environment.

More information is available at www.microsoft.com/technet/security/bulletin/MS98-016.asp.

Internet Information Server 4.0 ::$DATA Vulnerability

I remember the IIS ::$DATA vulnerability well because I was on the IIS team at the time the bug was found. Allow me to go over a little background material. The NTFS file system built into Microsoft Windows NT and later is designed to be a superset of many other file systems, including the Apple Macintosh, which supports two sets of data, or forks, in a disk-based file. These forks are called the data and the resource forks. (You can read more about this at support.microsoft.com/support/kb/articles/Q147/4/38.asp.) To help support these files, NTFS supports multiple-named data streams. For example, you could create a new stream named test in a file named Bar.txt that is, bar.txt:test by using the following code:

char *szFilename = c:\\temp\\bar.txt:test"; HANDLE h = CreateFile(szFilename, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); if (h == INVALID_HANDLE_VALUE) { printf( Error CreateFile() %d", GetLastError()); return; } char *bBuff = Hello, stream world!"; DWORD dwWritten = 0; if (WriteFile(h, bBuff, lstrlen(bBuff), &dwWritten, NULL)) { printf( Cool! ); } else { printf( Error WriteFile() %d", GetLastError()); }

This example code is also available on the companion CD in the folder Secureco\Chapter 8\NTFSStream. You can view the contents of the file from the command line by using the following syntax:

more < bar.txt:test

You can also use the echo command to insert a stream into a file and then view the contents of the file:

echo Hello, Stream World! > bar.txt:test more < bar.txt:test

Doing so displays the contents of the stream on the console. The normal data in a file is held in a stream that has no name, and it has an internal NTFS data type of $DATA. With this in mind, you can also access the default data stream in an NTFS file by using the following command line syntax:

more < boot.ini::$DATA

Figure 8-1 outlines what this file syntax means.

Figure 8-1

The NTFS file system stream syntax.

An NTFS stream name follows the same naming rules as an NTFS filename, including all alphanumeric characters and a limited set of punctuation characters. For example, two files, john3 and readme, having streams named 16 and now, respectively, would become john3:16 and readme:now. Any combination of valid filename characters is allowed.

Back to the vulnerability. When IIS receives a request from a user, the server looks at the file extension and determines what it should do with the request. For example, if the file ends in .asp, the request must be for an Active Server Pages (ASP) file, so the server routes the request to Asp.dll for processing. If IIS does not recognize the extension, the request is sent directly to Windows for processing so that the contents of the file can be shown to the user. This functionality is handled by the static-file handler. Think of this as a big default switch in a switch statement. So if the user requests Data.txt and no special extension handler, called a script map, associated with the .txt file extension is found, the source code of the text file is sent to the user.

The vulnerability lies in the attacker requesting a file such as Default.asp::$DATA. When IIS evaluates the extension, it does not recognize .asp::$DATA as a file extension and passes the file to the operating system for processing. NTFS determines that the user requested the default data stream in the file and returns the contents of Default.asp, not the processed result, to the attacker.

You can find out more about this bug at www.microsoft.com/technet/security/bulletin/MS98-003.asp.

DOS Device Names Vulnerability

As you might know, some filenames in MS-DOS spilled over into Windows for backward-compatibility reasons. These items are not really files; rather, they are devices. Examples include the serial port (aux) and the printer (lpt1 and prn). In this vulnerability, the attacker forces Windows 95 and Windows 98 to access the device. When Windows attempts to interpret the device name as a file resource, it performs an illegal resource access that usually results in a crash.

You can learn more about this vulnerability at www.microsoft.com/technet/security/bulletin/MS00-017.asp.

Sun Microsystems StarOffice /tmp Directory Symbolic-Link Vulnerability

I added this vulnerability because symbolic-link vulnerabilities are extremely common in Unix and Linux. A symbolic link (symlink) is a file that only points to another file; therefore, it can be considered another name for a file. Unix also has the hard-link file type, which is a file that is semantically equivalent to the one it points to. Hard links share access rights with the file they point to, whereas symlinks do not share those rights.

	You can create hard links in Windows 2000 by using the CreateHardLink function.

For example, /tmp/frodo, a symlink in the temporary directory, might point to the Unix password file /etc/passwd or to some other sensitive file. If the permissions on /tmp/frodo are low and allow anyone to write to it, a user can write to the link and actually overwrite the password file!

On startup, Sun s StarOffice creates a directory named /tmp/soffice.tmp, which allows anyone to do anything to it. In Unix parlance, the access mask is 0777, which is just as bad as Everyone (Full Control). A malicious user can create a symlink, /tmp/soffice.tmp, to any target file owned by another user, and, if the second user runs StarOffice, the target of the symlink will become 0777. As a result, if the directory containing this target is accessible by the attacker, the attacker can do whatever he wants with the target file, including read it, write to it, or delete it. Imagine if the target file were some sensitive encryption key or perhaps a private document the attacker would have access to it all!

Learn more about this bug at www.securityfocus.com/bid/1922.

Many other canonicalization vulnerabilities exist, including those listed in Table 8-1.

Table 8-1 More Canonicalization Bugs

Vulnerability	URL	Comments
Oracle Web Listener URL vulnerability	www.securityfocus.com/bid/841	Escaping URL characters allows access to restricted files.
Disclosure of source code with Unify ServletExec	archives.neohapsis.com/archives/bugtraq/2000-11/0285.html	Escaping URL characters allows access to restricted files.
Arbitrary file retrieval using Allaire Inc. JRUN 2.3	www.foundstone.com/cgi-bin/display.cgi?Content_ID=230	Access arbitrary files on a Web server using JRUN.
Long vs. short filename vulnerabilities	www.cert.org/advisories/CA-1998-04.html	Access files using the short filename (FAT 8.3) representation of a long filename.

Almost all of the canonicalization bugs I ve discussed occur when user input is passed between multiple components in a system. If the first component to receive user input does not fully canonicalize the input before passing the data to the second component, the system is at risk.

	All of the canonicalization issues exist because an application, having determining that a request for a resource did not match a known pattern, defaulted to an insecure mode.

	If you make security decisions based on the name of a file, you will get it wrong!