From ras@e-gerbil.net  Fri Nov  3 17:44:37 2000
Return-Path: <ras@e-gerbil.net>
Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247])
	by hub.freebsd.org (Postfix) with ESMTP id 1F71A37B4CF
	for <FreeBSD-gnats-submit@freebsd.org>; Fri,  3 Nov 2000 17:44:36 -0800 (PST)
Received: by overlord.e-gerbil.net (Postfix, from userid 1000)
	id 46C9B5D7A; Fri,  3 Nov 2000 20:44:35 -0500 (EST)
Message-Id: <20001104014435.46C9B5D7A@overlord.e-gerbil.net>
Date: Fri,  3 Nov 2000 20:44:35 -0500 (EST)
From: Richard Steenbergen <ras@e-gerbil.net>
Reply-To: ras@e-gerbil.net
To: FreeBSD-gnats-submit@freebsd.org
Subject: telnetd tricked into using arbitrary peer ip
X-Send-Pr-Version: 3.2

>Number:         22595
>Category:       bin
>Synopsis:       telnetd tricked into using arbitrary peer ip
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    brian
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Nov 03 17:50:01 PST 2000
>Closed-Date:    Tue Jun 22 20:43:24 GMT 2004
>Last-Modified:  Tue Jun 22 20:43:24 GMT 2004
>Originator:     Richard A Steenbergen
>Release:        FreeBSD 5.0-CURRENT i386
>Organization:
>Environment:


>Description:

	telnetd can be tricked into believing the source of the connection
	is any arbitrary ip. This applies to realhostname[_sa]() functions.

	telnetd uses realhostname_sa() to determine the remote hostname.
	The resolver reverses the ip to real.hostname.com and then resolves
	forward. If the forward dns has multiple cnames for round-robin load
	balancing it will resolve forward to a different ip. That ip will then
	be reversed and that host and ip will be used in telnetd. This poses
	obvious security implications.

ras@overlord:docs> w
 8:36PM  up 3 days, 15:44, 19 users, load averages: 0.58, 0.51, 0.50
USER             TTY      FROM              LOGIN@  IDLE WHAT
ras              pl       www.senate.gov    6:46PM     9 -

ras@overlord:docs> w -n
 8:37PM  up 3 days, 15:44, 19 users, load averages: 0.58, 0.51, 0.50
USER             TTY      FROM              LOGIN@  IDLE WHAT
ras              pl       199.95.76.12      6:46PM    10 -

>How-To-Repeat:

	Add multiple cnames to the real hostname of the machine you're
	connecting from, resolving to the ip you wish to spoof from.

>Fix:

	make realhostname*() not suck

>Release-Note:
>Audit-Trail:

From: Brian Somers <brian@Awfulhak.org>
To: "Richard A. Steenbergen" <ras@e-gerbil.net>
Cc: Peter Pentchev <roam@orbitel.bg>, freebsd-security@FreeBSD.org,
	freebsd-gnats-submit@FreeBSD.org
Subject: bin/22595: telnetd tricked into using arbitrary peer ip (was: telnetd suckage)
Date: Sat, 21 Jul 2001 14:37:36 +0100

 > On Fri, Jul 20, 2001 at 03:58:09PM -0400, Richard A. Steenbergen wrote:
 > > Speaking of telnetd sucking, did anyone ever get around to fixing
 > > http://www.freebsd.org/cgi/query-pr.cgi?pr=22595
 > > 
 > > Doesn't look like it.
 > 
 > Do you have any actual suggestions on how to 'make realhostname*()
 > not suck', as you have so helpfully suggested as a fix?
 
 I don't understand this PR.  What's the problem ?  realhostname*() 
 takes the connecting IP, turns it into a name and resolves that name. 
 If the *original* IP isn't in the list (or if a name couldn't be 
 found from the IP), it puts the *original* ip in utmp/wtmp.  If the 
 *original* IP is in the list, it uses the name that the IP was turned 
 into.
 
 The difference between ``w'' and ``w -n'' is whether ``w'' will look 
 up IP numbers found in utmp.  The fact that you're seeing different 
 answers means that realhostname_sa() stored the IP number in utmp.  
 
 The example in the PR means that someone connected from 199.95.76.12.
 
 There's nothing wrong with realhostname_sa() here.  Can the 
 originator please follow up with a better description of what the 
 perceived problem is please ?
 
 > G'luck,
 > Peter
 > 
 > -- 
 > This sentence is false.
 
 -- 
 Brian <brian@freebsd-services.com>                <brian@Awfulhak.org>
       http://www.freebsd-services.com/        <brian@[uk.]FreeBSD.org>
 Don't _EVER_ lose your sense of humour !      <brian@[uk.]OpenBSD.org>
 
 
State-Changed-From-To: open->feedback 
State-Changed-By: brian 
State-Changed-When: Sat Jul 21 06:40:44 PDT 2001 
State-Changed-Why:  
Awaiting a response to my comments 


Responsible-Changed-From-To: freebsd-bugs->brian 
Responsible-Changed-By: brian 
Responsible-Changed-When: Sat Jul 21 06:40:44 PDT 2001 
Responsible-Changed-Why:  
I was responsible for originally introducing realhostname 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=22595 

From: "Jeroen Massar" <jeroen@unfix.org>
To: "'Brian Somers'" <brian@Awfulhak.org>,
	"'Richard A. Steenbergen'" <ras@e-gerbil.net>
Cc: "'Peter Pentchev'" <roam@orbitel.bg>,
	<freebsd-security@FreeBSD.org>, <freebsd-gnats-submit@FreeBSD.org>
Subject: RE: bin/22595: telnetd tricked into using arbitrary peer ip (was: telnetd suckage)
Date: Sat, 21 Jul 2001 18:27:11 +0200

 Brian Somers wrote:
 
 > > On Fri, Jul 20, 2001 at 03:58:09PM -0400, Richard A. 
 > Steenbergen wrote:
 > > > Speaking of telnetd sucking, did anyone ever get around to fixing
 > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=22595
 > > > 
 > > > Doesn't look like it.
 > > 
 > > Do you have any actual suggestions on how to 'make realhostname*()
 > > not suck', as you have so helpfully suggested as a fix?
 > 
 > I don't understand this PR.  What's the problem ?  realhostname*() 
 > takes the connecting IP, turns it into a name and resolves that name. 
 > If the *original* IP isn't in the list (or if a name couldn't be 
 > found from the IP), it puts the *original* ip in utmp/wtmp.  If the 
 > *original* IP is in the list, it uses the name that the IP was turned 
 > into.
 
 $ host -t ptr 10.0.0.1
 1.0.0.10.IN-ADDR.ARPA domain name pointer www.fbi.gov
 
 $ host -t a www.fbi.gov
 www.fbi.gov has address 32.96.111.130
 
 And then your average dumb admin does a 'who' and oooooh... That dude is
 leet he/she/it logs in from www.fbi.gov
 It's also great for your logs... "My box got hacked from www.fbi.gov,
 the feds are on to me" nice quotes :)
 
 IRCd and many more (even PuTTY
 (www.chiark.greenend.org.uk/~sgtatham/putty/) :) do a:
 - Resolve IP -> hostname
 - resolve hostname -> IP2
 - if IP1 != IP2 then hostname = IP1
 
 That's the problem reported in the 22595 PR...
 
 
 But it get's even worse (evil grin :), this is a nice trick you can do
 to fool your ssh which IMHO should be a nice PR on it's own:
 
 8<-----------
 jeroen@purgatory:~$ w
  6:08PM  up 93 days,  9:58, 1 user, load averages: 0.19, 0.13, 0.14
 USER             TTY      FROM              LOGIN@  IDLE WHAT
 jeroen           p1       hell.unfix.org   10:16AM     - w
 jeroen@purgatory:~$ w -n
  6:08PM  up 93 days,  9:58, 1 user, load averages: 0.16, 0.12, 0.13
 USER             TTY      FROM              LOGIN@  IDLE WHAT
 jeroen           p1       10.100.13.66     10:16AM     - w -n
 ------------>8
 
 And guess what:
 8<-----------
 jeroen@purgatory:~$ netstat -an | grep \.22 | less
 tcp6       0      0  3ffe:8114:2000:2.22    3ffe:8114:2000:2.1628
 ESTABLISHED
 tcp4       0      0  *.22                   *.*
 LISTEN
 tcp46      0      0  *.22                   *.*
 LISTEN
 ------------>8
 
 Now I wonder... why the peep doesn't the wtmp log an IP (either IPv4 or
 IPv6) alongside a hostname...
 As you see ... Hell.unfix.org resolves nicely to 10.100.13.66 (an IPv4
 address) even when I am connected over IPv6...
 If that isn't one kind of security risk.... Simply change your reverse
 to something nice and wh0ppa...
 No-one will even notice thaty you're coming from a remote network far
 far away...
 With this nice IPv4/IPv6 trick you could even set a forward IPv4 lookup
 to make a local IPv4 IP. So that it looks like you logged in from a
 local system.
 If that isn't enough 'proof' that the whole utmp/wtmp concept is
 wrong.... -> YES, I accuse utmp/wtmp not telnetd as you might notice ssh
 has the same problem :)
 Telnetd simply does what it _can_ do ... log the hostname to utmp/wtmp,
 'w' and friends simply use that info to show it to us...
 
 So we basically have the following list of problems:
  - wtmp/utmp should have hostname and IPv4 or IPv6 or ...
    one could choose IPv4 mapped IP's.. eg: ::ffff:10.100.13.66 (but this
 could become a prob in the future again...
    IMHO adding an extra field containing the ascii representation of the
 IP/address whatever should do... Which also would be able to log the IPX
 addy or whatever :)
    And the hostname field should contain either nothing (empty) or
 should contain the ascii representation of the address, that's what
 forward&reverse resolve is for...
  - utmp/wtmp-"client"-programs (readers) show the wrong info when
 'showing network numbered' because they don't have the full/correct info
 because they don't have it.
 
 _if/when_ these get fixed even "dumb admins/users" won't go around
 telling that they got hacked by the FBI or the CIA simply because some
 kiddy with reverse access,
 which currently is quite easy to obtain with all those IPv6
 tunnelbrokers around who don't give anything about (possible) abuse from
 their clients.
 And the same goes for IPv4 ofcourse.... Simply insert a PTR record...
 and tada... you're now coming from a NASA host... how 1337 or whatever
 spelling those people/things/... prefer...
 
 And like Richard says: THAT REALLY SUCKS.
 
 Greets,
  Jeroen
 

