> -----Original Message----- > From: Angelos Karageorgiou [SMTP:angelosat_private] > Sent: Friday, July 20, 2001 3:37 > To: Cole, Timothy D. > Cc: bugtraqat_private > 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.
This archive was generated by hypermail 2b30 : Mon Jul 23 2001 - 10:25:07 PDT