I think the general concern of this isn't an anonymous user injecting a
message into a DBMail managed site via SMTP, but instead an IMAP user
account that might be able to get code leaked directly to the SQL engine
without being escaped.
I too am worried about this- and haven't managed to do an audit of the
parts of DBMail that I think might be involved. As a result, I run
DBMail strictly as a one user per database using SQLite, and with each
user being an unprivileged user at that.
This way, my largest attack vector could be an evildoer that deletes his
own mailbox. I don't know of any way to fix this short of disabling a
users' ability to delete mail and folders, which isn't a useful option.
On Wed, 2006-06-14 at 21:55 -0400, M. J. [Mike] OBrien wrote:
> Hi Kevin:
> Your colleague seems a tad cynical (" DBMail then seems to keep adding SQL
> injection security holes") without specifics. Not much to argue with there.
> grrrh
On this point, I'd like to point out that there are _several_ cases
where escaping has been added/moved/removed/changed in SVN since I
initially submitted the SQLite driver. Each and every one of these
places _could_ be an attack vector. I already said I didn't audit them,
did you?
Did anyone audit these things?
MySQL escaping rules are absurdly complicated- not just the PHP people,
but even the MySQL people have messed it up. Are we sure we're safe
here?
> Crafting a message that once injected by DBMail has disruptive capabilities
> is real if you have the computing power to arrive at the
> purmutation-handling SQL for an attack and in that manner you could likely
> destroy the user's account at the point of injection perhaps.
I have no idea what this means. What kind of permutation-handling SQL
are we talking about here?
> 2) For DBMail it is important to encrypt user passwords in the database and
> minimize access probability.
Won't help. They could be plaintext without impacting security SO LONG
AS untrusted users don't have access to the database.
> 3) It is also important to run DBMail programmes (daemons) as a low-priv
> user.
That may help local machine escalation, but someone who compromises the
DBMail daemons has full control of the database, and may be able to
escalate themselves further.
> 6) Always maintain a good back-up regimen for your database.
I think asking users to solve security issues by having "good backups"
is really ridiculous.
Besides the fact that most people don't have good backups (even those
that think they do- when was the last time you unspooled all of your
backups to make sure they contained what you think they contain?)-
what's to say that once restored, the host isn't compromised again and
this time- even worse?
What happens when the invaders manage to lie hidden for a long time- are
you really going to roll your email back six months because that's the
last time you _know_ your data was safe?
It's great advice- take regular backups- but it's also a cop-out.
Security issues must be fixed.
--
Internet Connection High Quality Web Hosting
http://www.internetconnection.net/
