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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