Project

General

Profile

Feature #1858

ssh reverse-mapping check should care about crafted PTR records

Added by Rich Lowe almost 8 years ago. Updated over 4 years ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
cmd - userland programs
Start date:
2011-12-07
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

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

History

#1

Updated by Andy Fiddaman over 4 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

Also available in: Atom PDF