release/src/router/vsftpd/SECURITY/TRUST

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