netdev - Re: [PATCH net] inet: stop leaking jiffies on the wire

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 11 Nov 2019 09:52:46 +0100
From:   Thiemo Nagel <tnagel@...gle.com>
To:     Eric Dumazet <edumazet@...gle.com>
Cc:     David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [PATCH net] inet: stop leaking jiffies on the wire

Hey Eric,

I've been thinking about this some more. The prandom_u32() description
says: "This algorithm is NOT considered safe for cryptographic use."
-- Afaiu this implies that an attacker could deduce internal state by
looking at a sequence of random numbers. Consequently, I believe that
we shouldn't use prandom_* for data that gets sent over the wire.
Instead get_random_* should be used which is described as
cryptographically secure.

Kind regards,
Thiemo

>From /drivers/char/random.c:

[About get_random_*:]
 * Besides the obvious cryptographic uses, these numbers are also good
 * for seeding TCP sequence numbers, and other places where it is
 * desirable to have numbers which are not only random, but hard to
 * predict by an attacker.
[...]
 * It *is* safe to expose get_random_int() output to attackers (e.g. as
 * network cookies); given outputs 1..n, it's not feasible to predict
 * outputs 0 or n+1.
[...]

 * prandom_u32()
 * -------------
 *
 * For even weaker applications, see the pseudorandom generator
 * prandom_u32(), prandom_max(), and prandom_bytes().  If the random
 * numbers aren't security-critical at all, these are *far* cheaper.
 * Useful for self-tests, random error simulation, randomized backoffs,
 * and any other application where you trust that nobody is trying to
 * maliciously mess with you by guessing the "random" numbers.

On Mon, Nov 4, 2019 at 4:50 PM Eric Dumazet <edumazet@...gle.com> wrote:
>
> On Mon, Nov 4, 2019 at 7:24 AM Thiemo Nagel <tnagel@...gle.com> wrote:
> >
> > Thanks a lot, Eric!
> >
> > Grepping through the source, it seems to me there are two more
> > occurrences of jiffies in inet_id:
> >
> > https://github.com/torvalds/linux/blob/v5.3/net/dccp/ipv4.c#L120
> > https://github.com/torvalds/linux/blob/v5.3/net/dccp/ipv4.c#L419
> >
>
> Indeed.
>
> The one in dccp_v4_connect() has been handled in my patch.
> I missed it in dccp_v4_request_recv_sock()
>
> Thanks.
>
> > Kind regards,
> > Thiemo

-- 

Thiemo Nagel

Software Engineer

Google Germany GmbH, Erika-Mann-Straße 33, 80686 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg