> There is probably no problem to worry about. The Xforce ISS
> scanner is,
> like most such products, a fear-mongering over-zealous worry-wart that
> makes tremendous assumptions about how sendmail in particular works.
> You should simply ignore it if you do not understand the
> issue in depth.
> -----Original Message-----
> From: woods@??? [mailto:woods@most.weird.com]
> Sent: Monday, November 19, 2001 9:31 PM
> To: freelsjd@???
> Cc: exim-users@???
> Subject: Re: [Exim] request for help: CAN-1999-0531 expn exploitation
>
>
> [ On Monday, November 19, 2001 at 13:37:21 (-0500), James D.
> Freels wrote: ]
> > Subject: [Exim] request for help: CAN-1999-0531 expn exploitation
> >
> > but I am still getting the same response from the "Xforce
> ISS" scanners.
> > Since I am not using sendmail, then there appears to be a
> problem. I
> > would appreciate any solution offered.
>
> There is probably no problem to worry about. The Xforce ISS
> scanner is,
> like most such products, a fear-mongering over-zealous worry-wart that
> makes tremendous assumptions about how sendmail in particular works.
> You should simply ignore it if you do not understand the
> issue in depth.
>
> You cannot use the information provided by a generic security scanner
> unless you have a very well designed security policy and you
> know how to
> implement technical controls to enforce it. Now I am not
> trying to say
> you don't to have a properly written security policy, or that
> you don't
> know how to implement it with technical controls. I am saying however
> that blindly following the advice of any security scanner is _never_ a
> good idea, and that appears to be what you're trying to do,
> for whatever
> reason. Blindly following such advice can usually only lead
> to having a
> false sense of security, and that can be worse than no
> security at all.
> You can only use a security scanner effectively if you use it
> to monitor
> the accuracy and completeness of your security policy implementation,
> not the other way around.
>
> Note that even if you do allow the SMTP VRFY and EXPN commands there's
> probably no additional risk (though EXPN might open you up to getting
> more of your users on spammer lists, which may or may not be something
> covered by your security policy).
>
> To understand these security risks properly you have to understand
> what's really being revealed, and how this information might be
> available through other obvious sources to an attacker, and how the
> attacker might be able to use this information against your specific
> systems in particular.
>
> I.e. you need to know what's going on explicitly with how SMTP is used
> on your systems, and how information in e-mail addresses can
> be a threat
> to your system(s). Then once you have all that knowledge you can
> conduct a real and proper risk assessment that is not biased by the
> overly generic advice from a program which is at least partially
> designed explicitly to provide additional revenue streams to
> its vendor
> (though even Nessus is similarly useless in this regard).
>
> SMTP VRFY reveals nothing beyond what "RCPT TO:" will reveal,
> or indeed
> what passive listening to your external SMTP traffic will reveal, or
> even what scanning of various public Internet archives (google, google
> groups, etc.) is likely to reveal.
>
> SMTP EXPN may not reveal anything more either -- it all depends on
> exactly how you use your external mailer and whether or not
> it hosts any
> mailing lists. If you host mailing lists then SMTP EXPN may allow
> anyone to harvest those lists. At best this will make it easy for a
> spammer to collect more addresses, and at worst it might reveal all
> account-names on your system(s) (eg. if you've got an
> "office" alias or
> such that lists every user).
>
> If you really want to use "security by obscurity" to "raise
> the bar" by
> hiding account names then you _MUST_ ensure that your external mailer
> _NEVER_ delivers to local accounts and that local system account names
> CANNOT be derived by any algorithm from the mailbox names you
> expose to
> the public Internet (or any other internet which you consider a threat
> of some sort), _AND_ that there's no other way for external
> attackers to
> readily learn account names. I.e. this kind of security by obscurity
> must be only a tiny part of a very much larger policy implementation.
>
> Generally speaking it's unlikely that the total costs of turning off
> VRFY will outweigh the risks, but turning off EXPN is less costly
> overall and far more of a risk IFF you host any mailing lists on the
> server in question. This is because on monolithic mailers
> such as Exim
> (and smail and sendmail) VRFY and EXPN are very valuable debugging
> tools, not just for you but also for remote postmasters you
> do not know
> and thus the "cost" of turning them off is much higher in total than
> just the administrative overhead of changing the mailer's
> configuration.
>
> I.e. you should turn off EXPN, leave VRFY enabled, and
> completely ignore
> ISS on this matter. :-)
>
> That does appear to be how at least three of the ornl.gov mailers your
> message passed through on its way to the exim-users list are
> configured....
>
> --
> Greg A. Woods
>
> +1 416 218-0098 VE3TCP <gwoods@???>
> <woods@???>
> Planix, Inc. <woods@???>; Secrets of the Weird
> <woods@???>
