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

Ftp客户端

开发平台:

C/C++

  1. This document describes what the vsftpd code trusts, what it doesn't trust, and
  2. the reasoning behind any trust decisions.
  3. The importance of trust and trust relationships
  4. ===============================================
  5. Imagine a largely well written and secure piece of code. Now imagine that this
  6. piece of code delegates a task to an external program, perhaps in the name of
  7. code reuse. Now, if this external program is sloppily coded and insecure, we've
  8. wasted a lot of effort making our original program secure; our erroneous trust
  9. of the buggy external program means we have a security leak, even though we
  10. were careful in _our_ code.
  11. There is a very similar situation with buggy library APIs. Imagine our secure
  12. program calling some complex library function which lets the side down by
  13. containing a security hole.
  14. Lets put some concrete examples on the two similar above considerations. We can
  15. even give examples in the context of FTP daemons.
  16. 1) External /bin/ls helper
  17. A very common operation asked of FTP servers is to provide a directory listing.
  18. Unfortunately, convention seems to be to emit the directory listing in UNIX
  19. "/bin/ls -l" format. Even the Microsoft FTP service can be observed to do this.
  20. When writing an FTP server for the UNIX platform, then, this leads to the
  21. temptation to reuse /bin/ls as a child process, to avoid having to rewrite a
  22. load of code to handle directory listings.
  23. Even more unfortunately, FTP server writers seem to want to adopt the
  24. versatility of the average /bin/ls implementation. This means they allow
  25. clients to specify arbitrary parameters to /bin/ls.
  26. By using an external /bin/ls command, we would tie the security of our FTP
  27. server to that of the /bin/ls code. Be careful not to underestimate the amount
  28. of code paths in /bin/ls which are explorable by a remote malicious user. GNU
  29. /bin/ls has a myriad of options. Some of these options are complex such as -I
  30. or the various formatting options. All it takes is a single coding flaw in the
  31. handling of one of these options, and your FTP security is in trouble.
  32. By using an external /bin/ls, you also inherit the risk of any dangerous or
  33. complex APIs it uses. For example, calls to libc's complex fnmatch() or
  34. glob() functions, which will get given arbitrary malicious user controlled
  35. data as the search patterns. Also remember that users (and sometimes remote
  36. users) can upload/create files, and filenames are a very prominent input
  37. to /bin/ls.
  38. To conclude: vsftpd has no intention of using an external /bin/ls program
  39. because of the risks outlined above. Even if I were to audit e.g. GNU
  40. fileutils /bin/ls, and also important parts of glibc, this would still leave
  41. security in an unknown state on other platforms. The solution I have employed
  42. is to write a minimal internal implementation of a /bin/ls listing generator;
  43. it's hardly difficult. As a happy side effect, this will boost performance by
  44. avoiding unneccesary fork()s and exec()s!
  45. Here's some quick data about FTP servers which tend to use external ls
  46. programs:
  47. ftp.wuftpd.org:
  48. ftp> ls --version
  49. 227 Entering Passive Mode (x.x.x.x.x.x)
  50. 150 Opening ASCII mode data connection for /bin/ls.
  51. ls (GNU fileutils) 3.16
  52. 226 Transfer complete.
  53. ftp.digital.com:
  54. ftp> ls -v
  55. 227 Entering Passive Mode (x.x.x.x.x.x)
  56. 150 Opening ASCII mode data connection for /bin/ls.
  57. /bin/ls: illegal option -- v
  58. usage: ls [ -1ACFLRabcdfgilmnopqrstux ]  [files]
  59. 226 Transfer complete.
  60. Note that /bin/ls is not the only external program invoked by common FTP
  61. servers such as wu-ftpd. wu-ftpd also has the ability to invoke "tar" and
  62. "gzip" on the fly, so there are trust relationships there too.
  63. 2) Complex library APIs
  64. vsftpd is very careful to avoid using library calls which are potentially
  65. dangerous. I would typically classify calls as dangerous if they interact
  66. with the network non-trivially, or take malicious user supplied data and
  67. start parsing it in a major way.
  68. Some examples are clearly required (vsftpd avoids using any of the following):
  69. 1) fnmatch(). This is the libc glob pattern matcher. The danger comes
  70. from the fact that the user supplies the glob pattern - "ls *.mp3" would
  71. be a simple example. Furthermore, glob pattern matching is complex and
  72. involves a lot of string handling.
  73. 2) gethostbyaddr(). This is a libc call to resolve an IP address to a hostname.
  74. Unfortunately, doing this is quite complicated. When you call gethostbyaddr(),
  75. a lot of work goes on under the covers. This usually involves making a network
  76. call out to the DNS server, and, dangerously, parsing the response.
  77. For clarity (and clarity is a very important part of security), all external
  78. APIs used by vsftpd are encapsulated within two "system interaction" files,
  79. named "sysutil.c", and "sysdeputil.c" (for the more variable/system dependent
  80. calls). This provides a convenient audit point for ascertaining which calls
  81. vsftpd trusts.
  82. vsftpd-2.0.0 introduces SSL / TLS support using OpenSSL. OpenSSL is a massive
  83. quantity of code which is essentially parsing complex protocol under the full
  84. control of remote malicious clients. SSL / TLS is disabled by default, both
  85. at compile time and run time. This forces packagers and administrators to make
  86. the decision that they trust the OpenSSL library. I personally haven't yet
  87. formed an opinion on whether I consider the OpenSSL code trustworthy.
  88. Summary
  89. =======
  90. Be very aware of what APIs and/or programs you are trusting, or you might end
  91. up creating a trust relationship which makes your program exploitable --
  92. through no direct fault of your own.