oberman@rogue.llnl.gov (08/01/90)
In article <9007301547.AA19807@ucbvax.Berkeley.EDU>, DBARTON@IBM.COM writes: > TCP/IP Version 2 for VM will start allocating ports at port number 1024, > to prevent this problem with the Hewlett Packard product. Ports > 1000-1023 are not restricted, and I am surprised that Hewlett Packard > does not have problems interoperating with other TCP/IP products than > VM. I beg to differ. Please check RFC-1060 in the section "UNIX PORTS". By convention, ports in the range 256 to 1024 are used for "Unix Standard" services. This is "by convention", but in IP-land "by convention" is what is really done. So HP has no problem with the vast majority of implementations since the authors knew that all addresses up to 1024 were reserved. Only those designed in strict compliance with the specs are going to have problems. And I doubt if any implementation has ever worked by designing to the spec. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything.
donp@na.excelan.com (don provan) (08/01/90)
In article <1990Jul31.115309.1@rogue.llnl.gov> oberman@rogue.llnl.gov writes: >In article <9007301547.AA19807@ucbvax.Berkeley.EDU>, DBARTON@IBM.COM writes: > >> TCP/IP Version 2 for VM will start allocating ports at port number 1024, >> to prevent this problem with the Hewlett Packard product. > >I beg to differ. Please check RFC-1060 in the section "UNIX PORTS". > > By convention, ports in the range 256 to 1024 are used for "Unix > Standard" services. OK, this discussion has gotten out of hand and i'm afraid some innocent novice it going to believe some of this misinformation. While it is true that ports lower than 1024 are reserved on many systems, that has nothing whatsoever to do with the HP bug that's being discussed here. The port given in the FTP PORT command is a *remote* port. There's no justification at all for HP checking this port for any range of any type for any reason. It should just use the port given. I don't even understand what prompted some misguided soul to add the extra, unnecessary code needed to make this check. I applaud the IBM developers for making this simple change to accommodate the HP implementation, but i want everyone to understand that the HP implementation is, in fact, broken. don provan donp@novell.com
barmar@think.com (Barry Margolin) (08/02/90)
In article <1628@excelan.COM> donp@novell.com (don provan) writes: >I don't even understand what prompted some misguided soul to >add the extra, unnecessary code needed to make this check. I suspect that it is trying to prevent users from spoofing standard services. For instance, mail can normally be forged by opening a connection to port 25. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
jkp@cs.HUT.FI (Jyrki Kuoppala) (08/04/90)
In article <1628@excelan.COM>, donp@novell.com (don provan) writes: >OK, this discussion has gotten out of hand and i'm afraid some >innocent novice it going to believe some of this misinformation. > >While it is true that ports lower than 1024 are reserved on many >systems, that has nothing whatsoever to do with the HP bug that's being >discussed here. The port given in the FTP PORT command is a *remote* >port. There's no justification at all for HP checking this port for >any range of any type for any reason. It should just use the port >given. I don't even understand what prompted some misguided soul to >add the extra, unnecessary code needed to make this check. I'm not familiar with the HP bug, but sounds like it's a kludge to fix the same security problem that an UCB-bug-fixes posting fixes in September 1987. If the kind of checking that HP does is not done, it may be possible to exploit the security weakness to some other machines; I wonder if HP themselves have left the UCB-fix unapplied becaused they 'fixed' it the other way. The exact nature of the security problem is left as an exercise to the reader. By the way, IMHO the UCB fix is also a horrible kludge, as is the concept of the privileged TCP/IP ports altogether, but it was an useful kludge at the time and it still is. >I applaud the IBM developers for making this simple change to >accommodate the HP implementation, but i want everyone to understand >that the HP implementation is, in fact, broken. Yes, although it does close a security hole in some environments. //Jyrki