Skip Menu |
 

This queue is for tickets about the Net-Server CPAN distribution.

Report information
The Basics
Id: 83909
Status: open
Priority: 0/
Queue: Net-Server

People
Owner: Nobody in particular
Requestors: CARNIL [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: CVE-2013-1841: Improper reverse DNS matching check for the given hostname
Date: Tue, 12 Mar 2013 22:46:27 +0100
To: bug-Net-Server [...] rt.cpan.org
From: Salvatore Bonaccorso <carnil [...] cpan.org>
Download (untitled) / with headers
text/plain 2.1k
Hi CVE-2013-1841 was assigned to following issue, first quoting from reporter[1]. ----cut---------cut---------cut---------cut---------cut---------cut----- Hi, I think there is a security issue in the way the access control feature of Net::Server (http://search.cpan.org/perldoc?Net%3A%3AServer) works. Net::Server is used by various projects including Munin, Postgrey and SQLgrey. The issue lies in the fact that the allow / deny access control does not perform a valid DNS check when given a hostname parameter and the 'reverse_lookups' option is enabled. The current code only checks that the incoming connection source IP address has a reverse DNS matching the given hostname, but does not check that the hostname resolves back to this source IP address (see how the $prop->{'peerhost'} property is set in get_client_info(), lib/Net/Server.pm:553, then used in allow_deny(), lib/Net/Server.pm:597). As it is trivial for an attacker to be able to set his own source IP's reverse DNS, the current check is not safe (this probably matches CWE-807: Reliance on Untrusted Inputs in a Security Decision). I think that the valid way would be to do the same checks as Apache HTTPd does for the Allow / Deny directives (see do_double_reverse() and ap_get_remote_host() in server/core.c for more information): "It will do a reverse DNS lookup on the IP address to find the associated hostname, and then do a forward lookup on the hostname to assure that it matches the original IP address. Only if the forward and reverse DNS are consistent and the hostname matches will access be allowed." At the very least, the documentation of Net:Server should be updated to specify exactly what is checked by Net:Server access control, as many people seem to assume that the check is done in the same way as in Apache HTTPd. So far, I have been unable to reach the Net-Server maintener to discuss this matter. -- Regards, Remi Gacogne ----cut---------cut---------cut---------cut---------cut---------cut----- [1]: http://www.openwall.com/lists/oss-security/2013/03/04/10 Further reference: [2]: https://bugzilla.redhat.com/show_bug.cgi?id=920683 Regards, Salvatore
Subject: Re: [rt.cpan.org #83909] CVE-2013-1841: Improper reverse DNS matching check for the given hostname
Date: Wed, 13 Mar 2013 14:37:11 -0600
To: bug-Net-Server [...] rt.cpan.org
From: Paul Seamons <paul [...] seamons.com>
Download (untitled) / with headers
text/plain 2.9k
We will add an option to do the forward lookup. Should be available within a day or so. As for not being able to get hold of the maintainer, this is the first I have been contacted so whatever other email options were used did not work. Paul On 03/12/2013 03:46 PM, Salvatore Bonaccorso via RT wrote: Show quoted text
> Tue Mar 12 17:46:44 2013: Request 83909 was acted upon. > Transaction: Ticket created by CARNIL > Queue: Net-Server > Subject: CVE-2013-1841: Improper reverse DNS matching check for the given hostname > Broken in: (no value) > Severity: (no value) > Owner: Nobody > Requestors: CARNIL@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=83909 > > > > Hi > > CVE-2013-1841 was assigned to following issue, first quoting from > reporter[1]. > > ----cut---------cut---------cut---------cut---------cut---------cut----- > Hi, > > I think there is a security issue in the way the access control feature > of Net::Server (http://search.cpan.org/perldoc?Net%3A%3AServer) works. > Net::Server is used by various projects including Munin, Postgrey and > SQLgrey. > > The issue lies in the fact that the allow / deny access control > does not perform a valid DNS check when given a hostname parameter > and the 'reverse_lookups' option is enabled. > The current code only checks that the incoming connection source IP > address has a reverse DNS matching the given hostname, but does not > check that the hostname resolves back to this source IP address (see > how the $prop->{'peerhost'} property is set in get_client_info(), > lib/Net/Server.pm:553, then used in allow_deny(), lib/Net/Server.pm:597). > As it is trivial for an attacker to be able to set his own > source IP's reverse DNS, the current check is not safe (this probably > matches CWE-807: Reliance on Untrusted Inputs in a Security Decision). > > I think that the valid way would be to do the same checks as > Apache HTTPd does for the Allow / Deny directives (see do_double_reverse() > and ap_get_remote_host() in server/core.c for more information): > "It will do a reverse DNS lookup on the IP address to find the > associated hostname, and then do a forward lookup on the hostname > to assure that it matches the original IP address. > Only if the forward and reverse DNS are consistent and the hostname > matches will access be allowed." > > At the very least, the documentation of Net:Server should be updated to > specify exactly what is checked by Net:Server access control, as many > people seem to assume that the check is done in the same way as in Apache > HTTPd. > > So far, I have been unable to reach the Net-Server maintener to discuss > this matter. > > -- > Regards, > > Remi Gacogne > ----cut---------cut---------cut---------cut---------cut---------cut----- > > [1]: http://www.openwall.com/lists/oss-security/2013/03/04/10 > > Further reference: > > [2]: https://bugzilla.redhat.com/show_bug.cgi?id=920683 > > Regards, > Salvatore > >
Subject: Re: [rt.cpan.org #83909] CVE-2013-1841: Improper reverse DNS matching check for the given hostname
Date: Thu, 14 Mar 2013 06:51:50 +0100
To: Paul Seamons via RT <bug-Net-Server [...] rt.cpan.org>
From: Salvatore Bonaccorso <carnil [...] cpan.org>
Download (untitled) / with headers
text/plain 762b
Hi Paul On Wed, Mar 13, 2013 at 04:37:39PM -0400, Paul Seamons via RT wrote: Show quoted text
> We will add an option to do the forward lookup. Should be available > within a day or so.
Ok, thank you for your quick followup on this! Btw, should that be done by default whenever reverse_lookups are used, tho check forward by default? It's what apache does, and seems to be a common approach. See e.g. Russ Allbery's mail[1]. [1]: http://marc.info/?l=oss-security&m=136242581611722&w=2 Show quoted text
> As for not being able to get hold of the maintainer, this is the first I > have been contacted so whatever other email options were used did not work.
This is the part I do not acctualy know. I forwarded the findings by Remi Gacogne here to the tracker. Thank you Paul! Salvatore
From: rgacogne-bugs [...] coredump.fr
Download (untitled) / with headers
text/plain 739b
Hi Paul, Show quoted text
> As for not being able to get hold of the maintainer, this is the first > I > have been contacted so whatever other email options were used did not > work.
I did indeed try to reach you by email, from rgacogne-bugs (at) coredump (dot) fr to paul (at) seamons (dot) com on Sun, 27 Jan 2013 17:19:57 +0100 (CET). I am very sorry you didn't get the email, and I am certainly not trying to blame you. Please accept my apology if it seemed so. I wasn't very fond of the idea of posting this issue to oss-sec, but adding it to this bug tracker would have been public disclosure without notifying the security people of the various distributions so I didn't think it was a wise option at the time. Best regards, Remi Gacogne
From: vcizek [...] suse.cz
Download (untitled) / with headers
text/plain 378b
Hi Paul On Wed Mar 13 16:37:38 2013, RHANDOM wrote: Show quoted text
> We will add an option to do the forward lookup. Should be available > within a day or so.
Is the new code available somewhere? I don't see any new releases since 2.007 Btw, the forward lookup should be mandatory rather than an option. Check the thread on oss-sec: http://marc.info/?l=oss-security&m=136242562311649&w=2


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.