Different network applications have different methods of encapsulatingdata. One method very common with Internet protocols is a text orientedrepresentation that transmits requests and responses as lines of ASCIItext, terminated by a newline character (and usually a carriage returncharacter). Typical examples are FTP (File Transfer Protocol),SMTP (Simple Mail Transfer Protocol), or the finger protocol.
The finger service lets you obtain status information about a user accounton a remote host, such as the time of the last login, or the terminalsthe user is currently logged in on. On one hand, the service is in factinfamous for several reasons; one being that it is considered as givingaway too much local information to potential attackers. In addition,it had a security bug that was abused in what was probably thefirst widely publicized Internet security incident: the RTM Worm,named after its author, Robert T. Morris Jr.
The finger protocol works like this: the client sends a single lineof text containing the name of the user to be queried. The serverresponds with one or more lines of status output. Which sounds simpleenough.
Now the bad thing about these old implementations of the finger server(also known asfingerd, pronounced finger-dee) was that it readthe client request using thegets function. The function'sprototype looks like this:
char * gets(char *buffer);
When invoked, the function will read characters from the process' standardinput and store them inbuffer, up to the first newline, or theend of file, whichever it encounters first. Sadly, it doesn't give adamn about how big the buffer is. In fact, it cannot evenknowhow big it is, because there's no argument through which the callercan pass the buffer's maximum capacity.7.1
To make a long story short, the oldfingerd code lookedroughly like this:
doit(void){ char line[64], *sp; /* Read the first line from stdin */ if (gets(line) == NULL) return; /* Zap trailing newline if present */ if ((sp = strchr(username, '\n')) != NULL) *sp = '\0'; display(line); return;}So an attacker sending 128 characters of text to the finger servercould easily overflow theline buffer. We've discussedthe mechanics of buffer overflows and how they can be exploited inchapter ![[*]](/image.pl?url=https%3a%2f%2fweb.archive.org%2fweb%2f20100530140215im_%2ffile%3a%2fusr%2flib%2flatex2html%2ficons%2fcrossref.png&f=jpg&w=240)
to some extent. Suffice it to say herethat the RTM worm did exactly that: exploit this buffer overflow and takeover thefingerd process. In fact, the worm was so aggressivethat the traffic caused by it brought the entire Internet to a completestand-still.7.2
So how can this be done correctly? In all cases I've seen, it's enoughto replace the call togets with a call tofgets,which takes a buffer size parameter.fgets will never writemore characters than the buffer is able to hold. All it takes to fixthe buffer overflow bug above is to use the following instead of thegets call:
if (fgets(line, sizeof(line), stdin) == NULL) return; ... and so on ...
While we're on the topic offingerd, there was a secondsecurity glitch, which is not a presentation layer issue but still worthmentioning.fingerd was usually installed to run as the superuser, so anyone exploiting the buffer overflow would immediately obtainmaximum privilege on the server machine. However,fingerddoesn'tneed root privilege in order to do what it's supposedto do! Even when run as some completely unprivileged user such asnobody, it would still be able to display a user's status.So iffingerd had been configured to run as a non-privilegeduser, the buffer overflow would still have given the attacker a shellaccount on the victim host, but with a far lower impact. Making surethat a network server doesn't run with a higher privilege than absolutelyrequired is calledprinciple of least privilege. We will discussthis issue in greater detail in chapter .