Re: [exim-dev] Interesting behaviour

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Heiko Schlittermann
Fecha:  
A: exim-dev
Asunto: Re: [exim-dev] Interesting behaviour
Hi,

Warwick Brown <Warwick.x.Brown@???> (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:user@???


Exim ignores the part preceeding and including the first ':'.

If the remaining user@??? 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: user@???:user@???


> 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 info@???:hs@???
syntax error: malformed address: :hs@??? may not follow info@???

> 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 user@??? 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:user@???' gets
parsed into user@???, 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 ------------ -