From: Brian Somers <brian@Awfulhak.org>
To: "Jeroen Massar" <jeroen@unfix.org>
Cc: "'Brian Somers'" <brian@Awfulhak.org>,
	"'Richard A. Steenbergen'" <ras@e-gerbil.net>,
	"'Peter Pentchev'" <roam@orbitel.bg>, freebsd-security@FreeBSD.org,
	freebsd-gnats-submit@FreeBSD.org, brian@Awfulhak.org
Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip (was: telnetd suckage) 
Date: Sat, 21 Jul 2001 19:38:23 +0100

 > Brian Somers wrote:
 > 
 > > > On Fri, Jul 20, 2001 at 03:58:09PM -0400, Richard A. 
 > > Steenbergen wrote:
 > > > > Speaking of telnetd sucking, did anyone ever get around to fixing
 > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=22595
 > > > > 
 > > > > Doesn't look like it.
 > > > 
 > > > Do you have any actual suggestions on how to 'make realhostname*()
 > > > not suck', as you have so helpfully suggested as a fix?
 > > 
 > > I don't understand this PR.  What's the problem ?  realhostname*() 
 > > takes the connecting IP, turns it into a name and resolves that name. 
 > > If the *original* IP isn't in the list (or if a name couldn't be 
 > > found from the IP), it puts the *original* ip in utmp/wtmp.  If the 
 > > *original* IP is in the list, it uses the name that the IP was turned 
 > > into.
 > 
 > $ host -t ptr 10.0.0.1
 > 1.0.0.10.IN-ADDR.ARPA domain name pointer www.fbi.gov
 > 
 > $ host -t a www.fbi.gov
 > www.fbi.gov has address 32.96.111.130
 > 
 > And then your average dumb admin does a 'who' and oooooh... That dude is
 > leet he/she/it logs in from www.fbi.gov
 > It's also great for your logs... "My box got hacked from www.fbi.gov,
 > the feds are on to me" nice quotes :)
 
 If you log in from 10.0.0.1 and the above resolutions are in effect, 
 realhostname_sa() will put 10.0.0.1 in utmp.
 
 Why are you assuming it doesn't ?
 
 > IRCd and many more (even PuTTY
 > (www.chiark.greenend.org.uk/~sgtatham/putty/) :) do a:
 > - Resolve IP -> hostname
 > - resolve hostname -> IP2
 > - if IP1 != IP2 then hostname = IP1
 
 Which is exactly what realhostname() and realhostname_sa() do.
 
 > That's the problem reported in the 22595 PR...
 
 What is ?
 
 > But it get's even worse (evil grin :), this is a nice trick you can do
 > to fool your ssh which IMHO should be a nice PR on it's own:
 > 
 > 8<-----------
 > jeroen@purgatory:~$ w
 >  6:08PM  up 93 days,  9:58, 1 user, load averages: 0.19, 0.13, 0.14
 > USER             TTY      FROM              LOGIN@  IDLE WHAT
 > jeroen           p1       hell.unfix.org   10:16AM     - w
 > jeroen@purgatory:~$ w -n
 >  6:08PM  up 93 days,  9:58, 1 user, load averages: 0.16, 0.12, 0.13
 > USER             TTY      FROM              LOGIN@  IDLE WHAT
 > jeroen           p1       10.100.13.66     10:16AM     - w -n
 > ------------>8
 > 
 > And guess what:
 > 8<-----------
 > jeroen@purgatory:~$ netstat -an | grep \.22 | less
 > tcp6       0      0  3ffe:8114:2000:2.22    3ffe:8114:2000:2.1628
 > ESTABLISHED
 > tcp4       0      0  *.22                   *.*
 > LISTEN
 > tcp46      0      0  *.22                   *.*
 > LISTEN
 > ------------>8
 > 
 > Now I wonder... why the peep doesn't the wtmp log an IP (either IPv4 or
 > IPv6) alongside a hostname...
 > As you see ... Hell.unfix.org resolves nicely to 10.100.13.66 (an IPv4
 > address) even when I am connected over IPv6...
 > If that isn't one kind of security risk.... Simply change your reverse
 > to something nice and wh0ppa...
 > No-one will even notice thaty you're coming from a remote network far
 > far away...
 > With this nice IPv4/IPv6 trick you could even set a forward IPv4 lookup
 > to make a local IPv4 IP. So that it looks like you logged in from a
 > local system.
 
 But this doesn't happen either.  On my machine, 3ffe:8114:2000:2 is 
 recorded.  In fact, I've just fixed realhostname_sa() so that it 
 records the hostname if it fits in the utmp field and the forward/
 reverse lookup ends up with the same ipv6 number, but even before the 
 fix, the IPv6 number was what's recorded.
 
 Ah, wait, I see what the problem is.  It's ``w'' that's getting it 
 wrong.  It's assuming that it knows the address family of the name in 
 utmp -- and mucks about with name resolutions whether you say -n or 
 not.
 
 ``who'' gives the right answer.
 
 > If that isn't enough 'proof' that the whole utmp/wtmp concept is
 > wrong.... -> YES, I accuse utmp/wtmp not telnetd as you might notice ssh
 > has the same problem :)
 > Telnetd simply does what it _can_ do ... log the hostname to utmp/wtmp,
 > 'w' and friends simply use that info to show it to us...
 
 All daemon programs that log you in and are part of the base system will 
 display this behaviour, but I don't agree that there's any problem 
 with realhostname*().  w(1) is flawed.
 
 > So we basically have the following list of problems:
 >  - wtmp/utmp should have hostname and IPv4 or IPv6 or ...
 >    one could choose IPv4 mapped IP's.. eg: ::ffff:10.100.13.66 (but this
 > could become a prob in the future again...
 >    IMHO adding an extra field containing the ascii representation of the
 > IP/address whatever should do... Which also would be able to log the IPX
 > addy or whatever :)
 >    And the hostname field should contain either nothing (empty) or
 > should contain the ascii representation of the address, that's what
 > forward&reverse resolve is for...
 
 The extra field should hold the address family.
 
 >  - utmp/wtmp-"client"-programs (readers) show the wrong info when
 > 'showing network numbered' because they don't have the full/correct info
 > because they don't have it.
 
 Agreed.
 
 > _if/when_ these get fixed even "dumb admins/users" won't go around
 > telling that they got hacked by the FBI or the CIA simply because some
 > kiddy with reverse access,
 > which currently is quite easy to obtain with all those IPv6
 > tunnelbrokers around who don't give anything about (possible) abuse from
 > their clients.
 > And the same goes for IPv4 ofcourse.... Simply insert a PTR record...
 > and tada... you're now coming from a NASA host... how 1337 or whatever
 > spelling those people/things/... prefer...
 
 I don't agree.  A dumb admin/user will do dumb things no matter what 
 the operating system that they're working with does.
 
 If realhostname*() doesn't see the PTR record pointing at a name that 
 resolves back to the IP, it records the IP.
 
 > And like Richard says: THAT REALLY SUCKS.
 
 Which is a pretty useless statement.
 
 > Greets,
 >  Jeroen
 
 I'll have a look at fixing ``w'' -- probably by tearing the -n option 
 out as it's evil.
 
 I won't add the extra field to utmp however.  This has been discussed 
 before and it would break too much.  Programs should simply not 
 attempt to muck about with things when they don't have enough 
 information.
 
 -- 
 Brian <brian@freebsd-services.com>                <brian@Awfulhak.org>
       http://www.freebsd-services.com/        <brian@[uk.]FreeBSD.org>
 Don't _EVER_ lose your sense of humour !      <brian@[uk.]OpenBSD.org>
 
 

From: "Richard A. Steenbergen" <ras@e-gerbil.net>
To: Brian Somers <brian@Awfulhak.org>
Cc: Jeroen Massar <jeroen@unfix.org>,
	'Peter Pentchev' <roam@orbitel.bg>, freebsd-security@FreeBSD.org,
	freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip (was:
 telnetd suckage) 
