John Rose ha scritto:
> My company has a web application hosted at an application server provider
> site. We are using James 2.3.1 to provide email functionality to our app.
> James runs as a service on a Windows 2003 server.
>
> We contracted to have a penetration test done against our application to
> determine potential vulnerabilities with our application and with our
> hosting facility. The test pointed out two issues with our James
> installation:
>
> #1
> SmtpRelayUucp : SMTP servers may perform third-party relaying on UUCP
> style addresses
*MAY*. This is not the case with JAMES.
> Some SMTP (Simple Mail Transfer Protocol) servers will allow third-party
> remailing ("relaying") when the
> attacker uses UUCP (Unix to Unix Copy) style addresses. UUCP addresses are
> those that use the '%'
> character as a delimiter, as in [EMAIL PROTECTED] This could
> allow an attacker to bounce email
> through your servers and obfuscate its true origin.
% is like any other char for james and for the SMTP RFC. So it is ok to
accept it as it may be used in local part of local and remote email
addresses.
> #2
> SMTPforgery : SMTP server allows fake hostnames in HELO
> The SMTP server was found to accept any hostname issued to it in the HELO
> command. This lack of
> authorization could allow users to more easily forge mail from your mail
> server.
>
> Are either of these two issues something to worry about and does anyone
> have any configuration changes in James that would close these
> vulnerabilities?
IMHO there's no point in checking the validity of HELO. either you trust
the HELO or you don't. And you should not. I see no point in validating it.
If you want to check that the provided HELO host exists (not sure what
does it prove) you can use checkResolvableHelo property in the
HeloCmdHandler configuration.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
