lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <0b5f01c4d25b$227eaac0$3e0aa70a@doug> Date: Wed, 24 Nov 2004 14:23:52 -0500 From: "Doug Moen" <doug.moen@...ecoat.com> To: <Martin.Buchholz@....COM>, <Casper.Dik@....COM> Cc: srevilak@...akeasy.net, James Youngman <bugtraq@...ession.spiral-arm.org>, parimiv@...haw.com, levon@...ementarian.org, bugtraq@...urityfocus.com, bug-findutils@....org Subject: Re: Changes to the filesystem while find is running - comments? > Like other arbitrary system limits of its ilk, PATH_MAX > is evil, and is one of the more persuasive arguments for > getting rid of the C language and its fixed-size > stack-allocated buffers. > > char path[PATH_MAX]; /* considered harmful */ > > Martin The PATH_MAX limit may not be motivated by the limitations of the C language. I remember during my student days that we had BSD Unix running on a VAX. Early versions of BSD did *not* have a PATH_MAX limit. One day, someone discovered that you could launch a Denial Of Service attack against the kernel using (I think) chdir("./././././. ..."), where the length of the argument string was many megabytes. This was a big deal, because the VAX was a time sharing system with many simultaneous users, and this attack could effectively halt the machine for several minutes. Not long after that, our kernel was upgraded to enforce a PATH_MAX limit. Modern kernels seem to have arbitrary fixed limits for just about everything. My understanding is that this is sound engineering practice. It protects the system against rogue processes, and contributes to security and stability. Doug Moen
Powered by blists - more mailing lists