[gdm-list] Security?

[Jiri Lebl <jirka 5z com>]

Just for kicks, I was semi-bored for a moment, and since gdm is getting a
rewrite, I looked at the cookie generation in svn, module gdm and found the
following gem:

static char *
_generate_random_bytes (gsize size)
{
        char *bytes;
        int i;

        bytes = g_malloc (size);

        for (i = 0; i < size; i++) {
                guint8 byte;

                byte = (guint8) g_random_int_range (0, G_MAXUINT8);

                bytes[i] = (char) byte;
        }

        return bytes;
}

That can't possibly be serious.  Well we should be glad it doesn't use rand()
like xdm did.

Comeon!  Really?  A secure cookie is generated by an unverified pseudorandom
number generator using the persistent processwide random object which is
inited only once?

Doesn't it also say somewhere in GRand documentation that it should not be
used for security applications?  If not, it should.  Don't they say somehwere
in CS 101 that pseudorandom number generators do not generate random numbers?
 You CANNOT GET MORE ENTROPY THAN THE NUMBER OF BITS YOU START WITH, you can
only get less!  GRand NEVER uses more than 128 bits of data to init (with at
most 128 bits of entropy for those lucky to possess a /dev/urandom, and even
then the entropy could be less, but let's not argue that).  It is NONSENSE to
use GRand therefore to possible screw up any possible entropy you might have.
Furthermore it is nonsense to expect the second key generated to have any
entropy left.


1) GRand does not go to great lengths to get a seed with enough entropy.
2) The algorithm in GRand was not as far as I know verified to be secure.  So
the entropy we get might be far less than 128bits after it is finished
3) Not all systems have /dev/urandom, (not to mention the potential problems
of /dev/urandom)

Maybe the original version of gdm cookie generation was overkill on desktop
linux machine (note that gdm should run on more than linux, and gdm should be
secure even when not on linux).  But this is UNDERKILL.

If you really really want to have at least some minimal amount of security,
copy the seed code out of GRand and use that.  In case you use the pid, time
and whatnot when /dev/urandom is not available, you might want to xor over
that with something like the output of GRand, then it's OK.  And actually you
might then get a tiny bit more entropy out of that since grand is inited
separately with a slightly different time value.  Now I don't think that this
is really secure, but it is better than the joke that's currently in svn.

If you want to run some data through a hash to create random looking data.
Use MD5 or something better.  Do NOT use GRand!

George

PS: Good thing GRand seed is at least 128 bits, otherwise I would die
laughing.  But the fact that you guys use the processwide instance really
cracked me up.

-- 
George <jirka 5z com>
   Personally, I'm always ready to learn, although I do not
   always like being taught.
                       -- Sir Winston Churchill