> -----Original Message-----
> From: Angelos Karageorgiou [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, July 20, 2001 3:37
> To: Cole, Timothy D.
> Cc: [EMAIL PROTECTED]
> Subject: RE: Linux, too, sot of (Windows MS-DOS Device Name DoS
> vulnerabil ities)
>
> On Wed, 18 Jul 2001, Cole, Timothy D. wrote:
>
>
> > > A 'stat' of all of these files shows that they are not regular
> > > files. There's no reason, them, to open them in the browser.
> > >
> > > > If someone wants to be nasty, he/she can
> > > > create a web page with
> > > > URLs inside <IMG SRC="these device files" ....>
> > > > listing DOS devices as well as these popular UNIX devices.
> > >
> > > I question the wisdom of browsers which allow external web pages to
> > > reference local files via 'file://' URLs.
> > >
> > I agree; that's really the underlying problem. Checking for special
> > files is a band-aid fix that also limits flexibility.
> >
>
> I do follow your sentiments, but stat'ing shoul dhave been done since day
> one that the first exploit on unix appeared.
>
Most browsers do stat() for directories. Everything else is treated
as a byte stream, which was a deliberate design decision made in Unix, and
faithfully (we may disagree whether it was TOO faithfully) observed by
browser makers.
> Let me remind you that in Unix even the directories are files, there
> are also named pipes, synlinks, hardlinks loop filesystems, mountpoints
> etc etc.
>
You can't easily distinguish the latter cases (mountpoints, hard
links [which is the 'real' link?], loopback filesystems) by using stat().
Neither are any of these harmful.
> Now that I think about it, EVERY fopen must be prepended with a stat
> in every program, and would make a whole class of problems disappear
>
Not really. If a local user is using file:// URLs maliciously,
you're still subject to stat() races. fstat() after fopen() would be
better. However, merely opening some device files can do damage (e.g.
auto-rewinding tape devices).
I'll concede that doing a *stat() to check for S_IFBLK | S_IFCHR
might be reasonable as damage control, but it doesn't eliminate the entire
class of problems.
stat(), fstat() and lstat() also cannot tell you if opening or
reading a "regular" (S_IFREG) file will have side-effects. Consider a
kernel like HURD, a Linux or *BSD system with userfs, or on some systems,
certain entries in the /proc filesystem.
Restricting what can be opened based on inode type also eliminates a
certain class of useful things (for an admittedly weak example, a Linux
system administrator who has a "hardware configuration" page with an iframe
containing the output of /dev/sndstat. It is also possible to use named
pipes for interesting things locally).
>
> > As a genral principle, regardless of platform, local paths may
> > encompass more than just 'dumb' files, so following 'remote' references
> to
> > them should be restricted.
>
I meant "restricted" in the sense that it would not be allowed in
_all_ cases.
I think it should be allowed, but should require user intervention.
(e.g. "Load local image file:///dev/urandom from remote document
http://www.pure-evil.com/die-die-die.html (yes/no)?")
> then we have the problems of uploading files on the web, online editting
> and all these goodies
>
All of those cases require user intervention even now. If someone
chooses to upload /dev/zero voluntarily, more power to them.
