RE: Linux, too, sot of (Windows MS-DOS Device Name DoS vulnerabil ities)

["Cole, Timothy D." <timothy_d_cole () md northgrum com>]

> -----Original Message-----
> From: Angelos Karageorgiou [SMTP:angelos () invan gr]
> Sent: Friday, July 20, 2001 3:37
> To:   Cole, Timothy D.
> Cc:   bugtraq () securityfocus com
> 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.