Hello, > > 8. Has the "dbmail-smtp" branch been code reviewed by 3rd > > parties? I am concerned about the possibility of SQL Injection. > > Peer review. There was a bug in early 1.x train, but was fixed I believe.
FWIW, there is an sql-injection bug in dbmail-smtp, though I don't remember the specifics of how you trigger it. From memory it seems like you had to call dbmail-smtp with a username that had imbedded sql, which under most setups would be hard to get through the mta. There's a fix for it (in function auth_user_exists) in a patch I made last November-ish. That patch was too big (mainly because of I ran automake myself instead of having Ilja do it), and never got applied; I've been wanting to go break it up into individual patches (eg. one for security stuff, one for misc. fixes, and one for usermap support), but haven't had the time. Look for something like "dbmail-20031108-usermap.patch" and pull the pertinent parts out, if you want it. :) Of much greater concern is a similar sql-injection bug for the APOP command, fixed in that same patch. Iirc, that one took nothing special, just telnet to the box and submit an APOP command with sql embedded in the username part. I don't have any un- patched servers around to test on, but it should be something like "APOP user'; select something from somewhere where 1=1 and' <32char md5 digest>". I don't know exactly what the query looks like you're exploiting, so that sql probably doesn't work, but that's the general idea. Search that patch for "escuser" to find the fix (which was almost identical to the fix for the USER command a while back). Jn -- Jesse Norell [EMAIL PROTECTED] is not my email address; change "administrator" to my first name. --
