linux-kernel - Re: If not readdir() then what?

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:	Sun, 08 Apr 2007 12:13:35 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Theodore Tso <tytso@....edu>, "H. Peter Anvin" <hpa@...or.com>,
	Christoph Hellwig <hch@...radead.org>,
	Ulrich Drepper <drepper@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: If not readdir() then what?

Theodore Tso wrote:
> 
> You could, but then you're succeptible to a memory allocation attack.
> If you have an arbitrarily large directory (say, one with multiple
> millions of entries), and the attacker program calls seekdir() after
> every single readdir() call, you would then force the kernel to
> allocate and then pin arbitrarily large amounts of memory, which as
> you point out, as currently specified by the POSIX specification, you
> are not allowed to release until closedir().
> 
> This could be done in userspace, by forcing glibc to readdir() the
> entire directory into memory, at which point seekdir()/telldir() will
> work just fine.  But for a really big directory, this could consume a
> huge amount of space. 
> 
> If we had the 64-byte telldir cookie that I had proposed, then in
> userspace we could simply associate that 64-byte telldir cookie with a
> small 32-bit integer, either in memory, or in some berkdb or tdb
> interface, at least until the use of telldir/seekdir had actually
> disappeared.  (Which probably wouldn't take that long; I really doubt
> there are that many users of it out there, so it's probably OK if they
> suffer a performance penality if they use this really wretched and
> horrible interface.)
> 

If you want to have a large cookies, you could have glibc allocate a 
memory block to store it, and have glibc responsible for keeping track 
of it.  As far as I know, off_t can hold a pointer on all our 
implementations (only 32-bit machines have 32-bit off_t as an option; 
Alpha *might* be an exception but I don't think so.)

> I'll also note, by the way, that there are those who have been much
> more cavalier with breaking the wireless interface or the udev/sys
> interface after one year.  Not that I would agree with that, but over
> some deprecation period measured in years, I think it is possible to
> nuke what was a horribly misguided interface that should have never
> existed.  Whoever invented it really should receive the brown paper
> award for one of the worst design decisions of all time.

Readdir/telldir are much, much, more fundamental than that.  We're 
talking interfaces which have been standardized for longer than Linux 
itself has existed.

	-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/