Writing Secure Applications

for RuBoard

It seems like a simple statement, but software developers don't intend to write code with security problems. No one that I have worked with has admitted to intentionally writing security problems into their code. But, as we all know, software security holes appear all too often. According to the SecurityFocus vulnerability database (http://www.securityfocus.com/vulns/stats.shtml), around 100 security vulnerabilities have been reported each month since May of 2000. Almost everyone agrees there is room for improvement across the whole software industry.

NOTE

There are numerous places to read about software security vulnerabilities. Some industry-wide resources include the following:

• The SANS (System Administration, Networking, and Security) Institute at http://www.sans.org

• CERT (Computer Emergence Response Team) at http://www.cert.org

• SecurityFocus at http://www.securityfocus.com

• The CVE (Common Vulnerabilities and Exposures) Project at http://cve.mitre.org

In addition to these sites, some vendors provide information about security vulnerabilities and patches for their products. Some examples are

• Microsoft ”http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/current.asp

• Apple ”http://www.apple.com/support/security/security_updates.html

• RedHat ”http://www.redhat.com/support/alerts

• Sun ”http://supportforum.sun.com/salerts

Software security holes actually can be benign . They only become dangerous when exposed to untrusted code or people. If I have a computer that never connects to a network, never runs code I don't control, and is never operated by untrusted users, software security holes are probably of little concern. Of course, this is an idealized world where most of us don't live. For a majority of computer users, the rise of networked computing and the Internet has been a huge catalyst for making software security a vital concern.

The following types of software security problems have been rampant in recent years :

• Insecure default configurations

• Buffer overflows

• Canonicalization errors

• Information leaks

• Denial-of-service vulnerabilities

Insecure Default Configurations

According to the SANS Institute's list of 20 most critical Internet security vulnerabilities (Version 2.100, http://www.sans.org/top20.htm), the worst software vulnerability is that many default configurations of operating systems and applications are insecure.

Sometimes, what one person considers an insecure default configuration is considered to be adequate by someone else. In the software security community, it is preferred to limit functionality in default installations. However, some software publishers consider usability to be more important in certain cases, so additional features are enabled by default.

Some default configuration security problems include the following:

• CVE-2000-0869 ”SuSE Linux 6.4 has a problem with its install of Apache 1.3.12. It enables WebDAV, which allows remote users to list directory contents that shouldn't normally be possible.

• CVE-1999-0415 ”Certain Cisco routers enable an administrative HTTP server by default. This allows the owners and remote attackers to modify the router's configuration without sufficient authentication.

• Some versions of several different applications have default users and passwords. Examples include WWWBoard and Red Hat's Piranha Virtual Server. If the defaults are never changed, anyone with access to an application host can access the applications, often as administrators.

Buffer Overflows

