[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130405134843.GO30576@port70.net>
Date: Fri, 5 Apr 2013 15:48:44 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Pending issues for next release
* Rich Felker <dalias@...ifal.cx> [2013-04-04 20:41:00 -0400]:
> On Thu, Apr 04, 2013 at 07:37:42PM -0400, Rich Felker wrote:
> > On Tue, Apr 02, 2013 at 01:11:16PM +0200, Szabolcs Nagy wrote:
> > > and fix [u]intmax_t and wchar_t limits in stdint.h etc. (U,L,LL suffix)
> >
> > For [u]intmax_t, assuming all archs use the lowest-rank type that can
> > hold the value, wouldn't it suffice to just omit the suffix entirely?
> > Then the compiler would give it the right type. Or will this break in
> > c89 mode or something obscure like that?
>
> Should be fixed, but I'd appreciate a second review of it.
looks ok
and you are right the suffix can be omitted on the limits
(even U if the constants are hexadecimal)
> That email also mentions some extra macros for utmp/wtmp pathname. I
> looked at the issue, and utmp.h is actually defining _PATH_UTMP and
> _PATH_WTMP in ways that conflict with paths.h... We should address
> this. Any ideas how? I'd like to keep the /dev/null definitions, but
> I'm a little bit scared some broken program might see them and end up
> unlinking /dev/null and replacing it with an empty utmp file at
> startup.
we could say that the user should not run buggy code as root
or define the paths to the usual strings so those programs
will fail at runtime instead of compile time
> > > mkostemp (better rand and stack address hiding)
> >
> > Any specific recommendations? As temp filename generation is not
> > really security-critical (at worst you can slow down or cause
> > tempfile-creation errors in a target program), I think we should
> > probably avoid using the stack address at all. Leaking the stack
> > address to an attacker is too great a risk.
>
> A single call to clock_gettime lacks sufficient entropy to fill the
> 30-bit space we have. Should we just accept that? I don't see a lot of
> value to adding any PRNG since the attack vector would simply be
> predicting the time clock_gettime will return (within a range) then
> creating filenames to clash with every possible output for that range
> of inputs. The PRNG does not increase the size of the filename space
> that must be filled. One option would be calling clock_gettime twice,
> but the second call will have significantly less entropy than the
> first since the interval of time between them is somewhat predictable.
the reason for the PRNG was to hide the address better
and the address was there to increase the filename space
(another reason for using good hashing is to mix all the
input bits equally so we dont need to know which one of
them can the attacker guess)
but yes, the entropy can only be increased by leaking
information about the address:
H(filename) = H(filename|addr) + H(addr) - H(addr|filename)
where H(filename|addr) = H(time) in the optimal case,
so to increase the entropy of the filename the entropy
of the address with known filename should be decreased
if a process creates many temp files then the leaked
information about the stack address can be accumulated
(precise timing info can be obtained by inotify)
so if the stack address is supposed to be secret then
indeed it is better not to mix it into the filename
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.
