Secure network software
This page isn't really being updated. Maybe I should just remove it
- 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
- Monolithic design - a single process that starts as root and drops
- Exploits (quick google search):
Local root exploit,
Arbitrary command execution,
Format string vulnerability.
No, I wouldn't call it secure at all.
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
- 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.
- "designed with security in mind" - however I don't really see such
- 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..
- No exploits found so far
- 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
- Should be secure
- Code doesn't look too bad, but it's using a lot of gotos.
- Exploits: DoS (Jan 2002)
- 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
- 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
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..
- 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
- 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
- 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
More holes, one being a newly introduced bug involving, once again,
the ages old copy-string-to-stack-without-bounds-checking problem.
- 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
- 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
- Exploits: Postgresql authentication support had arbitrary SQL injection
flaw because ' character in username wasn't escaped.
Remote format string vulnerability if login debugging is
- Reference IMAP server implementation, written by the guy who designed
- 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.
- Written with C++.
- Doesn't write to hardly any buffers directly but uses C++ string
- 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