3 ms·
Well, it obviously does getaddrinfo() on the incoming TCP connection to get the hostname (which is reported in the log, unless you have a 'UseDNS no' directive)
by beagle3 12y ago
Well, it obviously does getaddrinfo() on the incoming TCP connection to get the hostname (which is reported in the log, unless you have a 'UseDNS no' directive) -- and at least in my setup (which is mostly vanilla Debian), it seems to resolve that name again to an IP address, compare that to the IP address of the connection, and warn if it does not match.
Thus, an attacker controlling the PTR record for a given IP might provide a GHOST-compliant name in that PTR record; Then, connect to the ssh daemon, wait for it to read the PTR record - and if it gethostbyname() on it, it's game over.
Quite a few log processors would do that. The reason I'm worried specifically about sshd is that it is usually the only port ever listening to the world-and-not-firewalled on my servers (and a non-standard, at that - and only allowing public key authentication) - but despite this generally-regarded-as-secure setting, GHOST may prove it vulnerable.
- cft 12y agoBut why would this malicious PTR record be fed into gethostbyname() again? At that point of getting a reverse lookup result, sshd is done checking.
- beagle3 12y agoTo see that it resolves back to the IP address from which the connection is made. It's a standard check that many servers do, and ssh does too (and gives off a warning if they don't match). I'm not sure if it does it in a way that's vulnerable or not, though - but it surely does so by default. From man sshd_config: UseDNS Specifies whether sshd(8) should look up the remote host name and check that the resolved host name for the remote IP address maps back to the very same IP address. The default is “yes”.