[9fans] exportfs security question

[9fans] exportfs security question

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]

Hullo 9fans.

Can somebody please explain to my slow mind the purpose of this game in
/sys/src/cmd/exportfs/exportfs.c (and the corresponding half in
cmd/import.c) and where my thoughts on it derail ?

    /* exchange random numbers */
    srand(truerand());
    for(i = 0; i < 4; i++)
      key[i+12] = rand();

    if (initial) 
      fatal("Protocol botch: old import\n");
    if(readn(netfd, key, 4) != 4)
      fatal("can't read key part; %r\n");

    if(write(netfd, key+12, 4) != 4)
      fatal("can't write key part; %r\n");

truerand() returns (at most) 32 bits of entropy, which gets pushed into
srand() and then 32 bits of entropy are read back out... why not just use
truerand() directly?

But wait...

We haven't brought up SSL yet, so Eve can read our exchanged random
numbers... now these values get shoved into SHA-1 (along with the 56 bits of
entropy from Kn derived from p9any authentication) before being used to make
the SSL secrets... but... that doesn't seem to matter much.  Eve sees the
first four, the last four, and knows 1/8th of the middle 8 bytes (p9sk1 gets
an 8-byte secret by unpacking a 7-byte DES key) of the input to the SHA-1
function, meaning...  Eve still only needs to do at most 2^56 SHA-1
operations to search for our SSL secrets [1]...  OK, so Eve can't have
precomputed tables to help her out, fair enough, but this still seems
dubious.

Subsequently, having done all of this, the secrets fed into the SSL stream
contain only 80 bits of entropy, which is itself somewhat small (esp.
relative to the ability of rc4 to use 128 or even 256 bit keys).

Am I missing something obvious?

--nwf;

[1] In fact, since Eve knows the first four bytes of the input, she can run
a reduced version of SHA-1 having precomputed the state of the machine after
the first four rounds (leaving only 76 more to go).

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

Re: [9fans] exportfs security question

[Steve Simon]

> truerand() returns (at most) 32 bits of entropy, which gets pushed into
> srand() and then 32 bits of entropy are read back out... why not just use
> truerand() directly?

This bit I know, truerand() reads /dev/random (see cons(1)) and
can only generate "a few hundred bits per second".

rand is pretty good (I think) but it is predictable, by seeding it from
truerand() the predictability is avoided.

-Steve.

Re: [9fans] exportfs security question

[erik quanstrom]

> We haven't brought up SSL yet, so Eve can read our exchanged random
> numbers... now these values get shoved into SHA-1 (along with the 56 bits of
> entropy from Kn derived from p9any authentication) before being used to make
> the SSL secrets... but... that doesn't seem to matter much.  Eve sees the
> first four, the last four, and knows 1/8th of the middle 8 bytes (p9sk1 gets
> an 8-byte secret by unpacking a 7-byte DES key) of the input to the SHA-1
> function, meaning...  Eve still only needs to do at most 2^56 SHA-1
> operations to search for our SSL secrets [1]...  OK, so Eve can't have
> precomputed tables to help her out, fair enough, but this still seems
> dubious.
>
> Subsequently, having done all of this, the secrets fed into the SSL stream
> contain only 80 bits of entropy, which is itself somewhat small (esp.
> relative to the ability of rc4 to use 128 or even 256 bit keys).

eve has to do zero computation to get at your plan-text stream.
i think they call it transport security for a reason. :-)

if you don't trust eve, then you can't trust /dev/truerand.  in fact,
why would an untrustable eve run the right exportfs?  but eve
doesn't need to work that hard.

it gets worse.  since ssl is part of a kernel device, eve gets to see your
keys anyway.  but eve doesn't need them.  since ssl is in the kernel,
eve sees the plan text side of the communication.

i think the network is more of a practical worry.

- erik

Re: [9fans] exportfs security question

[Mechiel Lukkien]

