Date: Mon, 28 Dec 1998 18:02:15 -0500 (EST) From: jooji@neptune.oceancomputer.com To: FreeBSD-gnats-submit@FreeBSD.ORG Subject: bin/9226: telnetd can log wrong IP address to utmp Message-ID: <199812282302.SAA00571@neptune.oceancomputer.com>
next in thread | raw e-mail | index | archive | help
>Number: 9226
>Category: bin
>Synopsis: telnetd can log wrong IP address to utmp
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Mon Dec 28 15:10:00 PST 1998
>Last-Modified:
>Originator: Jasper O'Malley
>Organization:
Ocean Computer Group, Inc.
>Release: FreeBSD 2.2.8-STABLE i386
>Environment:
Made the world and a new kernel with sources cvsupped on Dec 21:
FreeBSD neptune.oceancomputer.com 2.2.8-STABLE FreeBSD 2.2.8-STABLE #0: Tue Dec
22 10:21:07 EST 1998
>Description:
After renumbering a customer's network with new IP addresses, I telneted into
my server (neptune.oceancomputer.com), where I noticed that "who", "w -n", and
"last" were displaying the old IP address of the machine I was telneting from
as the source address. "netstat -n" correctly displayed the new IP address.
It's the result of a reverse DNS that doesn't agree with forward DNS (because
the cache on the server's nameserver hadn't expired the old forward DNS for
the customer site yet). My guess is that telnetd (or login?) apparently does a
reverse lookup on the source IP address from the socket object, and if the
hostname length exceeds UT_HOSTSIZE, it does a forward lookup on the hostname
it just got, and sticks that in ut_host[]. If the hostname generated by the
reverse lookup resolves to a different IP, and it's larger than UT_HOSTSIZE,
the wrong IP address gets stuck in utmp.
Here's the output from "who", "w", "w -n", and "last":
jooji@neptune:~ {7} who
jooji ttyp0 Dec 28 12:35 (206.34.173.214)
jooji@neptune:~ {8} w
12:41PM up 6 days, 1:27, 1 user, load averages: 0.06, 0.01, 0.00
USER TTY FROM LOGIN@ IDLE WHAT
jooji p0 rb01pxy.vnacj.or 12:35PM - w
jooji@neptune:~ {9} w -n
12:41PM up 6 days, 1:28, 1 user, load averages: 0.06, 0.01, 0.00
USER TTY FROM LOGIN@ IDLE WHAT
jooji p0 206.34.173.214 12:35PM - w -n
jooji@neptune:~ {10} last jooji | head -1
jooji ttyp0 206.34.173.214 Mon Dec 28 12:35 still logged in
[end output]
And here's the output from netstat -finet showing the correct source IP
(216.116.129.214):
jooji@neptune:~ {11} netstat -nfinet
Active Internet connections
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp 0 4 209.36.77.133.23 216.116.129.214.1661 ESTABLISHED
[end output]
And the output of nslookup, showing the disparate forward and reverse
DNS as neptune sees it:
jooji@neptune:~ {12} nslookup rb01pxy.vnacj.org
Server: ns1.oceancomputer.com
Address: 209.36.77.133
Non-authoritative answer:
Name: rb01pxy.vnacj.org
Address: 206.34.173.214
jooji@neptune:~ {13} nslookup 216.116.129.214
Server: ns1.oceancomputer.com
Address: 209.36.77.133
Name: rb01pxy.vnacj.org
Address: 216.116.129.214
[end output]
At first glance, it appears to be little more than a nuisance, but it could
allow some malicious bastard to jump into your machine with a bogus entry
in your lastlog.
>How-To-Repeat:
Change the IP address on a machine, update the reverse DNS, and leave forward
DNS where it is. Then telnet into a FreeBSD box.
>Fix:
Change the source for whatever actually fills the ut_host[] array in the
utmp structure for the connection so that if the hostname exceeds UT_HOSTSIZE,
it enters the IP address from the socket object (socket->sin_addr), rather
than doing a forward lookup on the hostname. I don't have a patch to offer
just now, but I'll see to it tonight.
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812282302.SAA00571>