Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #14918

Re: $RANDOM not Cryptographically secure pseudorandom number generator

Show all headers | View raw

On Mon, Dec 3, 2018 at 9:18 PM Chet Ramey <chet.ramey@case.edu> wrote:
> On 12/3/18 11:31 AM, Ole Tange wrote:
> > On Mon, Dec 3, 2018 at 3:56 PM Chet Ramey <chet.ramey@case.edu> wrote:
> >
> >> There has to be a compelling reason to change this, especially at a point
> >> so close to a major release.

I would think that a major release would be the perfect opportunity to
change this: Major releases in general are known for not being 100%
compatible with earlier releases.

> > The reason for my submission was that I needed a bunch of random
> > numbers in a shell script, but I needed them to be high quality.
> > Luckily I did not just assume that Bash delivers high quality random
> > numbers, but I read the source code, and then found that the quality
> > was low. I do not think must users would do that.
>
> This is always requirements-driven. Nobody expects to get cryptographic-
> quality PRNGs out of the shell (or any of the libc interfaces, tbh),

While I did not *expect* it, I honestly had hoped for it. Otherwise I
would never have raised this.

I feel a bit as if I am saying: "Hey this using environment variables
to store function definitions seems like it could be a problem, but I
do not have an exploit. I do, however, have an easy fix so that it
will not be a problem in the future."

And you replying: "Come back when you have an exploit."

And then we simply wait for Shellshock to happen.

> that's never been promised or expected. You can't really expect that from
> something that only promises 16 bits.

The naive user may assume that he can simply concatenate values and
get 128 bits:

echo $RANDOM-$RANDOM-$RANDOM-$RANDOM-$RANDOM-$RANDOM-$RANDOM-$RANDOM

But I hope we agree that he will not get 128 bits of randomness no
matter how many values he concatenates.

Or he might expect that this is not an infinite loop:

  while [ ! $RANDOM = $RANDOM ] ; do true; done

just like this is not:

  while [ ! $RANDOM = $(( 1+$RANDOM )) ] ; do true; done

(This one came as a surprise to me - I had totally expected $RANDOM
would give the same value twice 1 time in 65536 tries on average.
Tested on 4.4.19)

At the very least make it clear from the documentation what $RANDOM
can be used for. The man page does not warn about the low quality
either, and it does not point to a way to get high quality numbers.
Somehow we expect the user to simply know this without giving him even
a hint about this.

> However, for common scripting tasks like generating temporary filenames,
> it's perfectly adequate.

I hope that we agree that you should never use $RANDOM for generating
temporary file names in a dir that an attacker has write access to.
mktemp is made to do that in a secure fashion.

But your comment actually emphasizes my point: We _will_ have users
who are naive enough to use $RANDOM in ways you and I would not do,
because we know it is unsafe.

Let's make those usages a little safer.


/Ole

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread

Thread

Re: $RANDOM not Cryptographically secure pseudorandom number generator Ole Tange <tange@gnu.org> - 2018-12-15 23:22 +0100

csiph-web