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.
Mike/List sorry to start a fire storm on DBMail security. I am very happy with
DBMail and its continued development.
I just happened to pickup a thread on another list, merits of using SQL as a
mailstore. DBMail seemed a great fit so I was talking it up a bit help raise
awareness.
The context is that someone had asked the Dovecot list about DBMail. Dovecot
responded that both were good, but that the goals of the projects were
different. He mentioned that DBMail had some SQL injection issue early on that
were corrected, but thought they might have reemerged.
I thought I'd post to the list to check... sounds like you guys have it all
handled.
Thanks again for all your hard work !!!
- Kevin
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.
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...
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?
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.
Thanks.
Kindest regards...
Mike
----- Original Message ----- From: "Geo Carncross"
<[EMAIL PROTECTED]>
To: "DBMAIL Developers Mailinglist" <dbmail-dev@dbmail.org
Sent: Thursday, June 15, 2006 10:49 AM
Subject: Re: [Dbmail-dev] Re: The Future of Email is SQL
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?
-- Internet Connection High Quality Web Hosting
http://www.internetconnection.net/
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
--
Kevin Baker
Mission Vi Inc.
[EMAIL PROTECTED]
858.454.5532
begin:vcard
fn:Kevin Baker
n:Baker;Kevin
email;internet:[EMAIL PROTECTED]
tel;work:858-454-5532
version:2.1
end:vcard
