Hi, Warwick Brown <[email protected]> (Di 20 Okt 2015 00:47:39 CEST): > Hi All, > > I sent this to the list previously, but before I had confirmed my membership, > so please forgive me if you have already seen this.... > I'd like to report some weirdness I've experienced in case there is any > potential for impact.... > > In a recent vulnerability scan, I noticed some interesting behaviour as it > mistakenly caused my MTAs to incorrectly be marked as open relays.... > Say, I am a relay for domain1.com, When you do a RCPT command, as follows:- > RCPT TO: @domain2.com:[email protected]
Exim ignores the part preceeding and including the first ':'. If the remaining [email protected] is allowed on your host, the 250 is the expected behaviour. But, I'm not sure, if such an address is legal per the curreent RFCs. > Exim returns a 250 response, even when the source IP is not an authorised IP > and when domain2.com is not an authoritative domain. What is an 'authoritive' domain? > The interesting thing is, that if you do:- > RCPT TO: [email protected]:[email protected] > Exim correctly fails the RCPT TO command with a 500 error, This whould invalidate my statement above. But my version of exim refused such address: mx:~# exim -v -bt [email protected]:[email protected] syntax error: malformed address: :[email protected] may not follow [email protected] > But where the user-part is missing from the address, it appears that the > address is silently ignored, and the mail is then processed against address > [email protected] with no sign of anything untoward ever happening in the logs. Yes. See above, the first part is ignored, currently I do not know why. Because we follow RFCs? Because the parsing is buggy? We'll have to look at it more closely. > I know sending an email to an address with a null user-part is a bizarre and > broken thing to do, but that's what the pen-testing tool did, and it means I > have to explain my way out of a perceived vulnerability with a CVSS score of > 10 attached to it every time that tool is used by the assessor. > > So...Despite all of my efforts to modify my restricted characters acl within > my rcpt to acl chain, I was unable to make it reject the mail when the > user-part is null, and after some verification, I was able to conclusively > prove to my assessor that my MTAs were not open relays and that the MTA sent > only the mail for the authorised domain, domain1.com. Yes, it seems that the first case '@example.com:[email protected]' gets parsed into [email protected], thus you can't find it in your ACL. But, I believe there is some variable containing the complete command arguments from the current SMTP command, maybe you can check this. Best regards from Dresden/Germany Viele Grüße aus Dresden Heiko Schlittermann -- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE - ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
signature.asc
Description: Digital signature
-- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
