Date: Mon, 27 Nov 2000 15:07:44 -0800 (PST) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: kris@FreeBSD.org (Kris Kennaway) Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/cron/cron cron.h Message-ID: <200011272307.PAA37775@gndrsh.dnsmgr.net> In-Reply-To: <20001127140934.A66576@citusc17.usc.edu> from Kris Kennaway at "Nov 27, 2000 02:09:34 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mon, Nov 27, 2000 at 01:06:13PM -0800, Rodney W. Grimes wrote: > > > On Mon, Nov 27, 2000 at 12:18:10PM -0800, Rodney W. Grimes wrote: > > > > > kris 2000/11/26 14:21:40 PST > > > > > > > > > > Modified files: > > > > > usr.sbin/cron/cron cron.h > > > > > Log: > > > > > Correct definition of MAXHOSTNAMELEN in ifdef'ed out code > > > > > > > > I actaully was ignoring these until it hit me, your actually probably > > > > breaking the purpose of these. Old systems that didn't have MAXHOSTNAMELEN > > > > defined in system headers had a 64 byte length for this. I suspect if one > > > > takes this code after your ``Correction'' and compiles it on one of these > > > > systems a buffer overflow condition could easily be triggered. > > > > > > I'm making the buffers larger, not smaller. > > > > Which is fine for old code returing values to new code, but new code > > passing values to old code is passing values longer than the old codes > > buffer. And that old code is probably riddled with strcpy's and such. > > There are no 64-byte buffers! Yes there are, any time I take this code and compile it on my old crufty boxen with headers that never did define MAXHOSTNAMELEN and that I don't have the source to either the libraries or the resolver and have no real way to fix that part of the system. Ie, many BSD4.2 based boxen like SunOS 3.5, or Apollo Aegis 9.x and probably even Domain/OS 10.x. > > > If ths code were to be compiled on a system which has the definition > > > of MAXHOSTNAMELEN in a nonstandard place (so it isn't #included by the > > > code) but it has a DNS resolver which is RFC-compliant and capable of > > > returning hostnames up to 255 octets long, then there would be a > > > buffer overflow when it tries to store the result in a 64-byte buffer. > > > > And conversely if it has an old non-compliant resolver passing it a > > 255 byte hostname is going to overflow the 64-byte buffer. > > Passing from where? Where does it obtain the long hostname from, if > not the resolver? Command line arguments. Ie: telnet thisisareallylongandhardtoreadhostnamethatwillprobablycauseabufferoverflowinsomeonesoldcrufty64bytehostnamebuffer > I don't think you've thought this through properly. I think perhaps you have not thought this through properly. The ifndef will _never_ trigger on a modern BSD based system, so when does it trigger, well on old systems that have old resolvers and libc code that can probably only handle a 64 byte hostname. You have sanitized the code for the modern *BSD only systems, ignoring the whole case of when this ifndef will be triggered! Infact the code was more correct before your commit than after, systems that did not define MAXHOSTNAMELEN in there system header files often have a 64 byte hostname length limit, and thus the whole reason that ifndef was ever put in there. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011272307.PAA37775>