Chapter 6

The APIs Security Holes and Its Firewall Interactions

An Application Program Interface (API) is the specific method prescribed by a computer operating system by which a programmer writing an application program can make requests of the operating system.

An API can be contrasted with an interactive user interface or a command interface as an interface to an operating system. All of these interfaces are essentially requests for system services.

As discussed on chapter 5, "Firewalling Challenges: the Advanced Web," under the sections on ISAPI and NSAPI, API provides another alternative to CGI, SSI and Server-Side Scripting for working with Web servers, creating dynamic documents, as well as providing other services via the Web.

However, I believe that for the most part, you should try to develop Web-centric application not only with APIs, but also using SSI, CGI and SSS technology, which is discussed in more details on chapter 5. The reason I say this is because I also believe there has been too much media hype lately about pseudo-standard API technology. Much of it is about its speed when compared to CGI scripts, but this information overlooks some vital facts: Your choice of webserver should be heavily influenced by its SSI, SSS, and CGI capabilities and efficiency as well as its support for advanced API programming. Otherwise, you gain nothing. O’Reilly has a great paper at their Web site (http://website.ora.com/devcorner/white/extending.html) which discusses this issue and the key characteristics and the tradeoffs of using the four main server extension techniques: SSI, SSS, CGI and API.

For now, lets take a look at the security issues involving APIs and their applications.

Sockets

A socket is one end-point of a two-way communication link between two programs running on the network. For instance, a server application usually listens to a specific port waiting for connection requests from a client. When a connection request arrives, the client and the server establish a dedicated connection over which they can communicate. During the connection process, the client is assigned a local port number, and binds a socket to it. The client talks to the server by writing to the socket and gets information from the server by reading from it. Similarly, the server gets a new local port number, while listening for connection requests on the original port. The server also binds a socket to its local port and communicates with the client by reading from and writing to it. The client and the server must agree on a protocol before data starts being exchanged.

The following program is a simple example of how to establish a connection from a client program to a server program through the use of sockets, which was extracted from Sun’s Web site at URL http://java.sun.com/docs/books/tutorial/networking/sockets/readingWriting.html. I encourage you check the site our for more in-depth information about it and the use of the API java.net.Socket, a very versatile API..

The Socket class in the java.net package is a platform-independent implementation of the client end of a two-way communication link between a client and a server. The Socket class sits on top of a platform-dependent implementation, hiding the details of any particular system from your Java program. By using the java.net Socket class instead of relying on native code, your Java programs can communicate over the network in a platform-independent fashion.

This client program, EchoTest, connects to the standard Echo server (on port 7) via a socket. The client both reads from and writes to the socket. EchoTest sends all text typed into its standard input to the Echo server by writing the text to the socket. The server echos all input it receives from the client back through the socket to the client. The client program reads and displays the data passed back to it from the server:

import java.io.*;
import java.net.*;
public class EchoTest {
public static void main(String[] args) {
Socket echoSocket = null;
DataOutputStream os = null;
DataInputStream is = null;
DataInputStream stdIn = new DataInputStream(System.in);
try {
echoSocket = new Socket("taranis", 7);
os = new DataOutputStream(echoSocket.getOutputStream());
is = new DataInputStream(echoSocket.getInputStream());
} catch (UnknownHostException e) {
System.err.println("Don't know about host: taranis");
} catch (IOException e) {
System.err.println("Couldn't get I/O for the connection to: taranis");
}
if (echoSocket != null && os != null && is != null) {
try {
String userInput;
while ((userInput = stdIn.readLine()) != null) {
os.writeBytes(userInput);
os.writeByte('\n');
System.out.println("echo: " + is.readLine());
}
os.close();
is.close();
echoSocket.close();
} catch (IOException e) {
System.err.println("I/O failed on the connection to: taranis");
}
}
}
}

Let's walk through the program and investigate the interesting bits.

The following three lines of code within the first try block of the main() method are critical--they establish the socket connection between the client and the server and open an input stream and an output stream on the socket:

echoSocket = new Socket("taranis", 7);
os = new DataOutputStream(echoSocket.getOutputStream());
is = new DataInputStream(echoSocket.getInputStream());

The first line in this sequence creates a new Socket object and names it echoSocket. The Socket constructor used here (there are three others) requires the name of the machine and the port number that you want to connect to. The example program uses the hostname taranis, which is the name of a (hypothetical) machine on our local network. When you type in and run this program on your machine, you should change this to the name of a machine on your network. Make sure that the name you use is the fully qualified IP name of the machine that you want to connect to. The second argument is the port number. Port number 7 is the port that the Echo server listens to.

The second line in the code snippet above opens an output stream on the socket, and the third line opens an input stream on the socket. EchoTest merely needs to write to the output stream and read from the input stream to communicate through the socket to the server. The rest of the program achieves this. If you are not yet familiar with input and output streams, you may wish to read Input and Output Streams.

The next section of code reads from EchoTest's standard input stream (where the user can type data) a line at a time.

EchoTest immediately writes the input text followed by a newline character to the output stream connected to the socket.

String userInput;
while ((userInput = stdIn.readLine()) != null) {
os.writeBytes(userInput);
os.writeByte('\n');
System.out.println("echo: " + is.readLine());
}

The last line in the while loop reads a line of information from the input stream connected to the socket. The readLine() method blocks until the server echos the information back to EchoTest. When readline() returns, EchoTest prints the information to the standard output.

This loop continues--EchoTest reads input from the user, sends it to the Echo server, gets a response from the server and displays it--until the user types an end-of-input character.

When the user types an end-of-input character, the while loop terminates and the program continues, executing the next three lines of code:

os.close();
is.close();
echoSocket.close();

These lines of code fall into the category of housekeeping. A well-behaved program always cleans up after itself, and this program is well-behaved. These three lines of code close the input and output streams connected to the socket, and close the socket connection to the server. The order here is important--you should close any streams connected to a socket before you close the socket itself.

This client program is straightforward and simple because the Echo server implements a simple protocol. The client sends text to the server, the server echos it back. When your client programs are talking to a more complicated server such as an http server, your client program will also be more complicated. However, the basics are much the same as they are in this program:

1. Open a socket.
2. Open an input stream and output stream to the socket.
3. Read from and write to the stream according to the server's protocol.
4. Close streams.
5. Close sockets.

Only step 3 differs from client to client, depending on the server. The other steps remain largely the same.

But knowing how a socket works, even if using reliable codes such as the above, does not necessarily makes your system immune to security holes and threats. It all will depend on the environment you’re in. Security holes generated by sockets will vary depending on what kind of threat they can allow, such as all:

• Denial of service
• The increase of privileges to local users without authorizations
• Access of remote hosts without authorization, etc.

BSD sockets

Daniel L. McDonald (Sun Microsystems, USA), Bao G. Phan (Naval Research Laboratory, USA) and Randall J. Atkinson (Cisco Systems, USA) wrote a paper entitled "A Socket-Based Key Management API (and Surrounding Infrastructure)," which can be found at the URL http://info.isoc.org/isoc/whatis/conferences/inet/96/proceedings/d7/d7_2.htm, that addresses the security concerns expressed by the Internet Engineering Task Force (IETF) in this area.

The IETF has advanced to Proposed Standard, a security architecture for the Internet Protocol [Atk95a, Atk95b, Atk95c]. The presence of these security mechanisms in the Internet Protocol does not, by itself, ensure good security. The establishment and maintenance of cryptographic keys and related security information, also known as key management, is also crucial to effective security. Key management for the Internet Protocol is a subject of much experimentation and debate [MS95] [AMP96a] [AMP96b] [Orm96]. Furthermore, key management strategies have a history of subtle flaws that are not discovered until after they are published or deployed [NS87].

McDonald, Phan and Atkinson paper proposes an environment which allows implementations of key management strategies to exist outside the operating system kernel, where they can be implemented, debugged, and updated in a safe environment. The Internet Protocol suite has gained popularity largely because of its availability in the Berkeley Software Distribution (BSD) versions of the Unix operating system. Even though many commercial operating systems no longer use the BSD networking implementation, they still support BSD abstractions for application programmers, such as the sockets API [LMKQ89]. The sockets interface allows applications in BSD to communicate with other applications, or sometimes, even with the operating system itself. One of the recent developments in BSD was the routing socket [Skl91], which allows a privileged application to alter a node's network routing tables.

This abstraction allows a BSD system to use an appropriate routing protocol, without requiring changes inside the kernel. Instead, routing protocols are implemented in user-space daemons, such as routed or gated.

Windows sockets

Windows Sockets Version 2.0, provides a powerful and flexible API for creating universal TCP/IP applications. You can create any type of client or server TCP/IP application with an implementation of Windows Sockets specification. You can port Berkeley Sockets applications and take advantage of the message-based Microsoft Windows programming environment and paradigm.

WinSock 2 specification has two distinct parts: the API for application developers, and the SPI for protocol stack and namespace service providers. The intermediate DLL layers are independent of both the application developers and service providers. These DLLs are provided and maintained by Microsoft and Intel. The Layered Service Providers would appear in this illustration one or more boxes on top of a transport service provider.

3. Java APIs

Java Enterprise APIs support connectivity to enterprise databases and legacy applications. With these APIs, corporate developers are building distributed client/server applets and applications in Java that run on any OS or hardware platform in the enterprise. Java Enterprise currently encompasses four areas: JDBCTM, Java IDL, Java RMI and JNDITM. For more information about this APIs I recommend you to check the JavaLink site at URL http://java.sun.com/products/api-overview/index.html.

Now, Joseph Bank (jbank@mit.edu), from MIT wrote a paper discussing the Java security issues. The document is available at URL http://www.swiss.ai.mit.edu/~jbank/javapaper/javapaper.html

Bank discusses the potential problems raised by executable content, such as in Java. As he comments, the advantages of executable content come from the increase in power and flexibility provided by software programs. The increased power of Java applets (the Java term for executable content) is also the potential problem. When a user is surfing the Web, they should not have to worry that an applet may be deleting their files or sending their private information over the network surreptitiously.

The essence of the problem is that running programs on a computer typically gives that program access to certain resources on the host machine. In the case of executable content, the program that is running is untrusted.

If a Web browser that downloads and runs Java code is not careful to restrict the access that the untrusted program has, it can provide a malicious program with the same ability to do mischief as a hacker who had gained access to the host machine. Unfortunately, the solution is not as simple as completely restricting a downloaded programs access to resources. The reason that one gives programs access to resources in the first place is that in order to be useful a program needs to access certain resources. For example a text editor that cannot save files is useless. Thus, if one desires to have useful and secure executable content, access to resources needs to be carefully controlled.

As Bank concludes in his paper, "the security measures of Java provide the ability to tilt this balance whichever way is preferable. For a system where security is of paramount importance, using Java does not make sense; it is not worth the added security risk. For a system such as a home computer, many people are likely to find that the benefits of Java outweigh the risks. By this same token, a number of systems are not connected to the Internet because it is a security risk that outweighs the benefits of using the Internet. Anyone that is considering using Java needs to understand that it does increase the security risk, but that it does provide a fairly good "firewall."

3. Perl modules

Briefly described, Perl is a Practical Extraction and Reporting Language (Perl). Perl for Win32 is a port of most of the functionality in Perl, with some extra Win32 API calls thrown in so that you can take advantage of native Windows functionality, and runs on Windows 95 and Windows NT 3.5 and later.

There is a module with this package, Perl for ISAPI, which is a ISAPI DLL that runs Perl scripts in process with Internet Information Server (IIS) and other ISAPI compliant web servers. This provides better performance, at the risk of some functionality.

The following is a sample code written in PerlScript, extracted from ActiveWare Internet Corp, site, at URL http://www.activestate.com/PerlScript/showsource.asp?filename=hello.asp&URL=/PerlScript/hello.asp. This sample coding gives one an example of how versatile and portable this script is.

HTML Source for: /PerlScript/hello.asp 
<%@ LANGUAGE = PerlScript %>
<html>
<HEAD>
<!-- 
 1996, Microsoft Corporation. All rights reserved.
Developed by ActiveWare Internet Corp., http://www.ActiveWare.com
-->
<TITLE> Create a MSWC.BrowserType Browser Capabilities component </TITLE>
</HEAD>
<BODY> <BODY BGCOLOR=#FFFFFF>
<!-- 
ActiveWare PerlScript sample 
PerlScript: The coolest way to program custom web solutions. 
-->
<!-- Masthead -->
<TABLE CELLPADDING=3 BORDER=0 CELLSPACING=0>
<TR VALIGN=TOP ><TD WIDTH=400>
<A NAME="TOP"><IMG SRC="PSBWlogo.gif" WIDTH=400 HEIGHT=48 ALT="ActiveWare PerlScript" BORDER=0></A><P>
</TD></TR></TABLE>
<% 
for ($i = 3; $i < 8; $i++) { 
%><font size=
<%= $i %> > "Hello World!" </font><BR> <% 
} %>
<!-- +++++++++++++++++++++++++++++++++++++
here is the standard showsource link - 
Note that PerlScript must be the default language --> <hr>
<%
$url = $Request->ServerVariables('PATH_INFO')->item;
$_ = $Request->ServerVariables('PATH_TRANSLATED')->item;
s/[\/\\](\w*\.asp\Z)//m;
$params = 'filename='."$1".'&URL='."$url";
$params =~ s#([^a-zA-Z0-9&_.:%/-\\]{1})#uc '%' . unpack('H2', $1)#eg;
%>
<A HREF="index.htm"> Return </A>
<A HREF="showsource.asp?<%=$params%>">
<h4><i>view the source</i></h4></A> 
</BODY>
</HTML>

There is a lot written about Perl out there, and it doesn’t make sense to discuss too much about Perl on a firewall book. Nevertheless, I would like to comment a little bit about Perl for Win32, by ActiveWare Internet Corp (http://www.activeware.com/), as it closely interacts with ISAPI, playing a role on APIs security.

Perl for Win32 refers to a port of the Perl programming language to the Win32 platform. Please note that Perl for Win32 does not run on Windows 3.11 and Win32s.

You should be careful with these modules, as most of them are distributed AS-IS, without any guarantee to work. If a module doesn’t work, chances are:

• Some of the functions are not provided by Perl for Win32
• Some of the UNIX tools being used are not available on Win32 platforms, or
• It makes assumptions about the way files are handled that aren't valid on Win32 platforms

Also, be careful with the Perl for ISAPI build 307, which doesn’t work, due to a problem with POST. Activeware asks that you continue to use build 306. As soon as this bug is fixed it should be announced on the Perl-Win32-Announce Mailing List.

3. CGI Scripts

Typically, CGI scripts are insecure, and Perl CGI Scripts are not exception to the rule, especially affecting Web-centric application, such as browsers.

Take for example the Netscape server. It does not use Windows NT’s File Manager's associations between file extensions and applications. Consequently, even though you may have associated the extension .pl with the Perl interpreter, Perl scripts are not recognized as such when placed in the cgi-bin directory. In order to workaround this problem, an earlier Netscape technical note suggested that you place the perl.exe file into the cgi-bin directory and refer to your scripts as /cgi-bin/perl.exe?&my_script.pl.

However, it was a bad, very bad idea! This technique allowed anyone on the Internet to execute an arbitrary set of Perl commands right onto your server by just invoking such scripts as /cgi-bin/perl.exe?&-e+unlink+%3C*%3E, which once run will erase all files stored in your serves’s current directory! This was bad news! A more recent Netscape technical note suggested then to encapsulate your Perl scripts in a .bat file. However, because of a related problem with batch scripts, this is still not safer.

Because the EMWACS, Purveyor and WebSite NT servers all use the File Manager extension associations, you can execute perl scripts on these servers without placing perl.exe into cgi-bin. They are safe from this bug.

The NCSA httpd is also affected by CGI scripts with security holes. The NCSA httpd prior to version 1.4 contain a serious security hole relating to a fixed-size string buffer, which allows for remote users to break into systems running this server by requesting an extremely long URL. Even though this is a bug already well publicized for more than couple year, many sites are still running unsafe versions of this server. From version 1.5 on the bug was fixed.

But not so long ago, it was found that the example C code (cgi_src/util.c) usually distributed with the NCSA httpd as a boiler-plate for writing safe CGI scripts omitted the newline character from the list of characters. This omission introduced a serious bug into CGI scripts built on top of this template, which caused a security hole where a remote user could exploit this bug to force the CGI script to execute any arbitrary UNIX command. This is another example of the dangers of executing shell commands from CGI scripts.

The Apache server, versions 1.02 and earlier, also contains this hole in both its cgi_src and src/ subdirectories. The patch to fix these holes in the two util.c files is not complicated. You will have to recompile the "phf" and any CGI scripts that use this library after applying the GNU patch, which can be found at URL ftp://prep.ai.mit.edu/pub/gnu/patch-2.1.tar.gz).

Here it is the source:

tulip% cd ~www/ncsa/cgi_src
tulip% patch -f < ../util.patch
tulip% cd ../src
tulip% patch -f < ../util.patch
---------------------------------- cut here ----------------------------------
*** ./util.c.old	Tue Nov 14 11:38:40 1995
--- ./util.c	 Thu Feb 22 20:37:07 1996
***************
*** 139,145 ****
l=strlen(cmd);
for(x=0;cmd[x];x++) {
! if(ind("&;`'\"|*?~<>^()[]{}$\\",cmd[x]) != -1){
for(y=l+1;y>x;y--)
cmd[y] = cmd[y-1];
l++; /* length has been increased */
--- 139,145 ----
l=strlen(cmd);
for(x=0;cmd[x];x++) {
! if(ind("&;`'\"|*?~<>^()[]{}$\\\n",cmd[x]) != -1){
for(y=l+1;y>x;y--)
cmd[y] = cmd[y-1];
l++; /* length has been increased */
---------------------------------- cut here ----------------------------------

As I mentioned on chapter 5, "Firewalling Challenges: The Advanced Web," You should not consider and ActiveX applet secure.

However, you should understand that ActiveX is only as secure as its architecture, design, implementation and environment permits. Although Microsoft never tried to state the security of ActiveX, as its use of digital signatures is intended only to the extent that it allows you to prove who was the originators of the applet. As a commented on chapter 5, if Microsoft was attempting to do any further security on ActiveX, the WinVerifyTrust API implementation would be checking the signature against the CA every time the object was accessed. But again, dealing with certificate revocation is a lot of work!

The way its implemented, this check is done once and recorded, subsequent access check first to see if its been previously authorized, and if so, it will use the object. So if a CA invalidates an object, anyone who had previously accessed the object would continue to use the malicious object without question. But you don’t have to rely on it in order to grant some level of security. As it is discussed on chapter 14, "Types of Firewalls," there are products nowadays filtering ActiveX and Java applets.

But don’t put all your eggs into a single nest, or firewall. Of course, firewalls are needed, but you will also need virus scanning, applet filters, encryption and so on. Also, you must understand that all these security technologies are simply an artifact of our inability (lack of time, knowledge, money, who knows?) to did deeper into the foundation of any security model: a complete and well elaborated security policy, which is followed and enforced. It’s usually because we don’t want to deal with it that we look for fixes such as firewalls, etc. Thus, you must understand that these products and techniques are tools, and you’ll need to come up with the "intel," the knowledge anyway.

A firewall should be for you what a word processor is for me when I write this book. It doesn’t matter if I use a Pentium Pro or a 486 PC, with a word processor such as Microsoft Word or FrameMaker to write the book. Surely these tools will help me to spell the text, write faster and so on, but if I don’t have a clear picture of what I want to accomplish with my writings, nothing will help me.

4. ActiveX DocObjects

The new ActiveX DocObjects technology allows you to edit a Word document on Internet Explorer (IE), by just selecting a hyperlink displayed by Internet Explorer (IE). After clicking on a hyperlink to a Microsoft Word document, the document is displayed in Internet Explorer's window. The Word menus and toolbars are displayed along with those from Internet Explorer, as shown on Figure 06.1, extracted from MacMillam/Sams.Net site at URL http://www.mcp.com/sams/books/156-4/pax11.htm#I21.

This is what Microsoft calls visual editing, where Microsoft Word becomes activated in Internet Explorer's window. The editing functions of both applications coexist on the Internet completely intact.

You can benefit greatly from this type of "online" document management and editing. It gives you a much greater maintenance capability, which doesn't exist for most file formats. The problem of distributing your documentation is also alleviated merely by putting the documents on the Web.

This technology is intended for use in both Internet Explorer 3.0 and in the Office95 Binder for visually editing various file formats. The ActiveX DocObject technology uses a modified menu-sharing technique that more closely resembles the data's own standalone native editing application.

What you should be careful here is that by clicking on a hyperlink to open a Word document on the Web could trigger a malicious applet. The same is true for Adobe’s PFD files. When you click on a link or filename on the Web, you don’t know what this document contains, or even if it will open a Word document.

3. Distributed Processing

Distributed Processing (DP) is the process of distribution of applications and business logic across multiple processing platforms, which implies that processing will occur on more than one processor in order for a transaction to be completed. Thus, the processing is distributed across two or more machines and the processes are most likely not running at the same time, as each process performs part of an application in a sequence.

Often the data used in a distributed processing environment is also distributed across platforms.

Don’t confuse distribute processing with cooperative processing, which is the computing which requires two or more distinct processors to complete a single transaction. Cooperative processing is related to both distributed and client/server processing. It is a form of distributed computing where two or more distinct processes are required to complete a single business transaction. Usually, these programs interact and execute concurrently on different processors.

Cooperative processing can also be considered to be a style of client/server processing if communication between processors is performed through a message passing architecture.

Lets take a look at some examples of it.

4. XDR/RPC

XDR/RPC are routines used for describing the RPC messages in XDR language. They should normally be used by those who do not want to use the RPC package directly. These routines return TRUE if they succeed, FALSE otherwise.

XDR routines allow C programmers to describe arbitrary data structures in a machine-independent fashion. Data for remote procedure calls (RPC) are transmitted using these routines.

4. RPC

The rpc file is a local source containing user readable names that can be used in place of RPC program numbers. The rpc file can be used in conjunction with or instead of other rpc sources, including the NIS maps "rpc.byname" and "rpc.bynumber" and the NIS+ table "rpc".

The rpc file has one line for each RPC program name. The line has the following format:

name-of-the-RPC-program RPC-program-number aliases

Items are separated by any number of blanks and/or tab characters. A "_" indicates the beginning of a comment; characters up to the end of the line are not interpreted by routines which search the file.

RPC-based middleware is a more general-purpose solution to client/server computing than database middleware. Remote procedure calls are used to access a wide variety of data resources for use in a single application.

Messaging middleware takes the RPC philosophy one step further by addressing the problem of failure in the client/server system. It provides synchronous or asynchronous connectivity between client and server, so that messages can be either delivered instantly or stored and forwarded as needed.

Object middleware delivers the benefits of object-oriented technology to distributed computing in the form of object request brokers. ORBs package and manage distributed objects, which can contain much more complex information about a distributed request than an RPC or most messages and can be used specifically for unstructured or nonrelational data.

4. COM/DCOM

Database middleware as mentioned above, is used on database-specific environments. It provides the link between client and server when the client application that accesses data in the server's database is designed to use only one database type.

TP monitors have evolved into a middleware technology that can provide a single API for writing distributed applications. Transaction-processing monitors generally come with a robust set of management tools that add mainframe-like controls to open distributed environments.

Proprietary middleware is a part of many client/server development tools and large client/server applications. It generally runs well with the specific tool or application environment it is a part of, but it doesn't generally adapt well to existing client/server environments, tools, and other applications.

There are other technologies such as CORBA, ILU that also supports database middleware. For more information check the middleware glossary of LANTimes at http://www.lantimes.com/lantimes/95aug/508b068a.html.