[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sendmail & localhost rDNS



Re,

Lupe Christoph wrote:
On Monday, 2009-08-10 at 14:35:06 +0200, Bernhard R. Link wrote:
* Lupe Christoph <lupe@lupe-christoph.de> [090810 13:53]:
On Monday, 2009-08-10 at 13:46:38 +0200, Thomas Liske wrote:

last week, there was an article on heise security about MTAs[1] which relay mails for hosts having a reverse resolution of 'localhost'. Doing a small test shows that sendmail on etch seems to be vulnerable, too. I need to have a localhost RELAY line in my access file (which is not default AFAIK).

Will there be a DSA on this issue, since it seems to turn Sendmail installations with allowed localhost RELAYing into Open Relays?

Are you saying you want a DSA for a package that does not have that
particular vulnerability, but allows a user to create it?

"Doctor, it hurts when I do this!" "Don't do it, then."

"Help, help my computer does funny things!" "Don't power it up, then."

That's not what I meant. Admitted, the quote is more funny than exact
(and it isn;t particularly funny...). What I mean is that a lot of
software allows the user to shoot himself in various body parts. One
such example is rm. As in "rm * .o". Oooops.

If 'rm foo' has the same effect like 'rm -rf /', than rm would be broken. If '127.0.0.1 RELAY' has the same effect like '* RELAY' than sendmail is broken.

More related to the OP, sendmail allows you to configure an open relay
in a number of ways, not all of them as easily identified as the
"localhost" problem. It has a built-in write-only language...

This has nothing todo with the OP.

But why would the posssibility to configure the package to open a relay
warrant a DSA? It would IMNSHO only when the package came preconfigured
to do that.

yep, I think most of the recent DSAs shouldn't be published. The packages can be exploided if feed with user data - this is a change to the preconfigured setup !!!

Almost all security holes need to user to do something. (If only to
power up the machine, to install some packages, to connect to the
internet, to give accounts to users). The question cannot be that
something has to be done do make people vulnerable, but whether properly
sane and educated people can guess that something opens a security
problem.

I interpret this to mean that there should be DSAs for all problems *made
possible* by Debian packages, rather than those *caused* by the package.

It is caused by the package, due the implementation of the access.db handling. If netfilter wouldn't drop/reject any packets, you won't issue an DSA? The preconfiguration doesn't ship any rules, so nobody should care if netfilter doesn't work in stable...


Regards,
Thomas

PS: The guy who went to the doctor has died by disease last week. If the doc would have take a look at the guy, he would still be alive.

--
support@ibh.de                              Tel. +49 351 477 77 30
www.ibh.de                                  Fax  +49 351 477 77 39

-----------------------------------------------------------------------
Dipl.-Ing. Thomas Liske
Netzwerk- und System-Design


IBH IT-Service GmbH                         Amtsgericht Dresden
Gostritzer Str. 61-63                       HRB 13626
D-01217 Dresden                             GF: Prof. Dr. Thomas Horn
Germany                                     VAT DE182302907
-----------------------------------------------------------------------
Ihr Partner für: LAN, WAN IP-Quality, Security, VoIP, SAN, Backup, USV
-----------------------------------------------------------------------
       professioneller IT-Service - kompetent und zuverlässig
-----------------------------------------------------------------------


Reply to: