[Dovecot] Hostname passed to PAM as rhost
(I am sorry to bother the list with something I should have verified myself right now - I simply do not have access to the source code here)
Thinking of some limit I wanted to put with authentication, I am wondering - when Dovecot authenticates a user using PAM, now that (in 1.0) it passes the rhost item to PAM, it passes a hostname, not an IP address.
Does it double-verify the DNS record before it trusts this to be the hostname (first checking the IP address in in_addr.arpa and then checking that the hostname indeed maps back to the same IP address)?
That is necessary in order to trust the client address when determining authentication strength in the PAM module based on the client location (specifically we want stronger authentication when the client comes outside of our network, while inside a plain password suffices), as else anybody could "spoof" the hostname by changing the IN PTR record of his IP address to point back to some "trusted" hostname (given he has control of the DNS zone his host is in, which is completely possible given the server knows nothing about it).
Thanks, -- Tom
-- Tom Alsberg - hacker (being the best description fitting this space) Web page: http://www.cs.huji.ac.il/~alsbergt/ DISCLAIMER: The above message does not even necessarily represent what my fingers have typed on the keyboard, save anything further.
Tom Alsberg wrote:
Does it double-verify the DNS record before it trusts this to be the hostname (first checking the IP address in in_addr.arpa and then checking that the hostname indeed maps back to the same IP address)?
Actually, this level of paranoia is not useful, since it will fail to correctly operate in the very real case of co-hosted boxes. There can only be (in practice) a single mapping from IP => hostname (via in-addr.arpa), but there can be virtually limitless hostname => IP maps. There were a few SMTP servers which supported "round-trip DNS checks" but by now, hopefully, the sysadmins running those boxes have been killed off by the userbase eager to actually receive e-mail.
If PAM authentication supports different schemes based on source IP address, that is the best you can hope for. The only trustworthy value in a point-to-point TCP connection is IP (since it is impossible to spoof that due to the need to be able to get the response packets back later).
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
On Mon, 26 Sep 2005, John Peacock wrote:
Actually, this level of paranoia is not useful, since it will fail to correctly operate in the very real case of co-hosted boxes. There can only be (in practice) a single mapping from IP => hostname (via in-addr.arpa), but there can be virtually limitless hostname => IP maps.
Technically that is incorrect. See RFC 2181 10.2, which explicitly states:
"Confusion about canonical names has lead to a belief that a PTR record should have exactly one RR in its RRSet. This is incorrect, the relevant section of RFC1034 (section 3.6.2) indicates that the value of a PTR record should be a canonical name. That is, it should not be an alias. There is no implication in that section that only one PTR record is permitted for a name. No such restriction should be inferred."
Apparently older implementations of gethostbyaddr() didn't like this, but that isn't the case in modern implementations.
However, your comments are probably correct in practice because those implementing multiple hostnames -> single IP rarely put in the corresponding multiple PTR records from the in-addr.arpa entry back to each of the hostnames.
Jethro.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks Computing Officer, IT Services University Of Strathclyde, Glasgow, UK
Jethro R Binks wrote:
However, your comments are probably correct in practice because those implementing multiple hostnames -> single IP rarely put in the corresponding multiple PTR records from the in-addr.arpa entry back to each of the hostnames.
I said "in practice" and I meant it (I do know the RFC's in question). I'm not aware of any common application which supports multiple PTR records correctly, even if configured correctly at the DNS level. It can even cause problems with authoritative DNS servers which return records in a random order (like tinydns), where the client library may receive a different in-addr.arpa answer every time it is run.
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
On Mon, Sep 26, 2005 at 03:37:15PM -0400, John Peacock wrote:
Actually, this level of paranoia is not useful, since it will fail to correctly operate in the very real case of co-hosted boxes.
I realize that. However I am assuming that this will not be the case of most clients. I would expect that in such a case, Dovecot would would simply pass the IP address as a string.
There can only be (in practice) a single mapping from IP => hostname (via in-addr.arpa),
Are you sure of that? I cannot say now for sure and do not have the the relevant RFCs at hand, but I had the impression that a DNS key may have more than one record of the same type and class, no matter what the type and class (of course this is not always feasible and may be limited somewhere else).
but there can be virtually limitless hostname => IP maps.
Right.
There were a few SMTP servers which supported "round-trip DNS checks" but by now, hopefully, the sysadmins running those boxes have been killed off by the userbase eager to actually receive e-mail.
Of course it may be that the forward and reverse lookup do not match, and I did not intend to just kick out such clients. My intention was to assume that in our network, forward and reverse lookups do match, and therefore a client where it does not match may be safely treated as not in our network (and even if that is not the real case, the most damage done by this would be someone having to authenticate against a stronger mechanism - he would still be able to use the service)
If PAM authentication supports different schemes based on source IP address, that is the best you can hope for.
PAM itself (libpam), of course, knows nothing about clients, servers, and networks. The authentication is done by application and PAM can not know where the application received the authentication data from, except for what the application passes the module as a parameter.
I do not recall there being a PAM item for IP address, but just for the remote hostname - rhost, which may be any string received by the application, and is only by convention expected to be the address of the client.
The only trustworthy value in a point-to-point TCP connection is IP (since it is impossible to spoof that due to the need to be able to get the response packets back later).
I realize that. However if all I (the module) get from Dovecot is the hostname, there is no way to know what the IP address of the client was. Actually, I anyway intend to do the classification by IP address and netmask - but the only sure way I had in mind, to get the IP address of the client from Dovecot is get the hostname and do a lookup on that, which is not reliable if Dovecot has not first checked that it really resolves to the same IP address.
Well, tomorrow I'll look into the sources and see if there is a way to get the IP address from Dovecot as a PAM module. If not, I may just write a patch for that (will probably make it configurable in dovecot.conf whether the PAM rhost item passed will be a hostname or IP address).
John
Cheers, -- Tom
-- Tom Alsberg - hacker (being the best description fitting this space) Web page: http://www.cs.huji.ac.il/~alsbergt/ DISCLAIMER: The above message does not even necessarily represent what my fingers have typed on the keyboard, save anything further.
On Mon, 26 Sep 2005, Tom Alsberg wrote:
I do not recall there being a PAM item for IP address, but just for the remote hostname - rhost, which may be any string received by the application, and is only by convention expected to be the address of the client.
yeah pam is unfortunately the real problem here -- pam should support both the numeric IP and the text name. the IP address is absolutely essential for forensic analysis, however humans tend to want to read a text name...
but the text name is quite untrustworthy: even a double-reverse check is insufficient in the cases where an attacker has control over dns servers... how do you figure out what network block the attack came from after the fact if the dns has been changed again?
just write a patch for that (will probably make it configurable in dovecot.conf whether the PAM rhost item passed will be a hostname or IP address).
this is what i've done to other daemons... and i run with them in IP address mode instead.
my old patch for PAM_RHOST for 0.99.x didn't even do DNS lookups.
-dean
On Mon, 2005-09-26 at 22:24 +0300, Tom Alsberg wrote:
Thinking of some limit I wanted to put with authentication, I am wondering - when Dovecot authenticates a user using PAM, now that (in 1.0) it passes the rhost item to PAM, it passes a hostname, not an IP address.
You're looking at it wrong somehow. Dovecot doesn't do DNS lookups anywhere (and I hope to avoid it as long as possible). The code to set rhost looks like:
#ifdef PAM_RHOST const char *host = net_ip2addr(&request->remote_ip); if (host != NULL) pam_set_item(pamh, PAM_RHOST, host); #endif
participants (5)
-
dean gaudet
-
Jethro R Binks
-
John Peacock
-
Timo Sirainen
-
Tom Alsberg