Date: Sat, 21 Jul 2001 15:14:40 -0400 (EDT)

 On Sat, 21 Jul 2001, Brian Somers wrote:
 
 > > Brian Somers wrote:
 > > 
 > > $ host -t ptr 10.0.0.1
 > > 1.0.0.10.IN-ADDR.ARPA domain name pointer www.fbi.gov
 > > 
 > > $ host -t a www.fbi.gov
 > > www.fbi.gov has address 32.96.111.130
 > > 
 > > And then your average dumb admin does a 'who' and oooooh... That dude is
 > > leet he/she/it logs in from www.fbi.gov
 > > It's also great for your logs... "My box got hacked from www.fbi.gov,
 > > the feds are on to me" nice quotes :)
 > 
 > If you log in from 10.0.0.1 and the above resolutions are in effect, 
 > realhostname_sa() will put 10.0.0.1 in utmp.
 
 I think the problem would be obvious from a security prospective. You'll
 note that not only does the bad dns get passed to the system from telnetd,
 but the bad IP, an arbitrary IP. Not only is it a perfect spoof but its
 easy to control from the attackers side, they just need control over a
 domain forward. Did you ever hear of a little thing called trusted hosts?
 Infact, won't this be the IP that is passed to tcp wrappers and other
 security checks?
 
 > If realhostname*() doesn't see the PTR record pointing at a name that 
 > resolves back to the IP, it records the IP.
 > 
 > > And like Richard says: THAT REALLY SUCKS.
 > 
 > Which is a pretty useless statement.
 
 Well there are two solutions, stop using realhostname*() or make those
 functions actually work. Anything which does reverse forward then reverse
 again and takes the forward and reverse IPs is so broken that calling it
 real anything is laughable at best. I figured that would be blatantly
 obvious, sorry for the false assumption.
 
 -- 
 Richard A Steenbergen <ras@e-gerbil.net>       http://www.e-gerbil.net/ras
 PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)
 

From: "Richard A. Steenbergen" <ras@e-gerbil.net>
To: Brian Somers <brian@Awfulhak.org>
Cc: Peter Pentchev <roam@orbitel.bg>, freebsd-security@FreeBSD.org,
	freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip (was:
 telnetd suckage)
Date: Sat, 21 Jul 2001 15:21:34 -0400 (EDT)

 On Sat, 21 Jul 2001, Brian Somers wrote:
 
 > The example in the PR means that someone connected from 199.95.76.12.
 
 Sorry, at the time of the PR writing, that was the correct IP for
 www.senate.gov.
 
 traceroute to 199.95.76.12 (199.95.76.12), 64 hops max, 40 byte packets
 ...
 10  senate-gw3.customer.alter.net (157.130.33.182)  14.671 ms  14.310 ms  14.885 ms
 
 It's very simple:
 
 You are 1.2.3.4, your reverse dns is your.domain.com. You control
 domain.com, so you setup multiple CNAMES for "your", one pointing to
 1.2.3.4 and one pointing to the IP you wish to spoof (we'll call it
 9.8.7.6). When you connect to telnet, it reverses 1.2.3.4 to
 your.domain.com, forwards your.domain.com to 9.8.7.6, reverses 9.8.7.6 to
 www.senate.gov, and passes on 9.8.7.6 to the rest of the system.
 
 Spoofing at its finest...
 
 -- 
 Richard A Steenbergen <ras@e-gerbil.net>       http://www.e-gerbil.net/ras
 PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)
 

From: Brian Somers <brian@Awfulhak.org>
To: "Richard A. Steenbergen" <ras@e-gerbil.net>
Cc: Brian Somers <brian@Awfulhak.org>,
	Peter Pentchev <roam@orbitel.bg>, freebsd-security@FreeBSD.org,
	freebsd-gnats-submit@FreeBSD.org, brian@Awfulhak.org
Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip (was: telnetd suckage) 
Date: Sat, 21 Jul 2001 23:34:30 +0100

 > On Sat, 21 Jul 2001, Brian Somers wrote:
 > 
 > > The example in the PR means that someone connected from 199.95.76.12.
 > 
 > Sorry, at the time of the PR writing, that was the correct IP for
 > www.senate.gov.
 > 
 > traceroute to 199.95.76.12 (199.95.76.12), 64 hops max, 40 byte packets
 > ...
 > 10  senate-gw3.customer.alter.net (157.130.33.182)  14.671 ms  14.310 ms  14.885 ms
 > 
 > It's very simple:
 > 
 > You are 1.2.3.4, your reverse dns is your.domain.com. You control
 > domain.com, so you setup multiple CNAMES for "your", one pointing to
 > 1.2.3.4 and one pointing to the IP you wish to spoof (we'll call it
 > 9.8.7.6). When you connect to telnet, it reverses 1.2.3.4 to
 > your.domain.com, forwards your.domain.com to 9.8.7.6, reverses 9.8.7.6 to
 > www.senate.gov, and passes on 9.8.7.6 to the rest of the system.
 > 
 > Spoofing at its finest...
 
 I must be getting something wrong.  I wrote this stuff, and wrote it 
 so that 1.2.3.4 is looked up giving your.domain.com, your.domain.com 
 is looked up to give 1.2.3.4 and 9.8.7.6.  As 1.2.3.4 is correct, 
 your.domain.com is recorded in utmp (not 9.8.7.6).
 
 Yes, there is a problem where we've basically trusted a DNS that we 
 don't own -- and that is a risk.  But I can't see why 9.8.7.6 is 
 relevant, *except* that ``w -n'' may be mentioning it.
 
 Am I misinterpreting things or is the real problem that a forward and 
 reverse DNS can both conspire against you ?  Or is the real problem 
 just ``w''s -n flag ?
 
 > -- 
 > Richard A Steenbergen <ras@e-gerbil.net>       http://www.e-gerbil.net/ras
 > PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)
 
 -- 
 Brian <brian@freebsd-services.com>                <brian@Awfulhak.org>
       http://www.freebsd-services.com/        <brian@[uk.]FreeBSD.org>
 Don't _EVER_ lose your sense of humour !      <brian@[uk.]OpenBSD.org>
 
 

From: "Richard A. Steenbergen" <ras@e-gerbil.net>
To: Brian Somers <brian@Awfulhak.org>
Cc: Peter Pentchev <roam@orbitel.bg>,
	freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip (was:
 telnetd suckage) 
Date: Sun, 22 Jul 2001 05:52:36 -0400 (EDT)

 On Sat, 21 Jul 2001, Brian Somers wrote:
 
 > I must be getting something wrong.  I wrote this stuff, and wrote it
 > so that 1.2.3.4 is looked up giving your.domain.com, your.domain.com
 > is looked up to give 1.2.3.4 and 9.8.7.6.  As 1.2.3.4 is correct,
 > your.domain.com is recorded in utmp (not 9.8.7.6).
 > 
 > Yes, there is a problem where we've basically trusted a DNS that we
 > don't own -- and that is a risk.  But I can't see why 9.8.7.6 is
 > relevant, *except* that ``w -n'' may be mentioning it.
 > 
 > Am I misinterpreting things or is the real problem that a forward and
 > reverse DNS can both conspire against you ?  Or is the real problem
 > just ``w''s -n flag ?
 
 Ok I actually took a look at what was going on. I don't know why I blamed
 realhostname*() since that was many many months ago but I'm sure I had a
 good reason. :P Perhaps because it only affected telnetd, not sshd.
 
 At any rate it appears that realhostname*() gets it right and passes on
 the correct reverse as remote_hostname. It even appears that tcp wrappers
 get the correct IP, or at least a deny on the real IP stops it cold.
 However, the system is getting is wrong in utmp and wtmp (not w or who
 specific), it's putting the actual false IP.
 
 -- 
 Richard A Steenbergen <ras@e-gerbil.net>       http://www.e-gerbil.net/ras
 PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)
 

From: "Richard A. Steenbergen" <ras@e-gerbil.net>
To: Brian Somers <brian@Awfulhak.org>
Cc: Peter Pentchev <roam@orbitel.bg>,
	freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip (was:
 telnetd suckage) 
Date: Sun, 22 Jul 2001 06:12:42 -0400 (EDT)

 On Sun, 22 Jul 2001, Richard A. Steenbergen wrote:
 
 > Ok I actually took a look at what was going on. I don't know why I blamed
 > realhostname*() since that was many many months ago but I'm sure I had a
 > good reason. :P Perhaps because it only affected telnetd, not sshd.
 > 
 > At any rate it appears that realhostname*() gets it right and passes on
 > the correct reverse as remote_hostname. It even appears that tcp wrappers
 > get the correct IP, or at least a deny on the real IP stops it cold.
 > However, the system is getting is wrong in utmp and wtmp (not w or who
 > specific), it's putting the actual false IP.
 
 Woops hit send prematurely on that (3:05AM here). It looks like the
 problem is actually in login, I set UseLogin yes in the sshd_config and
 I'm seeing the same problem now. Looks like login does its own lookup on
 what it gets passed, and just picks one of the CNAMEs. Still a potential
 security problem though, a hacker could pretend to be a legitimate user to
 everyone else on the machine.
 
 I appologise for disparaging telnetd's reputation. :P
 
 -- 
 Richard A Steenbergen <ras@e-gerbil.net>       http://www.e-gerbil.net/ras
 PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)
 

From: Hajimu UMEMOTO <ume@mahoroba.org>
To: brian@Awfulhak.org
Cc: ras@e-gerbil.net, roam@orbitel.bg, freebsd-security@FreeBSD.org,
	freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip
