Re: SSL implementation problem at Netscape

[dawagner@flagstaff.princeton.edu (David A. Wagner)]

It looks like there's some confusion about the Netscape security problem
Ian Goldberg (iang@cs.berkeley.edu) and I found, as mentioned recently
on cypherpunks.  If we'd foreseen that such a silly bug would receive so
much attention, I think we would've tried to prepare a more comprehensive
description...  But we didn't.

Anyhow, let's see what I can clear up for you now.

[Note: Ian isn't here right now, so he hasn't had a chance to look at this.
Any errors are mine, any opinions are mine, etc.]

In article <david-1909951219130001@192.0.2.1> from sci.crypt,
David Sternlight <david@sternlight.com> wrote:
> If the above is, in fact, accurate it appears to apply to previous
> versions of Netscape, not the 2.0 versions for which the public beta goes
> out next week.

We haven't tried it on v2.0, as we only have a copy of v1.1 right now.
But the front-page New York Times article today said that the next version
also has the same flaw, and that it'll be fixed before release.

A Netscape official press release is available at

	http://www.netscape.com/newsref/std/random_seed_security.html

Also our prototype code can be found at

	ftp://ftp.csua.berkeley.edu/pub/cypherpunks/cryptanalysis/unssl.c

>                In addition the flat statement that "keys can now be found
> in appx 1 min." is not, as it seems, a general one but (if one reads the
> details) requires a number of special assumptions, applies only to some
> machines, and applies only if one can develop certain collateral
> information.

You are partially correct.

It all depends on the threat model.  If the attacker has user-level access
(e.g. an account) on the machine where you run Netscape, your encrypted
sessions can be broken quickly.  (Our tools took about 1 minute on 1
machine, but was just a proof of concept -- I believe the time could be
significantly reduced, and automated completely.)  This model is not
entirely unreasonable IMHO.


If the attacker is simply sniffing the wire somewhere between you and
the https: server, and has no account on your machine, things are a bit
more complicated.  Ian & I are still discussing this case, but I'll
mention a few of our observations:

* the time, pid, and ppid are mixed together in such a way that there
	is certainly no more than 47 bits of entropy (which is a far cry
	from the 128 bits claimed for their commercial domestic version).
* the attacker can guess the current time to within a few seconds easily.
* maybe the attacker can get this down to about 10 msec uncertainty,
	possibly even less in some cases.
* the ppid is often 1 (e.g. when you start up Netscape from a X-windows menu).
* if not 1, the ppid is often just a bit smaller than the pid.
* on personal workstations, the pid and ppid are often quite small.
* one can remotely determine pid's by talking to sendmail on the attacked
	machine and bouncing mail -- the pid will usually be in the Message-ID.
	(if the attacker host runs sendmail, which is a usual case)
	because pids are assigned sequentially, this leaves very little
	uncertainty in Netscape's pid.
* there's no notion of pid or ppid on MS-DOS: God only knows what
	Netscape does there.  maybe it's just seeded from the time!!
* the PRNG is never reseeded for the duration of a cached connection.

While we don't yet know exactly how long it would take to break Netscape's
PRNG in this threat model, I think it's clear that Netscape's current
implementation is insufficient and insecure.


You mention that our attack is only applicable to certain machines.  You
may well be correct -- this is one area where our experiments were still
proceeding when the media descended on us today.  <chuckle>  Certainly the
Solaris 2.0 and HP-UX versions of Netscape v1.1 are vulnerable: we tested
them ourselves.  Ian told me he got email from people who are trying unssl.c
on other architectures, and apparently the SunOS 4.x.x version is vulnerable
too (and tests of other machines are in progress).

We don't know about e.g. PC's yet -- this is another area we were still
working on.  I will note that Netscape didn't try to claim that any version
was safe from this flaw, for what that's worth...

Hopefully this will be quickly fixed by Netscape, and then we can all stop
worrying about it! :-)

David Wagner, daw@cs.berkeley.edu, speaking {for,to} himself