Buffer overflows are one of the most publicized software security problems today. The Common Vulnerabilities and Exposures list (http://cve.mitre.org) contains hundreds of specific software vulnerabilities caused by buffer overflows. The list of affected products is huge. It is fair to say that few (if any) mainstream operating systems or applications are free from all buffer overflows.

A buffer overflow occurs when software allocates a slot in memory (a buffer) to hold some data and then writes more data to that slot than it has space (it overflows its buffer). These overflows can occur anywhere in memory, although they are most dangerous when they occur on the stack in architectures such as x86. Often, buffer overflows just produce access violations when they are hit accidentally while running an application. However, the results of an overflow can be unpredictable depending on where memory is overwritten, how much memory is overwritten, and what the new data is.

The first widespread buffer overflow vulnerability was the Internet Worm. It was much like Nimda and other recent worms in that it propagated quickly from server to server, although this was the first such worm, occurring all the way back in 1988. Even though this was a well-known event at the time with Internet users, buffer overflows were not widely recognized to be a security problem until the mid to late 1990s. They started to become a widespread problem after Aleph One wrote the whitepaper "Smashing the Stack for Fun and Profit" (which is available at http://downloads.securityfocus.com/library/P49-14.txt) in 1996. Other similar documents were written and published over the next couple of years that helped raise awareness about buffer overflows.

Buffer overflows are primarily a problem with software written in C and C++. The reason for this is that these very popular computer languages do not require strong bounds checking. More precisely, because the standard libraries do not have strong bounds checking, many programs written in C or C++ have to take care to use the library safely.

Examples of reported buffer overflows include the following:

• Microsoft Advisory MS01-033 "Unchecked Buffer in Index Server ISAPI Extension Could Enable Web Server Compromise" ”This is one of the bugs in Windows that was exploited by the Nimda virus. A feature of IIS is that it allows extensions to be added to the Web server via ISAPI extensions. In this case, the Index Server's extension had a buffer overflow that was exploitable by remote users.

• CERT Advisory CA-2000-06 "Multiple Buffer Overflows in Kerberos Authenticated Services" ”This was actually a set of buffer overflows in the widely used Kerberos authentication package originally written at MIT. The code for this software was open sourced and available for years before the problems were found.

• CERT Advisory CA-2001-15 "Buffer Overflow In Sun Solaris in.lpd Print Daemon" ”The print daemon on multiple versions of Solaris had a buffer overflow that allowed remote users to execute arbitrary code on the system.

Canonicalization Errors

Canonicalization is the process by which paths to resources are normalized to a common format. For example, C:\temp\abc.txt and C:\temp\..\temp\abc.txt would both have the same canonical form. However, if some software treats them differently, security problems can occur. For example, take a Web server that doesn't properly canonicalize user requests . If it is only supposed to allow access to files in the C:\ wwwroot directory, it might be easy to circumvent that restriction by issuing a request for http:// servername /../path_to_databases/creditcards.db .

One particular problem with canonicalization errors is that they often occur outside of an application's "security" code. Unless care is taken to write secure software in an entire application, hard-to-detect problems like this can easily arise.

Some examples of reported canonicalization errors are as follows :

• Microsoft Advisory MS98-003 "File Access Issue with Windows NT Internet Information Server (IIS)" ”The NTFS file system allows files to have multiple "streams," or storage areas. The default stream of a file is called $DATA . If a Web client issued a request for a page with an appended ::$DATA , the text of the Web page was shown instead of having the server process the Web page. For ASP pages with embedded passwords or other business logic, this was quite dangerous.

• CERT Vulnerability Note VU#758483 "Oracle 9i Application Server PL/SQL module does not properly decode URL" ”A problem exists in the Oracle 9i Application Server that allows unauthenticated users to read arbitrary files on the host server. URLs are not properly decoded by the server, so specially formed requests bypass certain security checks in the application server.

• Microsoft Advisory MS98-004 "Unauthorized ODBC Data Access with RDS and IIS" ”This defect involved Web clients sending special strings to an IIS machine with RDS (Remote Data Service) components . Essentially, the Web client could issue arbitrary commands to a database server through IIS.

Information Leaks

Information leaks come in many forms and degrees of severity. They may be as trivial as exposing the name and version of the operating system on which a Web server is running or as damaging as reading your customers' credit card numbers from a database. It can be hard to know what information someone might try to gain from an application, though as a general rule, exposing the minimum amount of information as necessary is best.

A primary reason to limit information exposure is that malicious hackers will often try to glean information about potential targets before actually launching an attack. For example, they may try to gather a list of computers or usernames on an internal network they want to attack.

Some examples of information leaks include the following:

• Checkpoint Firewall-1 Information Leak ”Firewall-1 uses a piece of software called SecureRemote. SecureRemote has the ability to send an entire network topology to trusted clients. Unfortunately, the default setting of SecureRemote on Filewall-1 allowed network topology data to be sent to unauthenticated clients.

• Web server banners ”Almost all Web servers will print an informational banner by default when a client makes a connection. This banner usually identifies the software package (and possibly operating system and version) of the Web server.

• CERT Advisory CA-2001-02 "Multiple Vulnerabilities in BIND" ”BIND, a popular DNS server package, had a vulnerability where a remote user could discover the contents of environment variables on the server.

Denial-of-Service Vulnerabilities

Denial-of-service attacks are being seen more often as additional computers are added to the Internet. The increase in the number of computers both adds potential targets and potential attackers.

Certain classes of denial-of-service attacks are harder to defend against than others. "Standard" denial-of-service attacks are caused by one computer sending a large number or special kind of network packets to one machine. Distributed denial-of-service attacks are caused by many computers simultaneously flooding one computer with network packets. In some cases, a victim of a standard denial-of-service attack can simply ignore all requests from a certain location, thereby defeating the attack. However, there are currently few ways to fend off a distributed denial-of-service attack.

Some types of standard denial-of-service attacks are caused by software faults. For example, some network protocols involve a handshake involving a few exchanges of data. If memory is allocated at the beginning of a handshake but not released quickly, a malicious hacker could send a continuous stream of beginning handshakes. This could cause so many resources to be allocated by the victim that they can no longer perform standard functions.

Examples of denial-of-service vulnerabilities caused by software faults include the following:

• CERT Advisory CA-1996-26 "Denial-of-Service Attack via ping" ”The "ping" utility is normally a helpful tool to help diagnose network connectivity problems. However, several vendors had problems with their TCP/IP stacks that would cause an operating system to lock up when they received certain types of packets. In particular, specially crafted packets sent by "ping" from other machines could cause denial-of-service problems. This was colloquially known as the "ping of death."

• CERT Advisory CA-2001-18 "Multiple Vulnerabilities in Several Implementations of the Lightweight Directory Access Protocol (LDAP)" ”A group of researches tested multiple products that use the LDAP protocol. Many of the tested products would hang or crash when the team sent specially malformed LDAP packets.

• Microsoft Advisory MS98-007 "Potential SMTP and NNTP Denial-of-Service Vulnerabilities in Microsoft Exchange Server" ”If a remote user sent specially crafted data to a Microsoft Exchange server, its mail and/or news service could be shut down.

for RuBoard