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 - Fix: make realhostname*() not suck 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.
> 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 Awaiting a response to my comments
Responsible Changed From-To: freebsd-bugs->brian I was responsible for originally introducing realhostname
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
> 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>
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)
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)
> 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>
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)
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)
>>>>> 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/
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)
>>>>> 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/
: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
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
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
>>>>> 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/
:>>>>> 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
> :>>>>> 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>
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
> 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>
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
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
> 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>
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>
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
<<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
: :<<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
: :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
: :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> : :
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 >
>>>>> 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/
<<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
: :<<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
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 This wasn't a problem in telnetd, but it did expose a wider architectural issue.