45 lines
2.2 KiB
Plaintext
45 lines
2.2 KiB
Plaintext
This document details a few steps and decisions taken to ensure vsftpd is free
|
|
of common implementation flaws.
|
|
|
|
Tackling the buffer overflow
|
|
============================
|
|
|
|
Probably the most common implementation flaw causing security problems is the
|
|
buffer overflow. Buffer overflows come in many shapes and sizes - overflows
|
|
onto the stack, overflows off the end of dynamically malloc()'ed areas,
|
|
overflows into static data areas. They range from easy to spot (where a user
|
|
can put an arbitrary length string into a fixed size buffer), to very
|
|
difficult to spot - buffer size miscalculations or single byte overflows. Or
|
|
convoluted code where the buffer's definition and various usages are far
|
|
apart.
|
|
|
|
The problem is that people insist on replicating buffer size handling code
|
|
and buffer size security checks many times (or, of course, they omit size
|
|
checks altogther). It is little surprise, then, that sometimes errors creep
|
|
in to the checks.
|
|
|
|
The correct solution is to hide the buffer handling code behind an API. All
|
|
buffer allocating, copying, size calculations, extending, etc. are done by
|
|
a single piece of generic code. The size security checks need to be written
|
|
once. You can concentrate on getting this one instance of code correct.
|
|
|
|
From the client's point of view, they are no longer dealing with a buffer. The
|
|
buffer is encapsulated within the buffer API. All modifications to the buffer
|
|
safely go through the API. If this sounds familiar, it is because what vsftpd
|
|
implements is very similar to a C++ string class. You can do OO programming
|
|
in C too, you know ;-)
|
|
|
|
A key point of having the buffer API in place is that it is MORE DIFFICULT to
|
|
abuse the API than it is to use it properly. Try and create a buffer memory
|
|
corruption or overflow scenario using just the buffer API.
|
|
|
|
|
|
Unfortunately, secure string/buffer usage through a common API has not caught
|
|
on much, despite the benefits it brings. Is it under publicised as a solution?
|
|
Or do people have too much sentimental attachment to strcpy(), strlen(),
|
|
malloc(), strcat() etc? Of notable exception, it is my understanding that at
|
|
least the rather secure qmail program uses secure buffer handling, and I'd
|
|
expect that to extend to all Dan Bernstein software. (Let me know of other good
|
|
examples).
|
|
|