Abstract

In this work the author addresses some of the currently most dangerous security issues for Internet servers which are responsible for most of the attacks suffered by servers every day: Protocol misuse and buffer overflows. Both problems can be addressed with a single approach, which will be explained and built in the following pages: Protocol-specific TCP service wrappers.

This project started with much less ambitious goals. Originally, it pursued making a tool to help system administrators fight spam (unsolicited bulk mail, see section 3.5.1 and reference [5, Sendmail 8.9.3 con Reglas Anti-Spam]), which has become one of the major headaches of the Internet users over the last few years. This is how the idea of a protocol-specific wrapper was born: A wrapper that would monitor and, if necessary, limit the client's interaction with the server, filtering out some potentially dangerous commands (described in section 3.5.2). However, after some weeks, the author realized that this work could greatly benefit many other services if it was done as a generic, customizable wrapper.

Having worked since November 1999 in UNAM's Computer Security Department and after over three years of being a security-conscious UNIX system administrator, the author found there was a great need for such a product. History has proved that most successful attacks manage to break into a system exploiting buffer overflows --sending more data than what a program expects in any given moment, exceeding the space designed to hold it and usually overwriting vital parts of the program's image in main memory and subverting it. This kind of attacks are usually not hard to patch at the source code level, but sometimes that is not enough. The author saw the need for a proactive defense scheme to save the administrators from the disable-download-patch-enable-pray cycle, building a wrapper immune to buffer overflows, or at least a wrapper which would not compromise the entire system if successfully attacked.

When comparing the programming languages with which to do this project, using Perl was chosen over C and C++ because, albeit being a slower, non-compiled language, it has many desirable characteristics, notoriously the ability to manage the memory without exposing the programmer to make a critical mistake in such a critical part, and powerful pattern recognition techniques.

It should be noted that this work is a proof of concept; a working implementation of the suggested ideas, but it should be viewed more as an invitation for other programmers to continue working on this program or even reimplement it if a better way to do so is found than as a finished product.