Max Okumoto <[EMAIL PROTECTED]> wrote:

[CC changed to freebsd-security instead of the cvs list]

We're talking about replacing the home-grown mkfifo() funktion in make (a
modified copy of mkstemp()) with mkdtemp() and creating the fifo in this new
directory.

Max worries about a possible race with this new approach.

Its not a race between two nice programs :-)  The function mkdtmp()
creates a uniq directory, but make would then need to create a fifo
in it. (This is two steps, and thus can allow a race)

Assume badmake has same uid, so it can create a file in the uniq
directory.  (Of course this means that the bad guy already has
your account.)

Normal pattern:
---------------------
make0: uses mkdtmp() to create dir /tmp/4321
make0: tries to create fifo /tmp/4321
make1: uses mkdtmp() to create dir /tmp/4321 but fails
make1: mkdtmp() next tries to create /tmp/4322 successs
make1: tries to create fifo /tmp/4322


Sort of DOS: --------------------- make: uses mkdtmp() to create /tmp/1234/

badmake: watches for creation of /tmp/1234/ and
         creates /tmp/1234/fifo.

make: tries to create /tmp/1234/fifo fails.

Right. But if your account is owned you have to worry about other things than a DOS of make (e.g. your ssh keys or access to your banking account or whatever). And there are more possibilities for a DOS in the case of an owned account (fork-bomb, allocating all memory, generating as much files as possible, ...; some of them can be limited with resource limits, but not all), so hardening make would be a nice goal, but in my opinion not a goal we need to persuade today since it wouldn't buy us much. But feel free to come up with some good arguments which I haven' thought of.

Bye,
Alexander.

--
http://www.Leidinger.net/     Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org/        netchild @ FreeBSD.org  : PGP ID = 72077137
Great acts are made up of small deeds.
                -- Lao Tsu


_______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to