Date: Mon, 23 Jul 2001 05:30:51 +0900 (JST)

 >>>>> On Sat, 21 Jul 2001 23:34:30 +0100
 >>>>> Brian Somers <brian@Awfulhak.org> said:
 
 brian> Yes, there is a problem where we've basically trusted a DNS that we 
 brian> don't own -- and that is a risk.  But I can't see why 9.8.7.6 is 
 brian> relevant, *except* that ``w -n'' may be mentioning it.
 
 brian> Am I misinterpreting things or is the real problem that a forward and 
 brian> reverse DNS can both conspire against you ?  Or is the real problem 
 brian> just ``w''s -n flag ?
 
 It is problem of w(1).  `w -n' does forward lookup for IPv4 only and
 IPv6 is not supported at all.  When available, login(1) writes
 hostname into utmp instead of IP address.  If hostname is saved, `w
 -n' queries A RR for the hostname.
 Real problem is that UT_HOSTSIZE is too short to hold IPv6 address.
 Is there any chance to expand UT_HOSTSIZE in time to 5.0-RELEASE.  It
 apparently breaks binary compatibility.
 
 --
 Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
 ume@mahoroba.org  ume@bisd.hitachi.co.jp  ume@{,jp.}FreeBSD.org
 http://www.imasy.org/~ume/

From: "Richard A. Steenbergen" <ras@e-gerbil.net>
To: Hajimu UMEMOTO <ume@mahoroba.org>
Cc: brian@Awfulhak.org, roam@orbitel.bg,
	freebsd-security@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip
Date: Sun, 22 Jul 2001 16:38:13 -0400 (EDT)

 On Mon, 23 Jul 2001, Hajimu UMEMOTO wrote:
 
 > >>>>> On Sat, 21 Jul 2001 23:34:30 +0100
 > >>>>> Brian Somers <brian@Awfulhak.org> said:
 > 
 > brian> Yes, there is a problem where we've basically trusted a DNS that we 
 > brian> don't own -- and that is a risk.  But I can't see why 9.8.7.6 is 
 > brian> relevant, *except* that ``w -n'' may be mentioning it.
 > 
 > brian> Am I misinterpreting things or is the real problem that a forward and 
 > brian> reverse DNS can both conspire against you ?  Or is the real problem 
 > brian> just ``w''s -n flag ?
 > 
 > It is problem of w(1).  `w -n' does forward lookup for IPv4 only and
 > IPv6 is not supported at all.  When available, login(1) writes
 > hostname into utmp instead of IP address.  If hostname is saved, `w
 > -n' queries A RR for the hostname.
 > Real problem is that UT_HOSTSIZE is too short to hold IPv6 address.
 > Is there any chance to expand UT_HOSTSIZE in time to 5.0-RELEASE.  It
 > apparently breaks binary compatibility.
 
 This is not the problem here, login is writing the false IP to utmp.
 
 -- 
 Richard A Steenbergen <ras@e-gerbil.net>       http://www.e-gerbil.net/ras
 PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)
 

From: Hajimu UMEMOTO <ume@mahoroba.org>
To: ras@e-gerbil.net
Cc: brian@Awfulhak.org, roam@orbitel.bg,
	freebsd-security@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip
Date: Mon, 23 Jul 2001 06:09:35 +0900 (JST)

 >>>>> On Sun, 22 Jul 2001 16:38:13 -0400 (EDT)
 >>>>> "Richard A. Steenbergen" <ras@e-gerbil.net> said:
 
 ras> On Mon, 23 Jul 2001, Hajimu UMEMOTO wrote:
 
 > >>>>> On Sat, 21 Jul 2001 23:34:30 +0100
 > >>>>> Brian Somers <brian@Awfulhak.org> said:
 > 
 > brian> Yes, there is a problem where we've basically trusted a DNS that we 
 > brian> don't own -- and that is a risk.  But I can't see why 9.8.7.6 is 
 > brian> relevant, *except* that ``w -n'' may be mentioning it.
 > 
 > brian> Am I misinterpreting things or is the real problem that a forward and 
 > brian> reverse DNS can both conspire against you ?  Or is the real problem 
 > brian> just ``w''s -n flag ?
 > 
 > It is problem of w(1).  `w -n' does forward lookup for IPv4 only and
 > IPv6 is not supported at all.  When available, login(1) writes
 > hostname into utmp instead of IP address.  If hostname is saved, `w
 > -n' queries A RR for the hostname.
 > Real problem is that UT_HOSTSIZE is too short to hold IPv6 address.
 > Is there any chance to expand UT_HOSTSIZE in time to 5.0-RELEASE.  It
 > apparently breaks binary compatibility.
 
 ras> This is not the problem here, login is writing the false IP to utmp.
 
 I cannot agree with you here.  You did ssh via IPv6.  login(1) cannot
 write IPv6 address into utmp.  In this case, realhostname_sa(3)
 returns hostname.  The cases that IP address is saved are:
 
     - reverse or forward lookup was failed,
     - the result of reverse -> forward lookup doesn't match against
       the address, or
     - IPv4
 
 Even if IPv6 address is saved, since it is chopped, it will fail to do
 reverse lookup.
 
 --
 Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
 ume@mahoroba.org  ume@bisd.hitachi.co.jp  ume@{,jp.}FreeBSD.org
 http://www.imasy.org/~ume/

From: Matt Dillon <dillon@earth.backplane.com>
To: Hajimu UMEMOTO <ume@mahoroba.org>
Cc: brian@Awfulhak.org, ras@e-gerbil.net, roam@orbitel.bg,
	freebsd-security@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip
Date: Sun, 22 Jul 2001 14:17:58 -0700 (PDT)

 :It is problem of w(1).  `w -n' does forward lookup for IPv4 only and
 :IPv6 is not supported at all.  When available, login(1) writes
 :hostname into utmp instead of IP address.  If hostname is saved, `w
 :-n' queries A RR for the hostname.
 :Real problem is that UT_HOSTSIZE is too short to hold IPv6 address.
 :Is there any chance to expand UT_HOSTSIZE in time to 5.0-RELEASE.  It
 :apparently breaks binary compatibility.
 :
 :--
 :Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
 :ume@mahoroba.org  ume@bisd.hitachi.co.jp  ume@{,jp.}FreeBSD.org
 
     I think if we are going to increase UT_HOSTSIZE, then 5.0 (i.e. now)
     is exactly the right time to do it.  How large does UT_HOSTSIZE
     have to be to accomodate an IPV6 address?
 
 					-Matt

From: Anthony Schneider <aschneid@mail.slc.edu>
To: Matt Dillon <dillon@earth.backplane.com>
Cc: Hajimu UMEMOTO <ume@mahoroba.org>, brian@Awfulhak.org,
	ras@e-gerbil.net, roam@orbitel.bg, freebsd-security@FreeBSD.ORG,
	freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip
Date: Sun, 22 Jul 2001 17:22:32 -0400

 16 bytes.
 
 On Sun, Jul 22, 2001 at 02:17:58PM -0700, Matt Dillon wrote:
 > 
 > :It is problem of w(1).  `w -n' does forward lookup for IPv4 only and
 > :IPv6 is not supported at all.  When available, login(1) writes
 > :hostname into utmp instead of IP address.  If hostname is saved, `w
 > :-n' queries A RR for the hostname.
 > :Real problem is that UT_HOSTSIZE is too short to hold IPv6 address.
 > :Is there any chance to expand UT_HOSTSIZE in time to 5.0-RELEASE.  It
 > :apparently breaks binary compatibility.
 > :
 > :--
 > :Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
 > :ume@mahoroba.org  ume@bisd.hitachi.co.jp  ume@{,jp.}FreeBSD.org
 > 
 >     I think if we are going to increase UT_HOSTSIZE, then 5.0 (i.e. now)
 >     is exactly the right time to do it.  How large does UT_HOSTSIZE
 >     have to be to accomodate an IPV6 address?
 > 
 > 					-Matt
 > 
 > To Unsubscribe: send mail to majordomo@FreeBSD.org
 > with "unsubscribe freebsd-security" in the body of the message

From: Peter Pentchev <roam@orbitel.bg>
To: Anthony Schneider <aschneid@mail.slc.edu>
Cc: Matt Dillon <dillon@earth.backplane.com>,
	Hajimu UMEMOTO <ume@mahoroba.org>, brian@Awfulhak.org,
	ras@e-gerbil.net, freebsd-security@FreeBSD.ORG,
	freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip
Date: Mon, 23 Jul 2001 00:29:12 +0300

 Not really; I'd think that utmp structures hold an ASCII string,
 not the binary address representation.  Thus, the current UT_HOSTSIZE
 of 16 is quite enough to hold an IPv4 address (4*3 + 3 dots), but not
 nearly enough for full-blown IPv6 addresses.
 
 G'luck,
 Peter
 
 -- 
 If this sentence didn't exist, somebody would have invented it.
 
 On Sun, Jul 22, 2001 at 05:22:32PM -0400, Anthony Schneider wrote:
 > 16 bytes.
 > 
 > On Sun, Jul 22, 2001 at 02:17:58PM -0700, Matt Dillon wrote:
 > > 
 > > :It is problem of w(1).  `w -n' does forward lookup for IPv4 only and
 > > :IPv6 is not supported at all.  When available, login(1) writes
 > > :hostname into utmp instead of IP address.  If hostname is saved, `w
 > > :-n' queries A RR for the hostname.
 > > :Real problem is that UT_HOSTSIZE is too short to hold IPv6 address.
 > > :Is there any chance to expand UT_HOSTSIZE in time to 5.0-RELEASE.  It
 > > :apparently breaks binary compatibility.
 > > :
 > > :--
 > > :Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
 > > :ume@mahoroba.org  ume@bisd.hitachi.co.jp  ume@{,jp.}FreeBSD.org
 > > 
 > >     I think if we are going to increase UT_HOSTSIZE, then 5.0 (i.e. now)
 > >     is exactly the right time to do it.  How large does UT_HOSTSIZE
 > >     have to be to accomodate an IPV6 address?
 > > 
 > > 					-Matt

