Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 30 Jan 2013 02:21:08 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] Add support for mkostemp, mkstemps and mkostemps

On Tue, Jan 29, 2013 at 06:16:11PM -0500, Anthony G. Basile wrote:
> Hi Szabolcs,
> 
> Thanks for the feedback.  All these improvements are easy to
> implement, but the random name generator definitely needs a better
> algorithm.  I just adopted what was already there, but its not good
> enough.
> 
> Here's a simple test program which demonstrates the problem:
> 
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <string.h>
> 
> int main()
> {
> 	int i, fd;
> 	char *t = (char *)malloc(7);
> 
> 	for(i = 0; i < 10; i++)
> 	{
> 		strcpy(t, "XXXXXX");
> 		fd = mkstemp(t);
> 		printf("%s\n", t);
> 		close(fd);
> 		unlink(t);
> 	}
> 
> 	return 0;
> }
> 
> 
> On a glibc system, we get something like:
> 
> 4FeUYd
> gZd1x7
> wkq860
> y2QfGU
> e9rnfO
> crdvOH
> 0P9CnB
> m0cLWu
> eVuTvo
> cxT14h
> 
> On uclibc we get
> 
> WJMzFT
> nvSCqr
> fneEMi
> DTWxB1
> SH4n1C
> TwLMQ9
> LVyEHe
> EihiL4
> uaqxr4
> xmqe7O
> 
> 
> On musl we get
> 
> GIJNPM
> GJDGKC
> GJJBDH
> GJOFHL
> GKFHON
> GKLIPB
> GLCDJK
> GLHONA
> GMABAH
> GMGPLG

Is your concern denial of service by creating all possible temp names
for a given prefix?

With 6 characters and 4 bits per character, there are 2^24
possibilities. That's definitely high enough to avoid problems from
unintended collisions, but I think it's in the realm of "possible" for
an attacker to create them all (it would fill up quite an enormous
amount of directory table space, however, probably over a gig, and
stress the filesystem pretty bad).

One trivial way to get an extra bit per letter would be to add the
lower 4 bits to 'A' and then or the 5th bit onto the result (which
would lowercase it). This would up the number of possibilities to
2^30, which is getting pretty high.

Of course it would be nicer to get up to 6 bits per character
(base64), or even more like 6.5, using modulo rather than &. However,
using non-alphanumeric characters has some tradeoffs; one has to ask
whether the added security against temp name exhaustion DoS is worth
the risk of broken programs passing filenames generated by mkstemp on
system(), popen(), etc. unquoted, which would be dangerous if they
happened to contain characters special to the shell.

> Let me play around with some different algorithms and resubmit this.
> I'll look at what uclibc and glibc do and try to slim them down and
> speed them up.

I don't think performance is an issue unless you're talking about
extra syscalls. The bulk of the time spent in this function is
syscalls, so even making the userspace part of the code 100x faster is
not going to be noticable. I would aim just for small size and
simplicity.

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.