Re: /dev/full a security hole?

Darin Johnson (darin@connectnet.com)
Tue, 9 Sep 1997 11:34:06 -0700 (PDT)

> Consider the code:
>
> /* Use memory for whatever reason */
>
> setuid(getuid()); /* Drop permissions */
>
> buffer = malloc(BUFSIZ);
> fd = open(userfile, O_RDONLY);
> n = read(fd, buffer, BUFSIZ);
> write(1, buffer, n);
> close(fd);
>
> This kind of code is very common (although it is simplified here.)
> Doesn't have to be a FILE buffer, and it gives you a cozy peephole
> into the privileged portion of the program.

Huh, I'm still baffled here. Just by changing uid, you don't suddenly
lose the privilege of reading your own memory. You don't need to
exploit a bug to read your own memory. Or am I misunderstanding
the bug? It was said:

> > > I checked out the behaviour of a read of /dev/full, and found it
> > > rather intriguing. It will return a successful read without modify
> > > the user-space buffer at all.

But isn't the "user-space buffer" just the "buffer" up above? Ie, not
some other process's memory, but your own memory.

The "setuid(getuid())" baffles me as well. If you had the extra
privilege, you could have just exploited that fact without changing
resetting the uid... And there is no such thing, really, as a
"privileged portion of the program", either the whole program is
setuid, or none of it is.