Secure network software

This page isn't really being updated. Maybe I should just remove it completely.

SMTP

Postfix

• Pretty good sources
• Good and secure design
• Fast
• Exploits: local user could delete others' mail because of a design flaw (Dec 1998), DoS and bounce-scan/DDoS (1.1 series)

qmail

• DJB software (secure but ugly sources)
• Some questionable security holes

Exim

• Personally I don't like the coding style.
• Relies a lot on "large enough" buffers, but also uses dynamically growing strings in some places. With enough time you might find one buffer that isn't large enough..
• Uses signed integers in counters etc. where unsigned ones would be better/safer.
• Monolithic design - a single process that starts as root and drops privileges later.
• Exploits (quick google search): Local root exploit, Arbitrary command execution, Format string vulnerability. No, I wouldn't call it secure at all.

Sendmail X

Sendmail seems to be trying to get back into game with a rewrite. I looked at v0.0.16 sources.

• Modular design, similar to Postfix.
• Seems to have reimplemented/wrapped nearly everything from libc
• Uses dynamic strings often, but there are some hardcoded buffer sizes such as MAXHOSTNAME+16.
• Uses threads, which means locking, which may be tricky to do right and cause DoS or worse problems.
• Using variable sized function parameters isn't really good idea since compiler can't check that they're used correctly. I would have chosen other ways to implement eg. sm_rcb_putrec().
• Looks big and complex, very similar to Bind 9 (see below).
• It's confusing. The used function and macro names often make no sense until you look their description. There's lots of code which basically looks like it was just copy&pasted from 20 lines before and modified a bit. There are tons of #ifdefs. The files and functions are large. In short: I looked a lot of code and all I saw was error handling, logging, setting and looking whatever flags and IPC. The actual code logic was probably hidden somewhere around all of that.
• UPDATE: for 0.0.Alpha0.0 release: I forgot I had already looked at the code before. I browsed through the source files, skipping maybe 10-20 at a time. Every time I looked what I saw, it was either about some libc-like function but for some special sendmail-style structure (which there are many) or some incomprehencible function name full of calls to other functions with incomprehencible names. Sorry, but could you at least try to pick up naming conventions which MIGHT be understood by people who haven't carefully read through all the sources? Still, there didn't seem to be wrappers for simplest things such as easy string handling (I saw calc length + malloc() + strcpy() + strcat()).

Also see comments by Rick Moen

FTP

vsftpd

• Secure design, pretty good and very secure looking sources.
• This is exactly how C software should be written for maximal security. It's written so that it's not _possible_ to cause buffer overflows by accidental mistakes or sloppiness. All buffer management is done through few library functions which are well audited.
• One of the fastest FTP servers
• 0.0.15 version fixed a possible security issue with signal handlers.

Pure-FTPd

• "designed with security in mind" - however I don't really see such design
• 589 #ifdefs in the 1.0.12 sources - #ifdefs are ugly and make the sources unreadable.
• Code doesn't look insecure, but neither does it look secure. Buffer overflows seem to be taken care of by using snprintf() etc. and passing buffer sizes all around, but I prefer using buffers that can be grown when needed..
• Featureful
• No exploits found so far

DNS

djbdns

• DJB software (secure but ugly sources)
• Simple and easy to use
• Small and fast
• Supports IPv6 with external patch
• Doesn't support all BIND features, but everything that most users do need is well supported.
• No exploits found so far

MaraDNS

• Should be secure
• Code doesn't look too bad, but it's using a lot of gotos.
• Exploits: DoS (Jan 2002)

Bind 9

• A complete rewrite since version 8, supposedly being a lot better code. I haven't yet looked at v8 sources so can't comment that.
• Code has lots of asserts and sanity checks.
• Almost everything is wrapped over isc library. For example isc_mem_get(), isc_boolean_t, etc. Then again, they're still using "large enough" buffers and sprintf()/strcpy(), although dynamically growing buffers are used also.
• In general the code just _feels_ heavy - functions have tons of variables, some functions are huge, locks for thread safety, lots of goto jumping to deinitialization parts if something went wrong, ...
• Integer signedness seems to be used mostly correctly.
• djb has some interesting statistics about quality of code.
• Exploits: DoS

HTTP

Most HTTP servers seem to be relatively secure themselves, it's the cgi-bin and other extra modules that are dangerous.

I don't consider Apache 2 secure yet (if ever), it shows constantly in bugtraq. Also all the thread stuff sounds like it's full of holes..

IMAP

Dovecot

• My great new IMAP server :)
• Designed to be secure, should be pretty fast too
• Sources are quite good if I may say so :)
• No exploits found so far

Cyrus IMAP

• Designed to be fast, using it's own mail storage format.
• Running under one non-root account, a security flaw means getting access to every user's mails. Processes are reused so accidental information leaks could also happen between users.
• Sources aren't too bad, but it's using a lot of sprintf(), strcpy(), strcat() etc. functions that don't make it feel very safe.
• Sources are mixing signed/unsigned integers a lot, causing multiple potential security holes with systems allowing over 2GB processes.
• Exploits: 2.1.5 fixed \0 byte buffer overflow, versions up to 2.1.10 had remotely exploitable pre-login buffer overflow, sieve implementation had exploitable buffer overflows. Required SASL library up to v2.1.9 had buffer overflows.
• All string handling calls were audited by some people. I accidentally found some string handling calls in lmtpproxyd still to be exploitable after that audit. Audits don't make you secure. Use safe coding techniques.
• More holes, one being a newly introduced bug involving, once again, the ages old copy-string-to-stack-without-bounds-checking problem.

Courier IMAP

• Works with maildir format
• Takes little memory, but isn't very fast.
• Uses lots of malloc(calculate string length here) and then strcpy()+strcat() the string there. Too easy to make mistakes with that method.
• On the first look it doesn't look secure at all, especially because of the above. However I've looked through it pretty extensively and found only a single bug which allowed growing memory usage infinitely if the default ulimit -d of 64MB didn't work (eg. glibc2.3 because it mmap()s).
• Exploits: Postgresql authentication support had arbitrary SQL injection flaw because ' character in username wasn't escaped. Remote format string vulnerability if login debugging is enabled.

UW-IMAP

• Reference IMAP server implementation, written by the guy who designed IMAP protocol.
• Most of the code is actually in c-client library which is also used by at least Pine mail client.
• Code trusts very much that buffers are large enough. Changing some #defines will trigger buffer overflows.
• It doesn't use snprintf(), but rather sprintf(buf, "%100.s", ..).
• Exploits: There has been too many to list over the years.

Binc IMAP

• Written with C++.
• Doesn't write to hardly any buffers directly but uses C++ string classes etc.
• Uses mostly signed integers.
• Noticeably slower than other IMAP servers.
• No exploits found so far, but it's possible to cause it to allocate memory infinitely by just sending it data without spaces or newlines.