IMPLEMENTATION
上传用户:ig0539
上传日期:2022-05-21
资源大小:181k
文件大小:2k
源码类别:

Ftp客户端

开发平台:

C/C++

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