Feature #1858
open
ssh reverse-mapping check should care about crafted PTR records
0%
Description
The (openssh) upstream diffs for #1848 included a check:
+ /*
+ * if reverse lookup result looks like a numeric hostname,
+ * someone is trying to trick us by PTR record like following:
+ * 1.1.1.10.in-addr.arpa. IN PTR 2.3.4.5
+ */
+ memset(&hints, 0, sizeof(hints));
+ hints.ai_socktype = SOCK_DGRAM; /*dummy*/
+ hints.ai_flags = AI_NUMERICHOST;
+ if (getaddrinfo(name, "0", &hints, &ai) == 0) {
+ log("Nasty PTR record \"%s\" is set up for %s, ignoring",
+ name, ntop);
+ freeaddrinfo(ai);
+ return xstrdup(ntop);
+ }
which seems like something we should consider doing, though not actually related to the issue at hand there.
See: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/canohost.c.diff?r1=1.36;r2=1.37;f=h
Updated by Andy Fiddaman over 8 years ago
Other than a more informative log message in this case, this doesn't add anything to the reverse mapping check we already have. That is, a PTR record like the one suggested can't be used to circumvent the existing check, you just get something like this in the logs:
carolina# (9) dig +short -x 89.x.x.x.x
8.8.8.8.
Apr 14 11:33:44 carolina sshd29563: [ID 800047 auth.info] Address 89.x.x.x maps to 8.8.8.8, but this does not map back to the address - POSSIBLE BREAKIN ATTEMPT!
carolina# (10) tail -4 /etc/ssh/sshd_config
LookupClientHostnames yes
VerifyReverseMapping yes