On Fri, Apr 10, 2009 at 07:48:54AM -0400, erik quanstrom wrote:
> > We haven't brought up SSL yet, so Eve can read our exchanged random
> > numbers... now these values get shoved into SHA-1 (along with the 56 bits of
> > entropy from Kn derived from p9any authentication) before being used to make
> > the SSL secrets... but... that doesn't seem to matter much.  Eve sees the
> > first four, the last four, and knows 1/8th of the middle 8 bytes (p9sk1 gets
> > an 8-byte secret by unpacking a 7-byte DES key) of the input to the SHA-1
> > function, meaning...  Eve still only needs to do at most 2^56 SHA-1
> > operations to search for our SSL secrets [1]...  OK, so Eve can't have
> > precomputed tables to help her out, fair enough, but this still seems
> > dubious.
> >
> > Subsequently, having done all of this, the secrets fed into the SSL stream
> > contain only 80 bits of entropy, which is itself somewhat small (esp.
> > relative to the ability of rc4 to use 128 or even 256 bit keys).
>
> eve has to do zero computation to get at your plan-text stream.
> i think they call it transport security for a reason. :-)

he probably means eve as in eavesdropper.  alice, bob, eve & friends.

mjl

Re: [9fans] exportfs security question

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]

On Fri, Apr 10, 2009 at 02:08:25PM +0200, Mechiel Lukkien wrote:
> On Fri, Apr 10, 2009 at 07:48:54AM -0400, erik quanstrom wrote:
> > > We haven't brought up SSL yet, so Eve can read our exchanged random
> > > numbers... now these values get shoved into SHA-1 (along with the 56 bits of
> > > entropy from Kn derived from p9any authentication) before being used to make
> > > the SSL secrets... but... that doesn't seem to matter much.  Eve sees the
> > > first four, the last four, and knows 1/8th of the middle 8 bytes (p9sk1 gets
> > > an 8-byte secret by unpacking a 7-byte DES key) of the input to the SHA-1
> > > function, meaning...  Eve still only needs to do at most 2^56 SHA-1
> > > operations to search for our SSL secrets [1]...  OK, so Eve can't have
> > > precomputed tables to help her out, fair enough, but this still seems
> > > dubious.
> > > 
> > > Subsequently, having done all of this, the secrets fed into the SSL stream
> > > contain only 80 bits of entropy, which is itself somewhat small (esp.
> > > relative to the ability of rc4 to use 128 or even 256 bit keys).
> > 
> > eve has to do zero computation to get at your plan-text stream.
> > i think they call it transport security for a reason. :-)
> 
> he probably means eve as in eavesdropper.  alice, bob, eve & friends.

Erm, yes, that... the name collision didn't even occur to me.  Sorry. :)
--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

Re: [9fans] exportfs security question

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

On Fri, Apr 10, 2009 at 11:25:02AM +0100, Steve Simon wrote:
> > truerand() returns (at most) 32 bits of entropy, which gets pushed into
> > srand() and then 32 bits of entropy are read back out... why not just use
> > truerand() directly?
> 
> This bit I know, truerand() reads /dev/random (see cons(1)) and 
> can only generate "a few hundred bits per second".
> 
> rand is pretty good (I think) but it is predictable, by seeding it from
> truerand() the predictability is avoided.

Be that as it may, we put in 32 bits and read out 32 bits and AFAICT the
rest of exportfs doesn't avail itself of rand().

--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

Re: [9fans] exportfs security question

[Russ Cox]

>    /* exchange random numbers */
>    srand(truerand());
>    for(i = 0; i < 4; i++)
>      key[i+12] = rand();

if one really cared, the right thing to do
would be fastrand() calls.

truerand is only for things that absolutely
must be random (not pseudo-random)
or for seeding random number generators,
as in this example.

all the auth protocols are due for a rework,
but honestly i don't think anyone cares
enough to see it through, myself included.

russ

Re: [9fans] exportfs security question

[lucio]

> all the auth protocols are due for a rework,
> but honestly i don't think anyone cares
> enough to see it through, myself included.

Posting some guidelines, not least _known_ good reasons to do it, may
encourage someone to go ahead.  In fact, it would also make for useful
suggestions for GSoC projects.

++L