release/src/router/vsftpd/SECURITY/IMPLEMENTATION

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