On Thu, 2006-06-15 at 13:45 -0400, M. J. [Mike] OBrien wrote:
> With all due respect:
>
> 1) A rant with no specifics on known security exploits, may raise attention
> and awareness but doesn't offer much.
Agreed.
> 2) Please *Do not cry wolf* unless you see and unequivocally identify a
> wolf. I have not seen any specific security breaches with DBMail in some 5
> years now (around 1.1.cant remember) although it was to do with escaping
> query input which since 5 years ago was remedied; more so recently as Aaron
> reminds us.
I'm sorry, but security is either a concern going in or it isn't. It's
not something that is bolted on later, and it's not something that is
until proven otherwise.
Security is a process.
It's a big process.
It's a huge process.
I'd say its enormous.
But don't misunderstand me, see below and you'll note that I'm not
referring to "security breaches" of any kind...
> 3) The rapid development (release early and often :o) of MySQL may leave
> some things to be desired. It may or may not be true that, "even the MySQL
> people have messed it up" ("MySQL escaping rules"), but nothing suggests
> DBMail developers have...
I just did suggest the DBMail developers have. Timo did as well.
Suggestion isn't proof- it's only that, a suggestion.
I suggest that DBMail actually get audited.
Auditing software is not about finding vulnerabilities (although that
happens very often), it's about finding out what _kind_ of
vulnerabilities are possible.
Something like this:
snprintf(query, DEF_QUERYSIZE,
"SELECT mailbox_idnr FROM %smailboxes WHERE %s"
" AND owner_idnr = '%llu'",DBPFX,
mailbox_like, user_idnr);
Might be vulnerable if:
a) snprintf is vulnerable
b) the stack were previously manipulated AND the mailbox_like string
made the query invalid at the DEF_QUERYSIZE marker (1024 bytes in trunk)
Does this mean that DBMail has security vulnerabilities? No!
But does it mean that DBMail isn't secure?
The answer is simply "it might".
Auditing the construction of mailbox_like might be one way to
demonstrate "b" is impossible, and using a custom snprintf
implementation might be a way to save "a", but as Aaron and Lars pointed
out- they could both be made moot by simply replacing the code with
something that was conscious of the problems with such a statement.
However, I think there's a better (and probably easier) approach... See
below:
> 4) Ok. My offered list of security recommendations for the Wiki is "really
> ridiculous". Would you be so kind to please write some that *are* valid?
You misunderstand.
I don't think it can be done until the security of DBMail is better
understood.
Security recommendations aren't just good advice or good thinkings,
they're specifically designed to target what bits are unsafe and why,
and hopefully, what you can do to change that.
To put it another way, it's not _your_ list of security recommendations
that are "really ridiculous", but the very idea that security problems
just "go away" once you tell people to take backups, and turn off other
services.
As I see it, there's two ways of doing this: Audit DBMail- a time
consuming process, or change DBMail such that it no longer acts as a
security boundary.
This might actually be easier- All three supported databases (in a way)
support a concept of access controls. With MySQL and Pg, each "mailbox"
could be given a separate table (unless per-row grant rights are
possible), and then it'd be the SQL servers' job. Something they've
already got to spend a lot of effort into.
This'd mean that DBMail effectively "logs in as" the database user- and
would create a 1:1 mapping between database users and imap users.
With SQLite, security would be hard to do like this- SQLite has access
control hooks, but because they'd be in-process, they wouldn't be
trusted.
Fortunately, SQLite has a unique feature that would make this possible.
I can go over it if anyone's actually interested in persuing this path.
I do understand how big of an undertaking this is- and how deep of
changes this would mean- but I think it's a good idea because (ahem)
passing the buck is always good. It would mean DBMail could have huge
overflows and overruns (almost) everywhere and no risk would be had
simply because there's no escalation.
Oh, and needless to say, that "no escalation" bit would involve DBMail
running as a non-user, chrooted in a black hole, with no light or holes
etc... :)
ON THE OTHER HAND, because it wouldn't require a redesign of anything, a
full audit _may_ be effective. The OpenBSD people seem to have done it
with Sendmail, so I suppose anything is possible.
> 5) An extensive commercial user and proponent of DBMail with a huge
> user-base would prefer not to suffer proliferation of unfounded (nor any)
> rumours of DBMail insecurity. I guess that's my real concern.
I understand that.
And while the PHB's of the world may be consoled by a lack of chatter on
the subject, Engineers and administrators alike need to know what the
thinking is on the subject.
Lots of people are very concerned with security these days- Even normal
people. And too many times we hear arguments like "Oh, you have less
vulnerabilities _reported_- we've got 99% market share, so of course
more evildoers attack us" - and sadly they are actually on to something
here:
DBMail isn't so big right now that it's being actively scrutinized. I'm
suggesting _we_ scrutinize it before evildoers do so.
I can guarantee that an audit will find interesting things in DBMail- a
good audit finds interesting things everywhere. It might not find any
ways to get root, or ways to get the dbmail user, or even the database-
I simply don't know. For all I know, it might just make DBMail crash.
--
Internet Connection High Quality Web Hosting
http://www.internetconnection.net/
