CmdRCPT allows relaying

[mikea-xoba]

hi folks,

i've been going through the code with a fine-toothed comb all morning, mainly to further my understanding of it as it stands [and eventually to tackle the SMTP headers issue and also to get the tests to run :-)], and one of the things i encountered was that CmdRCPT apparently allows open relaying, as long as the sender address is a known one. this behaviour could be exploited by spammers, as they already use forged email-sender addresses.

the proper behaviour would be to check if the smtp client is authenticated or not, where authentication would either be explicit (like AUTH etc), or implicit if the client's i.p. address is localhost or 127.0.0.1. this at least is how sendmail can be configured.

so i'm thinking that at the very least we need a new state variable in the Protocol interface for SMTP, which essentially says whether or not the client is connecting from localhost. we then should hard-code this behaviour into CmdRCPT right now, and later on, instead develop a pluggable set of criteria that have to be satisfied before mail is relayed, and describe that in an mbean's xml configuration.

i'll start working on the quick solution right now, and start to think about how to organize the more modular, pluggable one --- unless something like this already exists in the code, and i overlooked it.

mike

[mikea-xoba]

i wound up actually adding the code to SMTPProtocolInstance.handleAuth, to take into account the case where an unauthenticated user can send email anywhere as long as his end of the socket is a local address --- and added a new state variable to SMTPProtocolInstance to support that. also added code to allow unauthenticated mail to any domain in known domain group, which i think should also handle the case of the server acting as a legitimate relay or secondary server (i.e., when there are multiple dns MX records). unfortunately, i still can't get the junit tests to run to check all this, but at least they still compile, and my manual tests seem to validate at least the aspects of behaviour i'm aware of.

if someone wants to run some security tests on this and report back on how i actually screwed things up, i'll be glad to go in and fix my mistakes!

mike

[acoliver]

I think you're wrong, it requires you to be authenticated or to send mail to an authenticated user...

[mikea-xoba]

maybe i screwed things up --- sorry --- but hopefully we'll have a whole suite of unit tests to screen this sort of security behaviour if we don't already have them.

but i definitely noticed two aspects of behaviour that didn't make sense to me in code from before this last weekend, when i did a few things including modify this security behaviour a bit:

1. if i connect to the server from a remote machine, do a 'helo xoba.com', then 'mail from:<acoliver@badmojo>', then a 'rcpt to:<[e-mail]>'. it actually goes ahead and tries to send the mail to yahoo --- i think this is open-relay behaviour (since i connected from a remote host), even though one needs to forge a known domain using '....@badmojo'. changing the mail-from to 'mail from:<acoliver@abcd>' confirms that it denies relaying to unknown senders' domains. i added some checks in the code to prevent the relaying, by keeping track of the client's inetaddress.

2. the mail server disallows sending mail from locally connected clients (i.e., executing on same machine) except when its sender-address is from a known domain --- i changed this to be totally free (like sendmail), since the owner ostensibly owns the machine and why say 'no' to him ---
although we may want to change this back to beef up security anyway. just let me know what your thoughts are on this.

again, hope i didn't screw things up trying to modify this behaviour!

best,
mike

[acoliver]

is handle-auth turned on? (mail.sar/META-INF/jboss-service.xml)

<!-- auth-required - optional, default = true: Determines whether we require the
user to login to the SMTP server in order to send the mail. By default we
do require it. I'd rather folks say that JBMail doesn't work at all than
say its an open relay....if YOU misconfigure it you CAN make it an open
relay....Its going to warn you in big bold fat letters. This is only
required to send mail to some SMTP server outside of your domain -->
auth-requiredtrue

[acoliver]

(BTW, I'm coming back up to speed after a week out and lots of baby-related appointments. I'm working on checking into everything, just be patient....baby comes on the 18th and then I go on a vacation for two weeks. I'm hoping to get M1 ready even if we don't release it due to me not wanting to have chaos while I'm away ;-) )

[mikea-xoba]

'auth-required' was set to 'true' which definitely explains my point #2 (on 2004-03-10) --- so it seems like i reinvented the wheel and degraded the code/architecture at the same time! sorry --- i'll revert stuff back to the way it was and now i know to look in jboss-service.xml more deeply next time i consider changing something like this. indeed, i agree that configuring this kind of behaviour in the mbean xml is the right way to go, rather than hard-coding it in the java source code.

but point #1 still seems to stand as a potential security issue --- where the server relayed the mail when the sender's address had a known domain name.

but i'll go back with a fine-toothed comb over the changes i made and make sure things are ok in light of the jboss-service.xml configuration elements.

mike

[acoliver]

is this still an issue?

[acoliver]

it seems like "verify identity" was off in your setup.

[mikea-xoba]

i believe those issues are settled, although i hope i didn't introduce other ones in the process (again); security is real tricky. we probably need a bit of a code overhaul at some point in this area, and a clear set of security policies maybe in an xml doc (expanding on what we already have in our xml mbean config).

probably the best way to make sure things are ok is through a junit test, so i'm adding that to my list of things to do. if our security polices can be expressed in xml, we can also automatically test them based on that configuration too.