From: Hajimu UMEMOTO <ume@mahoroba.org>
To: aschneid@mail.slc.edu
Cc: dillon@earth.backplane.com, brian@Awfulhak.org, ras@e-gerbil.net,
	roam@orbitel.bg, freebsd-security@FreeBSD.ORG,
	freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip
Date: Mon, 23 Jul 2001 06:34:58 +0900 (JST)

 >>>>> On Sun, 22 Jul 2001 17:22:32 -0400
 >>>>> Anthony Schneider <aschneid@mail.slc.edu> said:
 
 aschneid> 16 bytes.
 
 It's a binary form.  We need 40 bytes for global address.  To save
 site-local or link-local address, we need more space for scope
 identifier.  I believe the length of scope identifier is not defined
 and system specific.
 
 global address:
 
 	1234567890123456789012345678901234567890
 	NNNN:NNNN:NNNN:NNNN:NNNN:NNNN:NNNN:NNNN\n
 
 scoped address:
 
 	1234567890123456789012345678901234567890
 	NNNN:NNNN:NNNN:NNNN:NNNN:NNNN:NNNN:NNNN%fxp0\n
 
 There is one more consideration.  `:' is conflict with X.  I have no
 particular idea to solve this problem.  Enclosing IPv6 address with
 `[' and `]' doesn't help without changing X side.
 
 --
 Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
 ume@mahoroba.org  ume@bisd.hitachi.co.jp  ume@{,jp.}FreeBSD.org
 http://www.imasy.org/~ume/

From: Matt Dillon <dillon@earth.backplane.com>
To: Hajimu UMEMOTO <ume@mahoroba.org>
Cc: aschneid@mail.slc.edu, dillon@earth.backplane.com,
	brian@Awfulhak.org, ras@e-gerbil.net, roam@orbitel.bg,
	freebsd-security@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip
Date: Sun, 22 Jul 2001 15:57:56 -0700 (PDT)

 :>>>>> On Sun, 22 Jul 2001 17:22:32 -0400
 :>>>>> Anthony Schneider <aschneid@mail.slc.edu> said:
 :
 :aschneid> 16 bytes.
 :
 :It's a binary form.  We need 40 bytes for global address.  To save
 :site-local or link-local address, we need more space for scope
 :identifier.  I believe the length of scope identifier is not defined
 :and system specific.
 :
 :global address:
 :
 :	1234567890123456789012345678901234567890
 :	NNNN:NNNN:NNNN:NNNN:NNNN:NNNN:NNNN:NNNN\n
 :
 :scoped address:
 :
 :	1234567890123456789012345678901234567890
 :	NNNN:NNNN:NNNN:NNNN:NNNN:NNNN:NNNN:NNNN%fxp0\n
 :
 :There is one more consideration.  `:' is conflict with X.  I have no
 :particular idea to solve this problem.  Enclosing IPv6 address with
 :`[' and `]' doesn't help without changing X side.
 :
 :--
 :Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
 :ume@mahoroba.org  ume@bisd.hitachi.co.jp  ume@{,jp.}FreeBSD.org
 :http://www.imasy.org/~ume/
 
     Ok, it sounds like 56 bytes ought to be sufficient.  This will
     increase the lastlog structure from 28 bytes to 68 bytes
     and the utmp/wtmp structure from 44 bytes to 84 bytes.  A
     buildworld would be necessary to deal with the change and
     certrain ports, such as ftpd, would have to be rebuilt
     (for those people using them) to avoid corruption.  utmp
     is one of the few structures in the system which is 
     written out 'manually' by various programs, which is why
 .   changing the size of the structure is so nasty.
 
     The issue with X is a separate problem.
 
 					-Matt

From: "Jeroen Massar" <jeroen@unfix.org>
To: "'Matt Dillon'" <dillon@earth.backplane.com>,
	"'Hajimu UMEMOTO'" <ume@mahoroba.org>
Cc: <aschneid@mail.slc.edu>, <brian@Awfulhak.org>,
	<ras@e-gerbil.net>, <roam@orbitel.bg>,
	<freebsd-security@FreeBSD.ORG>, <freebsd-gnats-submit@FreeBSD.ORG>
Subject: RE: bin/22595: telnetd tricked into using arbitrary peer ip
Date: Mon, 23 Jul 2001 01:58:33 +0200

 Matt Dillon <dillon@earth.backplane.com> wrote:
 
 <SNIP>
 > :	1234567890123456789012345678901234567890
 > :	NNNN:NNNN:NNNN:NNNN:NNNN:NNNN:NNNN:NNNN%fxp0\n
 > :
 > :There is one more consideration.  `:' is conflict with X.  I have no
 > :particular idea to solve this problem.  Enclosing IPv6 address with
 > :`[' and `]' doesn't help without changing X side.
 > :
 
 >     Ok, it sounds like 56 bytes ought to be sufficient.  This will
 >     increase the lastlog structure from 28 bytes to 68 bytes
 >     and the utmp/wtmp structure from 44 bytes to 84 bytes.  A
 >     buildworld would be necessary to deal with the change and
 >     certrain ports, such as ftpd, would have to be rebuilt
 >     (for those people using them) to avoid corruption.  utmp
 >     is one of the few structures in the system which is 
 >     written out 'manually' by various programs, which is why
 > .   changing the size of the structure is so nasty.
 > 
 >     The issue with X is a separate problem.
 
 And what if we get IP18 in a couple of years? Resize again???
 Better to change it to:
 
 char Hostname[size];
 char Address[size];
 int AddressType;  // AF_INET6, AF_INET, AF_* whatever... these are
 standardized (kinda :)
 
 And ofcourse... For 'filling' these info's there should be standard
 functions, for reading it too (in different formats ofcourse ;)...
 Which makes sure that you don't have to upgrade every util whenever the
 format of that file changes again.... If at all it stays a file in the
 future...
 
 Even then.... IMHO one should log both hostname _AND_ IP...
 Following situation:
 
 23 June 2001 - I log into a machine from 10.1.2.3 which maps to
 bla.example.com which points to 10.1.2.3 thus bla.example.com is
 logged...
 24 June 2001 - The bla.example.com A is changed to 192.168.2.1,
 192.168.2.1 gets pointed back to bla.example.com...
 
 Now I actually did very evil things with that box on the 23rd.... So the
 admin of the box wants to hunt me down and checks his/her/it's logs:
 Ooe..... that evil user came from 'bla.example.com' let's find out
 his/her/it's IP....aha 192.168.2.1 <-------- OOOPS... Not even the same
 provider I actually came from to do all those very evil things...
 
 So long for your 'nice' loggin facility... (and thanks for all the
 fish... :) I know... It's been there for a long time and over many many
 unices but that doesn't say it's still acceptable...
 
 Only storing the IP is useless too ofcourse.. Because then you never
 know what the old hostname (for which you actually accepted) was...
 Especially if you got /etc/hosts.allow with the old reverse in it, but
 not the new one etc...
 
 Greets,
  Jeroen
 
 

From: Brian Somers <brian@Awfulhak.org>
To: Matt Dillon <dillon@earth.backplane.com>
Cc: Hajimu UMEMOTO <ume@mahoroba.org>, aschneid@mail.slc.edu,
	brian@Awfulhak.org, ras@e-gerbil.net, roam@orbitel.bg,
	freebsd-security@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip 
Date: Mon, 23 Jul 2001 00:55:16 +0100

 > :>>>>> On Sun, 22 Jul 2001 17:22:32 -0400
 > :>>>>> Anthony Schneider <aschneid@mail.slc.edu> said:
 > :
 > :aschneid> 16 bytes.
 > :
 > :It's a binary form.  We need 40 bytes for global address.  To save
 > :site-local or link-local address, we need more space for scope
 > :identifier.  I believe the length of scope identifier is not defined
 > :and system specific.
 > :
 > :global address:
 > :
 > :	1234567890123456789012345678901234567890
 > :	NNNN:NNNN:NNNN:NNNN:NNNN:NNNN:NNNN:NNNN\n
 > :
 > :scoped address:
 > :
 > :	1234567890123456789012345678901234567890
 > :	NNNN:NNNN:NNNN:NNNN:NNNN:NNNN:NNNN:NNNN%fxp0\n
 > :
 > :There is one more consideration.  `:' is conflict with X.  I have no
 > :particular idea to solve this problem.  Enclosing IPv6 address with
 > :`[' and `]' doesn't help without changing X side.
 > :
 > :--
 > :Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
 > :ume@mahoroba.org  ume@bisd.hitachi.co.jp  ume@{,jp.}FreeBSD.org
 > :http://www.imasy.org/~ume/
 > 
 >     Ok, it sounds like 56 bytes ought to be sufficient.  This will
 >     increase the lastlog structure from 28 bytes to 68 bytes
 >     and the utmp/wtmp structure from 44 bytes to 84 bytes.  A
 >     buildworld would be necessary to deal with the change and
 >     certrain ports, such as ftpd, would have to be rebuilt
 >     (for those people using them) to avoid corruption.  utmp
 >     is one of the few structures in the system which is 
 >     written out 'manually' by various programs, which is why
 > .   changing the size of the structure is so nasty.
 
 I think an API should really be introduced if we're going to do 
 this - there's no point in doing only half the job :-/
 
 I'm no great expert with IPv6, but if the scoping needs to be 
 recorded here, who can guarantee that the length of the interface 
 name will fit (remember, interface numbers can easily be something 
 like 10000 -- think ifconfig gif10000 create, and that's not even 
 considering the name itself having no limits as far as I'm aware).
 
 Besides, we also need an address family field.  It seems that part of 
 the problem described in this PR is the fact that running ``login -p 
 hostname blah'' results in login(1) doing a reverse lookup on 
 hostname - assuming it's IPv4.  w(1) does the same.
 
 >     The issue with X is a separate problem.
 
 The X-style ``machine:screen'' thing doesn't conflict as an IPv6 
 address will always have at least two ``:''s in it and an X entry 
 will only ever have one.
 
 > 					-Matt
 
 -- 
 Brian <brian@freebsd-services.com>                <brian@Awfulhak.org>
       http://www.freebsd-services.com/        <brian@[uk.]FreeBSD.org>
 Don't _EVER_ lose your sense of humour !      <brian@[uk.]OpenBSD.org>
 
 

From: Brian Somers <brian@Awfulhak.org>
To: "Jeroen Massar" <jeroen@unfix.org>
Cc: "'Matt Dillon'" <dillon@earth.backplane.com>,
	"'Hajimu UMEMOTO'" <ume@mahoroba.org>, aschneid@mail.slc.edu,
	brian@Awfulhak.org, ras@e-gerbil.net, roam@orbitel.bg,
	freebsd-security@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG,
	brian@Awfulhak.org
Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip 
Date: Mon, 23 Jul 2001 01:25:17 +0100

 > Even then.... IMHO one should log both hostname _AND_ IP...
 
 I don't think that's necessary.
 
 > Following situation:
 > 
 > 23 June 2001 - I log into a machine from 10.1.2.3 which maps to
 > bla.example.com which points to 10.1.2.3 thus bla.example.com is
 > logged...
 > 24 June 2001 - The bla.example.com A is changed to 192.168.2.1,
 > 192.168.2.1 gets pointed back to bla.example.com...
 > 
 > Now I actually did very evil things with that box on the 23rd.... So the
 > admin of the box wants to hunt me down and checks his/her/it's logs:
 > Ooe..... that evil user came from 'bla.example.com' let's find out
 > his/her/it's IP....aha 192.168.2.1 <-------- OOOPS... Not even the same
 > provider I actually came from to do all those very evil things...
 > 
 > So long for your 'nice' loggin facility... (and thanks for all the
 > fish... :) I know... It's been there for a long time and over many many
 > unices but that doesn't say it's still acceptable...
 
 The owner of what's logged will know the answer -- in this case, 
 talking to the admins of bla.example.com will result in them saying 
 ``ah, that box had it's IP number changed''.  I think the way this is 
 done is as appropriate as it ever was.
 
 > Only storing the IP is useless too ofcourse.. Because then you never
 > know what the old hostname (for which you actually accepted) was...
 > Especially if you got /etc/hosts.allow with the old reverse in it, but
 > not the new one etc...
 
 Your tcp-wrapper rules are subject to the same DNS confusion as the 
 utmp file is, but I don't think there's anything wrong with that.  If 
 you don't trust the admin of example.com, then block the whole domain 
 :)  But that's another argument^Wdiscussion....
 
 > Greets,
 >  Jeroen
 
 -- 
 Brian <brian@freebsd-services.com>                <brian@Awfulhak.org>
       http://www.freebsd-services.com/        <brian@[uk.]FreeBSD.org>
 Don't _EVER_ lose your sense of humour !      <brian@[uk.]OpenBSD.org>
 
 

From: "Jeroen Massar" <jeroen@unfix.org>
To: "'Brian Somers'" <brian@Awfulhak.org>
Cc: "'Matt Dillon'" <dillon@earth.backplane.com>,
	"'Hajimu UMEMOTO'" <ume@mahoroba.org>, <aschneid@mail.slc.edu>,
	<ras@e-gerbil.net>, <roam@orbitel.bg>,
	<freebsd-security@FreeBSD.ORG>, <freebsd-gnats-submit@FreeBSD.ORG>
Subject: RE: bin/22595: telnetd tricked into using arbitrary peer ip 
Date: Mon, 23 Jul 2001 03:15:59 +0200

 Behalf Of Brian Somers <brian@awfulhak.org> wrote:
 > 
 > > Even then.... IMHO one should log both hostname _AND_ IP...
 
 That's why I put the IMHO in there ;)
 
 > 
 > I don't think that's necessary.
 > 
 > > Following situation:
 > > 
 > > 23 June 2001 - I log into a machine from 10.1.2.3 which maps to
 > > bla.example.com which points to 10.1.2.3 thus bla.example.com is
 > > logged...
 > > 24 June 2001 - The bla.example.com A is changed to 192.168.2.1,
 > > 192.168.2.1 gets pointed back to bla.example.com...
 > > 
 > > Now I actually did very evil things with that box on the 
 > 23rd.... So the
 > > admin of the box wants to hunt me down and checks his/her/it's logs:
 > > Ooe..... that evil user came from 'bla.example.com' let's find out
 > > his/her/it's IP....aha 192.168.2.1 <-------- OOOPS... Not 
 > even the same
 > > provider I actually came from to do all those very evil things...
 > > 
 > > So long for your 'nice' loggin facility... (and thanks for all the
 > > fish... :) I know... It's been there for a long time and 
 > over many many
 > > unices but that doesn't say it's still acceptable...
 > 
 > The owner of what's logged will know the answer -- in this case, 
 > talking to the admins of bla.example.com will result in them saying 
 > ``ah, that box had it's IP number changed''.  I think the way this is 
 > done is as appropriate as it ever was.
 Hmm... Okay.... Kind of bad reasoning.... But unless logsize is in
 question I don't think nobody will object to having both the IP and
 hostname in the file...
 Surely because of the confusion part... And the fact that an evil admin
 won't reply, but that will give the same problems :)
 And probably an admin doesn't even know where the host was before as
 they either work in teams or maybe could have been put there temporary
 by another evil intruder or something :) Now if that isn't farfetched
 <grin>
 
 > > Only storing the IP is useless too ofcourse.. Because then you never
 > > know what the old hostname (for which you actually accepted) was...
 > > Especially if you got /etc/hosts.allow with the old reverse 
 > in it, but
 > > not the new one etc...
 > 
 > Your tcp-wrapper rules are subject to the same DNS confusion as the 
 > utmp file is, but I don't think there's anything wrong with that.  If 
 > you don't trust the admin of example.com, then block the whole domain 
 > :)  But that's another argument^Wdiscussion....
 <grin>
 Problem being... hacked stuff.... blabla... other discussion :)
 
 At least we are now at the point where everybody (it is everybody not?
 :) sees that the logging is doing very wrong (SUX :) things... :)
 
 About the API thing..... Check the other mail... I also suggested it
 there...
 One thing that should be considered to be done if an API is created... :
 make a backport to previous versions of FreeBSD and actually
 *BSD/Linux/* :)
 This also encourages program writers/maintainers to adopt it quicker, as
 it's less hassle for them and they don't have to make the
 "pre-FreeBSD-5" case or something...
 And the best thing of an API (if done right :): seperation of the back
 and the frontend... which makes changes like this even easier...
 
 Greets,
  Jeroen
 

From: Matt Dillon <dillon@earth.backplane.com>
To: "Jeroen Massar" <jeroen@unfix.org>
Cc: "'Brian Somers'" <brian@Awfulhak.org>,
	"'Hajimu UMEMOTO'" <ume@mahoroba.org>, <aschneid@mail.slc.edu>,
	<ras@e-gerbil.net>, <roam@orbitel.bg>,
	<freebsd-security@FreeBSD.ORG>, <freebsd-gnats-submit@FreeBSD.ORG>
Subject: Re: RE: bin/22595: telnetd tricked into using arbitrary peer ip 
Date: Sun, 22 Jul 2001 20:54:55 -0700 (PDT)

     All very nice, guys, but not realistic.  Only FreeBSD uses an API.
     Third party programs access the structure directly for the most
     part so adding new fields to the structure will just cause more
     garbage to be written to the file (many third party programs 
     don't bother to bzero the structure before writing it out).  We 
     aren't going to add a separate hostname[] array... we just got
     through ripping out the hostname crap, because there was never 
     enough room in the field to actually store the FQDN, and many
     programs don't bother to verify the forward against the
     reverse anyway so the data would be suspect.  And short
     of making a 200+ character array to hold it, which would be masive
     bloat, there is no way to fit it in the structure.  If you want to store
     host names for posterity you will have to log-process the file and
     store the results somewhere else.  Every program under the sun assumes
     utmp is a fixed-length structure.
 
     Pretty much our only option is to extend the size of existing fields
     and take the 'oh hell the structure size changed' hit.
 
 i						-Matt

From: Brian Somers <brian@Awfulhak.org>
To: Matt Dillon <dillon@earth.backplane.com>
Cc: "Jeroen Massar" <jeroen@unfix.org>,
	"'Brian Somers'" <brian@Awfulhak.org>,
	"'Hajimu UMEMOTO'" <ume@mahoroba.org>, aschneid@mail.slc.edu,
	ras@e-gerbil.net, roam@orbitel.bg, freebsd-security@FreeBSD.ORG,
	freebsd-gnats-submit@FreeBSD.ORG, brian@Awfulhak.org
Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip 
Date: Mon, 23 Jul 2001 11:12:42 +0100

 >     All very nice, guys, but not realistic.  Only FreeBSD uses an API.
 >     Third party programs access the structure directly for the most
 >     part so adding new fields to the structure will just cause more
 >     garbage to be written to the file (many third party programs 
 >     don't bother to bzero the structure before writing it out).  We 
 >     aren't going to add a separate hostname[] array... we just got
 >     through ripping out the hostname crap, because there was never 
 >     enough room in the field to actually store the FQDN, and many
 >     programs don't bother to verify the forward against the
 >     reverse anyway so the data would be suspect.  And short
 >     of making a 200+ character array to hold it, which would be masive
 >     bloat, there is no way to fit it in the structure.  If you want to store
 >     host names for posterity you will have to log-process the file and
 >     store the results somewhere else.  Every program under the sun assumes
 >     utmp is a fixed-length structure.
 > 
 >     Pretty much our only option is to extend the size of existing fields
 >     and take the 'oh hell the structure size changed' hit.
 
 Ok, I agree.  I think we should bump UT_HOSTSIZE to 40 then and only 
 put unscoped addresses in the field (ie, fec0::1, not fec0::1%vr0).
 
 Any disagreements ?  Should this be brought up (explained) on -arch 
 now ?
 
 > i						-Matt
 
 -- 
 Brian <brian@freebsd-services.com>                <brian@Awfulhak.org>
       http://www.freebsd-services.com/        <brian@[uk.]FreeBSD.org>
 Don't _EVER_ lose your sense of humour !      <brian@[uk.]OpenBSD.org>
 
 

From: Brian Somers <brian@Awfulhak.org>
To: Matt Dillon <dillon@earth.backplane.com>
Cc: Jeroen Massar <jeroen@unfix.org>,
	Brian Somers <brian@freebsd-services.com>,
	Hajimu UMEMOTO <ume@mahoroba.org>, aschneid@mail.slc.edu,
	ras@e-gerbil.net, roam@orbitel.bg, freebsd-security@FreeBSD.ORG,
	freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip 
Date: Mon, 23 Jul 2001 12:17:34 +0100

 Matt wrote:
 >  >     Pretty much our only option is to extend the size of existing fields
 >  >     and take the 'oh hell the structure size changed' hit.
 
 I wrote:
 >  Ok, I agree.  I think we should bump UT_HOSTSIZE to 40 then and only 
 >  put unscoped addresses in the field (ie, fec0::1, not fec0::1%vr0).
 >  
 >  Any disagreements ?  Should this be brought up (explained) on -arch 
 >  now ?
 
 Interestingly enough, OpenBSD has UT_HOSTSIZE set to 256.
 
 -- 
 Brian <brian@freebsd-services.com>                <brian@Awfulhak.org>
       http://www.freebsd-services.com/        <brian@[uk.]FreeBSD.org>
 Don't _EVER_ lose your sense of humour !      <brian@[uk.]OpenBSD.org>
 
 

From: "Jeroen Massar" <jeroen@unfix.org>
To: "'Matt Dillon'" <dillon@earth.backplane.com>
Cc: "'Brian Somers'" <brian@Awfulhak.org>,
	"'Hajimu UMEMOTO'" <ume@mahoroba.org>, <aschneid@mail.slc.edu>,
	<ras@e-gerbil.net>, <roam@orbitel.bg>,
	<freebsd-security@FreeBSD.ORG>, <freebsd-gnats-submit@FreeBSD.ORG>
Subject: RE: RE: bin/22595: telnetd tricked into using arbitrary peer ip 
Date: Mon, 23 Jul 2001 15:14:40 +0200

 Matt Dillon <dillon@earth.backplane.com> wrote:
 >     All very nice, guys, but not realistic.  Only FreeBSD uses an API.
 >     Third party programs access the structure directly for the most
 >     part so adding new fields to the structure will just cause more
 >     garbage to be written to the file (many third party programs 
 >     don't bother to bzero the structure before writing it out).  We 
 >     aren't going to add a separate hostname[] array... we just got
 >     through ripping out the hostname crap, because there was never 
 >     enough room in the field to actually store the FQDN, and many
 >     programs don't bother to verify the forward against the
 >     reverse anyway so the data would be suspect.  And short
 >     of making a 200+ character array to hold it, which would be masive
 >     bloat, there is no way to fit it in the structure.  If 
 > you want to store
 >     host names for posterity you will have to log-process the file and
 >     store the results somewhere else.  Every program under 
 > the sun assumes
 >     utmp is a fixed-length structure.
 > 
 >     Pretty much our only option is to extend the size of 
 > existing fields
 >     and take the 'oh hell the structure size changed' hit.
 
 So... Because they didn't account for this 40 years ago we're stuck with
 it??
 
 Another proposal, because I know what you mean with the 'old programs'
 problem which should have been fixed a long time ago with an API :)
 
 Quote from my other mail:
 8<---
 One thing that should be considered to be done if an API is created... :
 make a backport to previous versions of FreeBSD and actually
 *BSD/Linux/* :)
 This also encourages program writers/maintainers to adopt it quicker, as
 it's less hassle for them and they don't have to make the
 "pre-FreeBSD-5" case or something...
 And the best thing of an API (if done right :): seperation of the back
 and the frontend... which makes changes like this even easier...
 ---->8
 
 But now... Make that API log into a different way and place...
 We will get two wtmp/utmp files then... But then we can let the 'old'
 3rd party programs log to the 'old' utmp/wtmp facility.
 Whenever a 'new' program using the API queries the listing function of
 the API then the API will simply also check the 'old' facility... Et
 presto ... We have a solution :)
 
 The new solution could log to a database, file whatever you'd do with
 it.... Just make sure that it fits into an API... :)
 
 That's also one of the reasons I am kinda glad that intel simply made
 IA-64 not IA-32 compliant..... Away with the old stuff and backward
 compatibility you got emu's (or API's who know the old stuff :) for
 that... And Windows is going the same way too... NT != DOS ... Luckily
 :)
 
 Greets,
  Jeroen
 

From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
To: Matt Dillon <dillon@earth.backplane.com>
Cc: <freebsd-security@FreeBSD.ORG>,
	<freebsd-gnats-submit@FreeBSD.ORG>
Subject: Re: RE: bin/22595: telnetd tricked into using arbitrary peer ip 
Date: Mon, 23 Jul 2001 11:38:35 -0400 (EDT)

 <<On Sun, 22 Jul 2001 20:54:55 -0700 (PDT), Matt Dillon <dillon@earth.backplane.com> said:
 
 >     All very nice, guys, but not realistic.  Only FreeBSD uses an API.
 
 Erm, no, wrong.
 
 SVR4 has an API.  This API is standardized as a part of the Austin
 Group process.
 
 -GAWollman
 

From: Matt Dillon <dillon@earth.backplane.com>
To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc: <freebsd-security@FreeBSD.ORG>,
	<freebsd-gnats-submit@FreeBSD.ORG>
Subject: Re: RE: bin/22595: telnetd tricked into using arbitrary peer ip 
Date: Mon, 23 Jul 2001 08:57:26 -0700 (PDT)

 :
 :<<On Sun, 22 Jul 2001 20:54:55 -0700 (PDT), Matt Dillon <dillon@earth.backplane.com> said:
 :
 :>     All very nice, guys, but not realistic.  Only FreeBSD uses an API.
 :
 :Erm, no, wrong.
 :
 :SVR4 has an API.  This API is standardized as a part of the Austin
 :Group process.
 :
 :-GAWollman
 
     Fine.. then if you want to get all the third party program authors to
     use a magic API, be my guest.  Could it be, no... it couldn't...
     all those programs couldn't just not *know* about the 'Austin Group
     process' could they?  That's criminal!  Oops, oh well so much for
     that!
 
     Even ssh, about the closest third party program to BSD as there ever
     was, doesn't use an API call for lastlog.  It does for utmp, sort-of,
     but not for lastlog.  Bzzzt.
 
 					    -Matt

From: Matt Dillon <dillon@earth.backplane.com>
To: Brian Somers <brian@Awfulhak.org>
Cc: Jeroen Massar <jeroen@unfix.org>,
	Brian Somers <brian@freebsd-services.com>,
	Hajimu UMEMOTO <ume@mahoroba.org>, aschneid@mail.slc.edu,
	ras@e-gerbil.net, roam@orbitel.bg, freebsd-security@FreeBSD.ORG,
	freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip 
Date: Mon, 23 Jul 2001 08:58:29 -0700 (PDT)

 :
 :Matt wrote:
 :>  >     Pretty much our only option is to extend the size of existing fields
 :>  >     and take the 'oh hell the structure size changed' hit.
 :
 :I wrote:
 :>  Ok, I agree.  I think we should bump UT_HOSTSIZE to 40 then and only 
 :>  put unscoped addresses in the field (ie, fec0::1, not fec0::1%vr0).
 :>  
 :>  Any disagreements ?  Should this be brought up (explained) on -arch 
 :>  now ?
 :
 :Interestingly enough, OpenBSD has UT_HOSTSIZE set to 256.
 :
 :-- 
 :Brian <brian@freebsd-services.com>                <brian@Awfulhak.org>
 
     Heh.  Are they still trying to store the FQDN?
 
 					-Matt

From: Matt Dillon <dillon@earth.backplane.com>
To: Brian Somers <brian@Awfulhak.org>
Cc: "Jeroen Massar" <jeroen@unfix.org>,
	"'Brian Somers'" <brian@Awfulhak.org>,
	"'Hajimu UMEMOTO'" <ume@mahoroba.org>, aschneid@mail.slc.edu,
	ras@e-gerbil.net, roam@orbitel.bg, freebsd-security@FreeBSD.ORG,
	freebsd-gnats-submit@FreeBSD.ORG, brian@Awfulhak.org
Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip 
Date: Mon, 23 Jul 2001 08:59:49 -0700 (PDT)

 :
 :Ok, I agree.  I think we should bump UT_HOSTSIZE to 40 then and only 
 :put unscoped addresses in the field (ie, fec0::1, not fec0::1%vr0).
 :
 :Any disagreements ?  Should this be brought up (explained) on -arch 
 :now ?
 
     Make it 56, and you've got to put the whole IP address in the field,
     not the short form.  Logs are often processed off-host and the short
     form wouldn't be useful.  And we have to worry about X at some point.
     40 isn't quite big enough.  
 
 					-Matt
 
 :
 :-- 
 :Brian <brian@freebsd-services.com>                <brian@Awfulhak.org>
 :      http://www.freebsd-services.com/        <brian@[uk.]FreeBSD.org>
 :Don't _EVER_ lose your sense of humour !      <brian@[uk.]OpenBSD.org>
 :
 :
 

From: "John Howie" <JHowie@msn.com>
To: "Matt Dillon" <dillon@earth.backplane.com>,
	"Garrett Wollman" <wollman@khavrinen.lcs.mit.edu>
Cc: <freebsd-security@FreeBSD.ORG>,
	<freebsd-gnats-submit@FreeBSD.ORG>
Subject: Re: RE: bin/22595: telnetd tricked into using arbitrary peer ip 
Date: Mon, 23 Jul 2001 09:19:14 -0700

 This is getting off-topic for security but how about taking utmp and
 implementing it as a device? I haven't sat down and thought it all through
 but you could reasonably easily check the format of the data written to it
 (or at least check the size) to determine how to handle it, and likewise for
 the reads. That way you don't have to break your back trying to port all
 those third party apps. A daemon could pick up the processed data and write
 it to a log.
 
 Even better, have the information validated in the kernel before being
 logged. From a security perspective I have never liked the fact that crucial
 log files can just be written to by any old app that happens to run in root
 context.
 
 john...
 
 
 ----- Original Message -----
 From: "Matt Dillon" <dillon@earth.backplane.com>
 To: "Garrett Wollman" <wollman@khavrinen.lcs.mit.edu>
 Cc: <freebsd-security@FreeBSD.ORG>; <freebsd-gnats-submit@FreeBSD.ORG>
 Sent: Monday, July 23, 2001 8:57 AM
 Subject: Re: RE: bin/22595: telnetd tricked into using arbitrary peer ip
 
 
 >
 > :
 > :<<On Sun, 22 Jul 2001 20:54:55 -0700 (PDT), Matt Dillon
 <dillon@earth.backplane.com> said:
 > :
 > :>     All very nice, guys, but not realistic.  Only FreeBSD uses an API.
 > :
 > :Erm, no, wrong.
 > :
 > :SVR4 has an API.  This API is standardized as a part of the Austin
 > :Group process.
 > :
 > :-GAWollman
 >
 >     Fine.. then if you want to get all the third party program authors to
 >     use a magic API, be my guest.  Could it be, no... it couldn't...
 >     all those programs couldn't just not *know* about the 'Austin Group
 >     process' could they?  That's criminal!  Oops, oh well so much for
 >     that!
 >
 >     Even ssh, about the closest third party program to BSD as there ever
 >     was, doesn't use an API call for lastlog.  It does for utmp, sort-of,
 >     but not for lastlog.  Bzzzt.
 >
 >     -Matt
 >
 > To Unsubscribe: send mail to majordomo@FreeBSD.org
 > with "unsubscribe freebsd-security" in the body of the message
 >
 
 

From: Hajimu UMEMOTO <ume@mahoroba.org>
To: dillon@earth.backplane.com
Cc: brian@Awfulhak.org, jeroen@unfix.org, brian@freebsd-services.com,
	aschneid@mail.slc.edu, ras@e-gerbil.net, roam@orbitel.bg,
	freebsd-security@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip 
Date: Tue, 24 Jul 2001 01:31:41 +0900 (JST)

 >>>>> On Mon, 23 Jul 2001 08:58:29 -0700 (PDT)
 >>>>> Matt Dillon <dillon@earth.backplane.com> said:
 
 dillon> :Interestingly enough, OpenBSD has UT_HOSTSIZE set to 256.
 
 I think they prepare new protocol in the future.
 
 --
 Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
 ume@mahoroba.org  ume@bisd.hitachi.co.jp  ume@{,jp.}FreeBSD.org
 http://www.imasy.org/~ume/

From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
To: Matt Dillon <dillon@earth.backplane.com>
Cc: <freebsd-security@FreeBSD.ORG>,
	<freebsd-gnats-submit@FreeBSD.ORG>
Subject: Re: RE: bin/22595: telnetd tricked into using arbitrary peer ip 
Date: Mon, 23 Jul 2001 12:49:52 -0400 (EDT)

 <<On Mon, 23 Jul 2001 08:57:26 -0700 (PDT), Matt Dillon <dillon@earth.backplane.com> said:
 
 >     Fine.. then if you want to get all the third party program authors to
 >     use a magic API, be my guest.
 
 If they run on Solaris -- which most of them do -- then they already
 do.  Nice try, Matt, but far off the mark.
 
 -GAWollman
 

From: Matt Dillon <dillon@earth.backplane.com>
To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc: <freebsd-security@FreeBSD.ORG>,
	<freebsd-gnats-submit@FreeBSD.ORG>
Subject: Re: RE: bin/22595: telnetd tricked into using arbitrary peer ip 
Date: Mon, 23 Jul 2001 10:07:58 -0700 (PDT)

 :
 :<<On Mon, 23 Jul 2001 08:57:26 -0700 (PDT), Matt Dillon <dillon@earth.backplane.com> said:
 :
 :>     Fine.. then if you want to get all the third party program authors to
 :>     use a magic API, be my guest.
 :
 :If they run on Solaris -- which most of them do -- then they already
 :do.  Nice try, Matt, but far off the mark.
 :
 :-GAWollman
 
     Really..  Lets see. wu-ftpd... nope.  proftpd... nope.  Want me to
     continue?
 
 					-Matt

From: Garance A Drosihn <drosih@rpi.edu>
To: Matt Dillon <dillon@earth.backplane.com>,
	Brian Somers <brian@Awfulhak.org>
Cc: "Jeroen Massar" <jeroen@unfix.org>,
	"'Brian Somers'" <brian@Awfulhak.org>,
	"'Hajimu UMEMOTO'" <ume@mahoroba.org>, aschneid@mail.slc.edu,
	ras@e-gerbil.net, roam@orbitel.bg, freebsd-security@FreeBSD.ORG,
	freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/22595: telnetd tricked into using arbitrary peer ip
Date: Tue, 24 Jul 2001 15:23:38 -0400

 At 8:59 AM -0700 7/23/01, Matt Dillon wrote:
 >:
 >: Ok, I agree.  I think we should bump UT_HOSTSIZE to 40 then and only
 >: put unscoped addresses in the field (ie, fec0::1, not fec0::1%vr0).
 >:
 >: Any disagreements ?  Should this be brought up (explained) on -arch
 >: now ?
 >
 >     Make it 56, and you've got to put the whole IP address in the
 >     field, not the short form.  Logs are often processed off-host
 >     and the short form wouldn't be useful.  And we have to worry
 >     about X at some point.  40 isn't quite big enough.
 
 If we are going to go thru the pain of changing it at all, then we
 should change it to be big enough to be worthwhile.  56 sounds like a
 good number to me, or perhaps even a little big larger.  Just a LITTLE
 bit larger though -- the 256 of openbsd sounds like overkill, IMO.
 
 I do think it's time to bring this up on -arch.  I will do that.
 
 -- 
 Garance Alistair Drosehn            =   gad@eclipse.acs.rpi.edu
 Senior Systems Programmer           or  gad@freebsd.org
 Rensselaer Polytechnic Institute    or  drosih@rpi.edu
State-Changed-From-To: feedback->closed 
State-Changed-By: bms 
State-Changed-When: Tue Jun 22 20:42:53 GMT 2004 
State-Changed-Why:  
This wasn't a problem in telnetd, but it did expose a wider 
architectural issue. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=22595 
>Unformatted:
