Message-ID: <20020911205842.A1711@hamsec.aurora.sfo.interquest.net>
From: silvio at big.net.au (silvio@....net.au)
Subject: Re: owning /dev/[u]random

I am planning to post an advisory soon.. In recent times it has come
to my attention that a certain "book for hackers" contains software which
is deemed unsuitible for mass consumption.

I think it goes something like this -->

#include <stdio.h>
int main(void) { printf("Hello Hackers!\n"); }

there is obviously an issue with main not returning or explicity exiting.
Even pre-ansi this is still buggy, since a return type is present.
I think I perhaps need to mail some errata material.

THREATCON escalation to level "TT WW OO"  is being advised, either
explicity or implicity.  (NB.  if at any time, the threatcon level is not
attainable for any reason.. your on your own).

>         While doing some code auditing I got to thinking about
> known-plaintext attacks against various ciphers when /dev/random or
> /dev/urandom have been comprimised. A quick search on google doesn't turn
> much up. However, I'm curious if anyone knows of a thread somewhere where
> folks have discussed the implications of such a thing, and perhaps
> formulated a strategy to attack any much-used applications like those
> linked against openssl and using one of the ciphers therein.

This is definately an interesting area to research, in terms of identifying
non-theoretical attacks ;-)

OTOH, how much software does _not_ use /dev/[u]random ?  This is basically
past history, that is still probably present today in various software.

Example..

GLIBC (2.2.90 here) mkstemp will use "randomess" from gettimeofday()
(if present), else time(), then combine that with getpid() as a seed for its
algorithm to determine names for random temporary names.

mkstemp is OK though, because its not going to haplessly follow sym
links and so forth even if you can predict the next output from the prng.

But anyway.. how about rand() and random() in general use.. It's typical
to see this in a few places --> srand[om](time(NULL)).

As a local timing issue, how easy is it to predict something like
gettimeofday() ?  It's no problem, in simple test cases.

How easy is it, to predict time() ?  Possibly, there is information on howlong
a service has been up or how long a process has been running (/bin/ps ?),
maybe also you now the number of calls have been made to the prng, through
logs, or maybe even such things as publically viewable counters that keep
track *shrug* (can someone go back through sources of "crypto" secure
software and look for defense against reply attacks through the use
of linear incrememting sequence numbers? - maybe even nicer than ip_id
for determine usuage statistics on specific services)

>         I'm thinking mainly of Solaris systems (before solaris 9) with no
> SUNWSki package where someone might be able to write, say only 4 bytes of
> data to /dev/random using a race condition or other such trickery. There
> are a few cases (like padding ciphertext in a block cipher) where this
> might be enough of a toehold to try a known-plaintext attack. If the
> implications were serious enough, an attacker who owns a machine may
> choose _only_ to alter the /dev/random or /dev/urandom devices for some
> nefarious purpose. Of course it'd probably be much more fruitful to simply
> trojan all the shells. However, it's pretty tough to use AIDE or Tripwire
> on /dev/random or /dev/urandom (So, I'm guessing that they don't check to

Maybe the Palidium or whatever the hell its called can save us here..
Nothing against trusted environments, and this isn't directly related but
was menthioned in associate with Palidium.

I dont see how even enforcement of a static text/code image protects against
all malicious attacks?

Isn't this what return into libc exploits are all about?

In terms of gathering execution profiles for software, and using that
in palidium is not going to happen (thank god).

OTOH, what would be nice to implement, would be execution profile generation
directly from code..  There is already the information in
most things to maintain flow graphs and call graphs during compilation.
By registering a list of libc/system functions as system calls that
is used in postprocessing your graphs.  Your (subset of) flowgraph/callgrab +
system calls is now basically your execution profile as a state machine :-)

Binary analysis to do the same would also be nice ;-)

Please do not talk about issues such as the state machine being dependant
on the data flow in certain types of execution profile.  But the above
method seems OK and gains more than current.

> make sure that these are actually character devices). So, it might be
> pretty a pretty sneaky trick to own the machine, add your known-plaintext
> in place of /dev/random or /dev/urandom, then put the box back like it was
> before anyone checks the MD5 hashes.
> 
> Before anyone flames me, I'd like to use a tactic pioneered by RFP, and
> safe the troll some time:
> 
> 1. I have a small penis
> 2. I don't know shit.
> 3. I'm not a _true_ hacker/blackhat/whatever.
 
All of the above applies to me also, but I'll need to consult a lawyor first,
before making any rash, or non rash (which implies neither rash or non
rash) statements.

> aliver
> --
> Question: Is it better to abide by the rules until
> they're changed or help speed the change by breaking them?

--
Silvio

Powered by blists - more mailing lists