On Tue, 10 Apr 2001, Mike Gleason wrote: > NcFTPd Server for UNIX from NcFTP Software is not vulnerable to the > pathname globbing buffer overflow described by NAI COVERT Labs advisory > (COVERT-2001-02) (which is also documented in CERT Advisory CA-2001-07). > > Additionally, NcFTPd Server is not vulnerable to the globbing > denial-of-service bug mentioned recently (March 16) on BUGTRAQ. Hi, If we're playing "I'm not vulnerable", then can I join in? :) vsftpd[1] is not vulnerable, because 1) It contains a minimal internal pattern matcher, which uses a secure string handling API. 2) It does not use the underlying operating system's glob() at all. In fact because of point 2) above, vsftpd is safe even on systems with buggy glob() such as OpenBSD etc. For a while now, the security documentation has specifically commented on the risks of using glob(). This episode raises two secure coding issues which I believe deserve a wide audience. 1) Errant string handling/buffer overflows are a solved problem. The key here is to abstract string and buffer manipulations behind a buffer API. A well designed buffer API will be harder to use incorrectly (i.e. cause an overflow) than it is to use correctly. Also, your buffer handling code is localised to one place rather than scattered all over your code. This makes verification of correctness easier. This is not a new idea. qmail employs this technique with obvious success. 2) Carefully assess what external code you are trusting. FTP servers using glob() is a great example here. glob() is a complex function involving lots of parsing and buffer manipulation. It has a sprawling API. Exposing this API to the network for remote users to prod at was always likely to cause trouble on some implementations. Cheers Chris [1] ftp://ferret.lmh.ox.ac.uk/pub/linux/vsftpd-0.0.15.tar.gz
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 01:06:32 PDT