Le vendredi 30 mai 2014 à 19:57 +0200, Paul J Stevens a écrit :
> > p_string_printf(query, "SELECT m.message_idnr, n.headername,
> > v.headervalue%s "
> > "FROM %sheader h"
> > "LEFT JOIN %smessages m ON h.physmessage_id=m.physmessage_id"
> > "LEFT JOIN %sheadername n ON h.headername_id=n.id"
> > "LEFT JOIN %sheadervalue v ON h.headervalue_id=v.id"
> > "WHERE m.mailbox_idnr = %" PRIu64 ""
> > "AND m.message_idnr %s"
> > "AND n.headername %s IN ('%s')"
> > "ORDER BY message_idnr, seq",
> > not?"":fieldorder->str,
> > DBPFX, DBPFX, DBPFX, DBPFX,
> > self->mailbox->id, p_string_str(range),
> > not?"NOT":"", bodyfetch->hdrnames);> Of course. Earlier versions of dbmail added the owner_idnr into the > mix > for that reason. But the mailbox_idnr in this case is trusted, making > such an additional join redundant. OK, let's talk about attack scenarios: * dbmail is running on "mail" dedicated server. * database is hosted on "db" a separate dedicated server. A malicious rootkit is installed on "mail" and is able to modify memory interactively (just like a gdb debugger, but no debugger is needed with a rootkit). The attacker only needs to switch the few bits of m.mailbox_idnr in the query. I have seen such rootkits. Such an attacker would have access to all data and would be able to read ALL emails. I know these are headers only, but it seems possible to read more if the SQL query is modified interactively. OKay, an attacker with a rootkit knows "db" password and has root access. Now, let's face a second situation, where the attacker has discovered a leak in dbmail (or in the OS) and is able to change interactively these few bits. The result would be the same. Now, let's face a third situation where dbmail would only have access to a limited schema, protected by a PostgreSQL user/password, as I mentioned earlier. Even in case of a leak, the attacker would only be able to read his own mail. In case of a rootkit, the main "db" password is only known by administrator and the attacker only knows his own password. I don't want to mean that dbmail is broken in C code programming (it seems well-written), but in database design, for sure. dbmail should run only on a server with enhanced security, memory protection like grsec patch and even that is not secure given that security is stuck into dbmail and should rely more on PostrgeSQL (or MySQL). The main modifications needed are: * No sharing of emails. CC and BC should result in a copy in the database. * Database user level security relying on either schemas or table prefix (which is the same). Do you know whether MySQL supports schemas like PostgreSQL or Oracle do? The problem with MySQL development is that at some point, you usually bump on non-standard features and you are bound to support the worst database in the world, an many people love it, so you have to emulate what comes standard with PostgreSQL or Oracle. And in the end, you are not even sure whether MySQL still exists as a community, as it is being bought and sold all the time. i understand the rules of supporting MySQL, but is there schema support on latest MySQL versions or do we have to emulate that with table prefix? Kind regards, Kellogs _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
