sshd config parser

[Jefferson Ogata]

On 04/05/2006 01:12 AM, Darren Tucker wrote:
> Jefferson Ogata wrote:
>>>>2. How does "Host" with wildcards interact with DNS? E.g. will "Host
>>>>192.168.0.*" match 192.168.0.evil.domain?
>>>
>>>It would, which is why...
>>
>>Oh, my. Don't you think this is going to lead to unexpected results? I'm
>>a bit concerned that people won't realize that DNS is an issue...
> 
> The whole idea of having a "Address" and "Host" as distinct entities is
> that if you want to match an address you use "Address" and if you want
> to match a hostname you use "Host".

I follow that. But I'm concerned that people won't expect that Host will
behave the way you describe even with an all-numeric + wildcard value
such as 192.168.0.*.

>>Could sshd default not to use inverse DNS in Host matches unless another
>>config directive were enabled?
> 
> That would be "UseDNS", no?

>From the description:

UseDNS  Specifies whether sshd 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.

it looks to me as if UseDNS controls paranoid lookups. That's an
independent issue. An attacker with control over his own DNS can arrange
that paranoid checks will succeed. That is, attacking-ip.in-addr.arpa =>
192.168.0.evil.domain, and 192.168.0.evil.domain => attacking-ip.

I'm saying perhaps Host should default to ignoring DNS entirely.

Or, failing that, if the argument to Host matches [0-9\.\*]+ it could
behave like Address. In fact, Address might be unnecessary in this case.

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>
"Never try to retrieve anything from a bear."--National Park Service