Re: sendmail localhost rDNS
On Tue, Aug 11, 2009 at 10:56:57AM +0200, Joerg Morbitzer wrote: I just did a fresh sendmail installation on Debian Etch getting this auto-generated new /etc/mail/access file: titan:~# grep ^Connect:.*RELAY /etc/mail/access Connect:localhost RELAY Connect:127 RELAY Connect:[IPv6:::1] RELAY titan:~# Although it only binds to 127.0.0.1 and ::1 by default, Debian Lenny has the same default /etc/mail/access, which turns the whole Doctor, it hurts when I do this! discussion into Doctor, it hurts when you do this to me! On the other hand, I was not able to reproduce the problem on a Lenny virtual machine in my test environment. After I tampered with rDNS so that the sending system would resolve to 'localhost', Sendmail did indeed record the hostname 'localhost' in log messages, but it was always accompanied by the sending system's IP address and the note 'may be forged'. Even with the ability to control forward resolution of localhost (which requires commenting out the localhost lines in /etc/hosts or altering NSS configuration), I was able to get rid of the may be forged warnings but wasn't able to relay. I don't have any suitable Etch images prepared (and didn't want to sit through an installation), so I didn't run a test from a clean install, but in limited testing on an existing Etch system with the default Connect:localhost RELAY line in /etc/mail/access, I could not get the system to relay mail that it shouldn't have. Notes on test procedure: The Lenny Sendmail installation was entirely default, except that sendmail.mc was edited to allow Sendmail to bind all interfaces on the system. BIND was installed on the same system and provided with a suitably altered version of my number-to-name zone. The /etc/resolv.conf file was altered to point only at this new nameserver. To test ability to control forward resolution of 'localhost', I commented out all 'localhost' lines in /etc/mail/access and added a new line which matched the information my test DNS server was delivering. I did not perform tests on the Etch system that required altering /etc/hosts. On the Etch Here is a session transcript from a conversation with the Lenny system (with hostnames and IP addresses altered). Note that the same results happend regardless of whether I HELO'd with 'localhost', the target system's hostname, or some other name. | 220 vmtest1.a.test ESMTP Sendmail 8.14.3/8.14.3/Debian-5; Wed, 12 Aug 2009 16:43:04 -0600; (No UCE/UBE) logging access from: [x.x.x.5](FORGED)-localhost [x.x.x.5] (may be forged) | helo myhostname | 250 vmtest1.a.test Hello localhost [x.x.x.5] (may be forged), pleased to meet you | mail from: us...@a.test | 250 2.1.0 us...@a.test... Sender ok | rcpt to: us...@a.test | 550 5.7.1 us...@a.test... Relaying denied. IP name possibly forged [x.x.x.5] | quit | 221 2.0.0 vmtest1.a.test closing connection Here is a (hand-retyped) section of the mail log for the above session: | Aug 12 16:43:15 vmtest1 sm-mta[4761]: n7CMh4Q5004761: ruleset=check_rcpt, arg1=us...@a.test, relay=localhost [x.x.x.5] (may be forged), reject=550 5.7.1 us...@a.test... Relaying denied. IP name possibly forged [x.x.x.5] | Aug 12 16:43:16 vmtest1 sm-mta[4761]: n7CMh4Q5004761: from=us...@a.test, size=0, class=0, nrcpts=0, proto=SMTP, daemon=MTA, relay=localhost [x.x.x.5] (may be forged) -- William Aoki KD7YAFwa...@umnh.utah.edu5-1924 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
* Lupe Christoph l...@lupe-christoph.de [090810 21:13]: 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. What I try to tell you is that I do not share your interpretion of caused. If bash had a bug to always include . in PATH, would that cause a problem or make a problem possible? (After all, noone forces you do switch to other peoples directories before doing ls). If a webbrowser has a problem executing arbitrary stuff told by the website visited, is that a security problem caused or made possible by the webbrowser. (After all, if you do not visit untrusted sites, there is no problem). If sshd had a bug so that PermitRootLogin without-password (which is not the default) allowed people to login without any identification as root instead of what it is supposed to be, would that be bug caused by ssh or a bug made possible by ssh? So it is in my eyes to criteria at all that the user has to change some configuration. The question is whether this change is supposed to cause the effects it does and if a user can be expected to understand the effects. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
Re, Lupe Christoph wrote: On Monday, 2009-08-10 at 14:35:06 +0200, Bernhard R. Link wrote: * Lupe Christoph l...@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. -- supp...@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 --- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
OK, I give up. And shut up. Please file a bug against the sendmail package, with the information that sendmail allows you to enter Connect:localhost RELAY in /etc/mail/access. And another one that Connect:127.0.0.1 RELAY opens up the same hole as Connect:localhost RELAY. Since I have no sendmail installation to use for testing, I can't reproduce the second problem. The sendmail package maintainer will probably require the submitter to provide details which I can't. Thank you, Lupe Christoph -- | There is no substitute for bad design except worse design. | | /me | -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
On Tuesday, 2009-08-11 at 10:32:04 +0200, Bernhard R. Link wrote: * Lupe Christoph l...@lupe-christoph.de [090810 21:13]: 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. What I try to tell you is that I do not share your interpretion of caused. If bash had a bug to always include . in PATH, would that cause a problem or make a problem possible? (After all, noone forces you do switch to other peoples directories before doing ls). That would be a defect in the package that requires no user configuration. The equivalent of Connect:localhost RELAY would be this in .bashrc: PATH=.:$PATH . If a webbrowser has a problem executing arbitrary stuff told by the website visited, is that a security problem caused or made possible by the webbrowser. (After all, if you do not visit untrusted sites, there is no problem). That is a defect in the webbrowser. It requires no user configuration. If sshd had a bug so that PermitRootLogin without-password (which is not the default) allowed people to login without any identification as root instead of what it is supposed to be, would that be bug caused by ssh or a bug made possible by ssh? That is a bug because sshd does not what is documented. Suppose sshd_config had an option PermitRootLogin always, meaning that no password or key is required to log in as root. Would it be a bug of sshd to include this option or a misfeature? So it is in my eyes to criteria at all that the user has to change some configuration. The question is whether this change is supposed to cause the effects it does and if a user can be expected to understand the effects. Please go ahead and file security-related bugs against all packages that allow the user to open security holes by changing the default configuration. I suppose we should agree to disagree and terminate this thread here. Of course I will not restrict your freedom to answer to this mail, but I will leave your reply unanswered because I believe we won't ever agree. Lupe Christoph -- | There is no substitute for bad design except worse design. | | /me | -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
Lupe Christoph wrote: OK, I give up. And shut up. Please file a bug against the sendmail package, with the information that sendmail allows you to enter Connect:localhost RELAY in /etc/mail/access. And another one that Connect:127.0.0.1 RELAY opens up the same hole as Connect:localhost RELAY. Since I have no sendmail installation to use for testing, I can't reproduce the second problem. The sendmail package maintainer will probably require the submitter to provide details which I can't. Thank you, Lupe Christoph I just did a fresh sendmail installation on Debian Etch getting this auto-generated new /etc/mail/access file: titan:~# grep ^Connect:.*RELAY /etc/mail/access Connect:localhost RELAY Connect:127 RELAY Connect:[IPv6:::1] RELAY titan:~# Regards, Joerg. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
* Lupe Christoph l...@lupe-christoph.de [090811 10:56]: So it is in my eyes no criteria at all that the user has to change some configuration. The question is whether this change is supposed to cause the effects it does and if a user can be expected to understand the effects. Please go ahead and file security-related bugs against all packages that allow the user to open security holes by changing the default configuration. I suppose we should agree to disagree and terminate this thread here. Of course I will not restrict your freedom to answer to this mail, but I will leave your reply unanswered because I believe we won't ever agree. Thanks for not restricting my freedom to reply to a mail that ridicules what I say by drawing absurd conclusions out of it. I never said that being able to change a configuration to open holes is in itself and always a security problem. What I am saying is that needing user action or having to change a configuration file is no reason at all to claim that something is not a security problem. Annoyed, Bernhard R. Link That is a bug because sshd does not what is documented. Suppose sshd_config had an option PermitRootLogin always, meaning that no password or key is required to log in as root. Would it be a bug of sshd to include this option or a misfeature? Of course not. And being able to add an option to sendmail to allow everyone to relay would of course also definitely be no problem if it was documentated to do so and has a sensible name. And noone in this thread claimed it would be. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
If sendmail would do a double lookup verify on the reverse DNS records, there would be no problem at all. When some obscure IP address has reverse DNS pointer record localhost and sendmail would do another lookup to see what IP address belongs to localhost, then it would not match (obscure IP != 127.0.0.1) and the access DB rule should not be valid for this connection. Could someone from the Debian security team do some test and check if sendmail does the double lookup verify? If not, a DSA would be appropriate and it should be patched. With kind regards, Michiel Klaver IT professional At 11-8-2009 10:45, Lupe Christoph wrote: OK, I give up. And shut up. Please file a bug against the sendmail package, with the information that sendmail allows you to enter Connect:localhost RELAY in /etc/mail/access. And another one that Connect:127.0.0.1 RELAY opens up the same hole as Connect:localhost RELAY. Since I have no sendmail installation to use for testing, I can't reproduce the second problem. The sendmail package maintainer will probably require the submitter to provide details which I can't. Thank you, Lupe Christoph -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
sendmail localhost rDNS
Hi, 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? Cheers, Thomas [1] http://www.h-online.com/security/Naming-trick-opens-mail-servers--/news/113946 -- supp...@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 --- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
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. Lupe Christoph -- | There is no substitute for bad design except worse design. | | /me | -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
Re, #Lupe Christoph wrote: 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? if an access line like: Connect:localhost RELAY turns a MTA into an Open Relay than I would prefere a DSA, since the ACL implementation is broken IMHO. Regards, Thomas -- supp...@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 --- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
On Monday, 2009-08-10 at 14:03:44 +0200, Thomas Liske wrote: #Lupe Christoph wrote: 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? if an access line like: Connect:localhost RELAY turns a MTA into an Open Relay than I would prefere a DSA, since the ACL implementation is broken IMHO. Well, a line like this: Connect:spammer.comRELAY does the same, so, as I said, just don't do it. I still don't see why on one hand you say that you need a localhost line, and then complain that it hurts you. Why can't you use 127.0.0.1 or localhost.mydomain? Lupe Christoph -- | There is no substitute for bad design except worse design. | | /me | -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
On Mon, 2009-08-10 at 14:03 +0200, Thomas Liske wrote: if an access line like: Connect:localhost RELAY turns a MTA into an Open Relay than I would prefere a DSA, since the ACL implementation is broken IMHO. As long as reverse DNS can be faked, I would never use hostnames in my configuration files like that. If the debian package doesn't ship with this ACL as default, I don't see reason for a DSA. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
Re, Jan de Groot wrote: On Mon, 2009-08-10 at 14:03 +0200, Thomas Liske wrote: if an access line like: Connect:localhost RELAY turns a MTA into an Open Relay than I would prefere a DSA, since the ACL implementation is broken IMHO. As long as reverse DNS can be faked, I would never use hostnames in my configuration files like that. If the debian package doesn't ship with this ACL as default, I don't see reason for a DSA. the problem is even more worse. Replacing localhost with 127.0.0.1 as suggested by Lupe Christoph doesn't change anything. I can still relay if my reverse DNS resolves to localhost. Regards, Thomas -- supp...@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 --- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
* Jan de Groot j...@jgc.homeip.net [090810 14:22]: On Mon, 2009-08-10 at 14:03 +0200, Thomas Liske wrote: if an access line like: Connect:localhost RELAY turns a MTA into an Open Relay than I would prefere a DSA, since the ACL implementation is broken IMHO. As long as reverse DNS can be faked, I would never use hostnames in my configuration files like that. How common is programs verifying reverse DNS by doing forward DNS of the result? At least all programs relying on this information I've yet met consciously had it. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
* Lupe Christoph l...@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. 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. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sendmail localhost rDNS
On Monday, 2009-08-10 at 14:35:06 +0200, Bernhard R. Link wrote: * Lupe Christoph l...@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. 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... 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. 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. Lupe Christoph -- | There is no substitute for bad design except worse design. | | /me | -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
