NYT on Netscape Crack

The New York Times, September 19, 1995, pp. A1, D21.


   Security Flaw Is Discovered In Software Used in Shopping

   By John Markoff


   San Francisco, Sept. 18 -- A serious security flaw has been
   discovered in Netscape, the most popular software used for
   computer transactions over the Internet's World Wide Web,
   threatening to cast a chill over the emerging market for
   electronic commerce.

   The flaw, which could enable a knowledgeable criminal to
   use a computer to break Netscape's security coding system
   in less than a minute, means that no one using the software
   can be certain of protecting credit card information, bank
   account numbers or other types of information that Netscape
   is supposed to keep private during on-line transactions.

   The weakness was identified by two first-year graduate
   students in computer science at the University of
   California at Berkeley, who published their findings on an
   Internet mailing list Sunday evening.

   Although the Netscape Communications Corporation, which
   produces the software, said today that the flaw could be
   fixed and that new copies of the software would be
   distributed as early as next week, Internet experts said
   the discovery underscored the danger of assuming that any
   computer security system was safe.

   "There needs to be much more public auditability in the way
   these financial security systems are designed and
   implemented," said Eric Hughes, president of Open Financial
   Networks, a company in Berkeley that is developing Internet
   commerce systems.

   The Netscape software is already used by an estimated eight
   million people for navigating the World Wide Web portion of
   the Internet. On the Web, thousands of companies offer
   text, images, video and audio information, much of it as a
   way of advertising or directly selling goods and services.
   Because the Netscape software is not only easy to use but
   has also been promoted as a secure way of dealing with
   personal and financial information, it has been seen as the
   emerging de facto standard for on-line commerce.

   Already, a diverse group of companies -- including Wells
   Fargo Bank, MCI Communications, Internet Shopping Network
   and Virtual Vineyards -- have adopted Netscape as the
   vehicle for checking bank balances, catalogue shopping or
   buying wine on line.

   Although Internet experts agreed with the company's
   assessment that the flaw could be fixed and that it posed
   no risk to people who use the World Wide Web only to
   retrieve nonsensitive data, the security problem's
   disclosure may represent a public relations setback for
   Netscape Communications and an inconvenience to millions of
   people who may feel a need to replace the version of
   Netscape installed on their computers. Last month the
   company's shares began public trading and had one of the
   most successful first days in Wall Street's history,
   largely on the resounding popularity of the Netscape
   software.

   Today, as word of the security flaw circulated only within
   fairly small circles of Internet users, Netscape's stock
   closed with a slight loss, down 75 cents, to $52.50, in low
   Nasdaq trading volume.

   The company said it would release a repaired version of the
   software within a week. Users will be able to download it
   free over the Internet, through the Netscape site on the
   World Wide Web (http://home.netscape.com).

   The company had previously announced a next-generation
   version of Netscape that it said would be more secure than
   the original, and it said today that it would release this
   updated version within the next few weeks. But first it
   will remove the newly disclosed flaw, which is currently in
   the new version.

   "The good news and the bad news of the Internet is that
   when you put something up there, many more people can test
   it," said Mike Homer, the vice president of marketing at
   Netscape. "You also give yourself the opportunity of having
   people point things out which you can fix quickly."

   The company so far has distributed most copies of its
   program free over the Internet, under a strategy of making
   its money from commercial customers who use Netscape to
   provide services or for other business applications over
   the World Wide Web. So replacing the copies will not be an
   expensive undertaking.

   Instead, for Netscape Communications and for other
   companies betting their futures on the Internet, the real
   cost of this disclosure may be in the public's shaken
   confidence in the ability of computer companies to insure
   privacy and security for on-line commerce.

   The weakness in Netscape's security was discovered by Ian
   Goldberg, 22, and David Wagner, 21, two computer science
   students who share an office at the university and who also
   share an interest in the arcane science of cryptography,
   which is becoming increasingly important for business as
   companies begin to explore electronic commerce.

   The two students said they had decided to put the software
   to a test in an effort to raise public concern about
   placing too much trust in unproved electronic security
   systems.

   Netscape's security is based on a type of coding technology
   known generically as public key cryptography in which users
   exchange mathematically generated numbers -- or keys -- to
   encode or decode information. In such systems, a new key is
   created for each information exchange, based on a
   mathematical formula that is combined with numbers
   supposedly known only to the sender or recipient.

   The students found that by determining how Netscape's
   formula generated the number used as a starting point for
   creating a key, they were able to greatly reduce the
   potential combinations that would unlock the code. The
   starting-point number turned out to be based on the time
   and date of the transaction, combined with several other
   unique bits of information taken from a user's computer
   system -- bits of information that an electronic intruder
   could determine, if he were intent on intercepting a
   Netscape user's transactions.

   Knowing how the starting-point number was created greatly
   reduced the other possible components of the formula -- and
   the students found they were able to break the code in a
   matter of seconds using a standard computer work station.

   Netscape officials said today that they would strengthen
   the system, by making it significantly harder to determine
   the random number at the heart of their coding system. They
   said they would no longer disclose what data would be used
   to generate the random numbers.

   The announcement of the flaw was posted Sunday night on a
   computer network mailing list maintained by an informal
   group known as Cypherpunks. The group, which is made up of
   mathematicians, computer experts and privacy advocates, has
   been campaigning for more effective electronic security
   systems.

   The discovery is the second reported security weakness in
   the Netscape program to be posted on the Cypherpunks list
   in the last month. In August, Damien Doligez, a student at
   the Ecole Polytechnique in Paris, used a network of 120
   computers, running for eight days, to generate a Netscape
   secret key. But his was a "brute force" attack, requiring
   the computers to sample a vast range of numbers before
   coming up with a key that would break the code.

   The Berkeley students, in contrast, by identifying a basic
   flaw in the way Netscape set up its security system, were
   able to narrowly focus their attack to quickly break the
   code, with far less computer power.

   [End]

Markoff's article in the Times says:
>    Netscape officials said today that they would strengthen
>    the system, by making it significantly harder to determine
>    the random number at the heart of their coding system. They
>    said they would no longer disclose what data would be used
>    to generate the random numbers.

Not, of course, that they disclosed it before -- it was found by
reverse engineering the distributed executable. Not, of course, that
they have a choice in the matter of whether to disclose it -- they
will be "disclosing" how its done as soon as they release the
code. Not, of course, that security through obscurity does any good --
it just magnifies the pain.

I suspect that there are far more flaws in Netscape. String buffer
overflows are another good guess here -- they are probably rampant
through the code both for the browser and the commerce server they
sell. I can't prove it myself, of course, given that I don't have the
time to rip the thing apart, but the same folks never seemed to learn
their lesson in release after release when they worked at NCSA, and
the only thing thats probably keeping their dignity here is the lack
of distributed source code.

I'll pay for the "I broke Netscape's Security" T-Shirt for the
enterprising person that takes the time to find them in the object
code. (See Sameer's page on the shirts he's developing as prizes for
the Netscape flaw finders.)

Two "I broke Netscape's Security" T-Shirts to that daring soul at
Netscape who finds the next flaw and has the balls to mention it in
public instead of sweeping it under the carpet -- even if the person
is Marc Andreessen.

Perry

I've been having mail problems of late.

Did you get my letter on your tax issue?


---
"In fact, had Bancroft not existed,       potestas scientiae in usu est
Franklin might have had to invent him."    in nihilum nil posse reverti
00B9289C28DC0E55  E16D5378B81E1C96 - Finger for Current Key Information

Black Unicorn writes:
> I've been having mail problems of late.
> Did you get my letter on your tax issue?

Yes, but I've been preoccupied by the latest internet political
scandal over domain registration. Thank you greatly for the
information; I'll probably ask you a question or two within a few
days when my mail volume goes below 500 a day again.

Perry

Eek. Lovely accident. Never reply to "all" without checking the "to"
list. Sigh.

Perry

> 
> Not, of course, that they disclosed it before -- it was found by
> reverse engineering the distributed executable. Not, of course, that
> they have a choice in the matter of whether to disclose it -- they
> will be "disclosing" how its done as soon as they release the
> code. Not, of course, that security through obscurity does any good --
> it just magnifies the pain.

	Once netscape is patched with a stronger PRNG if someone can
crack -that- one too, then they will get a T-shirt as well. Perhaps I
should offer the t-shirt for just revealing the algorithim used w/o
actually cracking it, just to deal with that statement from "Netscape
officials".
	I emphasized in my conversation with the SFChronicle today
that 'security by obscurity' doesn't work. Hopefully that will be
reflected in the article.

-- 
sameer						Voice:   510-601-9777
Network Administrator				FAX:	 510-601-9734
Community ConneXion: The NEXUS-Berkeley		Dialin:  510-658-6376
http://www.c2.org (or login as "guest")			sameer@c2.org

> 
> I suspect that there are far more flaws in Netscape. String buffer
> overflows are another good guess here -- they are probably rampant
> through the code both for the browser and the commerce server they
> sell. I can't prove it myself, of course, given that I don't have the
> time to rip the thing apart, but the same folks never seemed to learn
> their lesson in release after release when they worked at NCSA, and
> the only thing thats probably keeping their dignity here is the lack
> of distributed source code.

  I doubt this in the case of the browser. Atleast as far as the
parsing is concerned. There may be a buffer overflow for example,
when you input the url in the "open" window, but that has to be
done manually by the user and isn't a threat, like a "rogue homepage"
would be. The reason I doubt string buffer overflows in the case of
the browser is that it seems to be written in some object oriented
language, perhaps C++ (or maybe just oo-C like BSAFE). Once you
have a general robust String class, you can prove it's non-overflowable,
and therefore no composition of operations from the browser code will
overflow it (unless of course, you break language safety by using
casts and pointer manipulation) Secondly, Netscape has been very
robust in my own testing against these common bugs. One of the things
I've done lately is "tiger team" attacks against servers and browsers.
(of course, sendmail is a brilliant counter example)
(if you can find a call to gets() in Netscape, I will instantly 
retreat ;-) )

  Netscape's security maybe bad, but the rest of their browser, or atleast
their development process, is good engineering. They've built a very
complex application, fairly quickly, that runs with very few bugs,
across a wide variety of operating systems and GUI's, while maintaining
a consistent user interface and feature set. Netscape 2.0 incorporated
Java, LiveObjects, and more HTML3.0 in almost record time. (I wasn't
expecting a Java capable Netscape until atleast December). I'd like to
see Microsoft develop a piece of code that quickly that runs on
umteen different flabors of Unix, MacOS, and Win3.1/95/NT. Hell, they
can't even write code that runs smoothly across all three
flavors of their operating system.

-Ray

> 
>   I doubt this in the case of the browser. Atleast as far as the
> parsing is concerned. There may be a buffer overflow for example,

	Buffer overflow seems like a much greater concern when dealing
with a server. Particularly one which is supposedly "secure", and
accessing "secured" documents. Even with the server running as
'nobody' if someone can implement buffer overflow to get access to
documents they shouldn't then that would count as a pretty significant
hack.

	I suspect that the server is where the majority of the bugs
lie. My Hack Netscape page emphasizes the server as a place to look
for holes.


> when you input the url in the "open" window, but that has to be
> done manually by the user and isn't a threat, like a "rogue homepage"
> would be. The reason I doubt string buffer overflows in the case of
> the browser is that it seems to be written in some object oriented
> language, perhaps C++ (or maybe just oo-C like BSAFE). Once you
> have a general robust String class, you can prove it's non-overflowable,
> and therefore no composition of operations from the browser code will
> overflow it (unless of course, you break language safety by using
> casts and pointer manipulation) Secondly, Netscape has been very
> robust in my own testing against these common bugs. One of the things
> I've done lately is "tiger team" attacks against servers and browsers.
> (of course, sendmail is a brilliant counter example)
> (if you can find a call to gets() in Netscape, I will instantly 
> retreat ;-) )
> 
>   Netscape's security maybe bad, but the rest of their browser, or atleast
> their development process, is good engineering. They've built a very
> complex application, fairly quickly, that runs with very few bugs,
> across a wide variety of operating systems and GUI's, while maintaining
> a consistent user interface and feature set. Netscape 2.0 incorporated
> Java, LiveObjects, and more HTML3.0 in almost record time. (I wasn't
> expecting a Java capable Netscape until atleast December). I'd like to
> see Microsoft develop a piece of code that quickly that runs on
> umteen different flabors of Unix, MacOS, and Win3.1/95/NT. Hell, they
> can't even write code that runs smoothly across all three
> flavors of their operating system.
> 
> -Ray
> 
> 
>  
>    
> 
> 


-- 
sameer						Voice:   510-601-9777
Community ConneXion				FAX:	 510-601-9734
An Internet Privacy Provider			Dialin:  510-658-6376
http://www.c2.org (or login as "guest")			sameer@c2.org

> 
> > 
> >   I doubt this in the case of the browser. Atleast as far as the
> > parsing is concerned. There may be a buffer overflow for example,
> 
> 	Buffer overflow seems like a much greater concern when dealing
> with a server. Particularly one which is supposedly "secure", and
> accessing "secured" documents. Even with the server running as
> 'nobody' if someone can implement buffer overflow to get access to
> documents they shouldn't then that would count as a pretty significant
> hack.

   Right. Some other common ones are ".." and shell meta characters
in paths. Also, accessing files that you don't have permissions
to. Even if the server is perfect, the setup could be bad. For
instance, if you use CERN's Authentication scheme for protecting
URL hierarchies, do not put the passwd/group file within the
hierarchy. I've noticed this before on some servers, like

http://www.isp.com/company1/passwd   contains the passwd file for the
http://www.isp.com/company1/   URL directory. Although it is convenient
to store the passwd file within the hierarchy it is protecting, care
must be taken to make it unreadable by normal HTTP requests. It's better 
to put it in a configuration directory somewhere where no server
has access to. (I've seen this mistake plenty of times)

  A barebone's web server is a pretty simple piece of a software compared
to a browser (or sendmail), so it should be possible to make them
much more secure.

-Ray

> http://www.isp.com/company1/passwd   contains the passwd file for the
> http://www.isp.com/company1/   URL directory. Although it is convenient
> to store the passwd file within the hierarchy it is protecting, care
> must be taken to make it unreadable by normal HTTP requests. It's better 
> to put it in a configuration directory somewhere where no server
> has access to. (I've seen this mistake plenty of times)

	The server process itself still needs access to that file
though in order to verify passwords, so it can't be totally
protected-- a bug in the server might reveal the password file. A
relatively minor point..

> 
>   A barebone's web server is a pretty simple piece of a software compared
> to a browser (or sendmail), so it should be possible to make them
> much more secure.

	Right. The Netscape Commerce server, on the other hand, is by
no means a barebones webserver. It has a full-featured API which
allows dynamic loading of custom-written modules to handle every
aspect of web servering. Its configurations files, while not as
complex as sendmail config files, are rather complex. The server comes
with an "GUI administration tool", which allows you to configure the
server using netscape over HTTP to a special server, -running as
root-, which can modify configuration files, restart the server,
etc. (I am not sure if the administration server -must- run as root,
but that is how it has been configured in the installations I have
seen.)
	Even extremely good security programmers could probably not
write such a complex program without bugs, particularly on the
timescale for which you have commended Netscape. (Extremely good
ethical security programmers may not even be -willing- to write such a
complex program and declare it secure)
	There is actually an interesting parallel to sendmail in
webservers..webservers have a very vital 'rewriting' phase, where they
turn the url (/~sameer for example) into a filename
(/u1/sameer/public_html/index.phtml) This phase is where it checks
ownership, checks symlinks, etc. I figure that section may be rife
with holes, given the incredibly powerful rewriting that the highly
flexible servers can do these days.

-- 
sameer						Voice:   510-601-9777
Community ConneXion				FAX:	 510-601-9734
An Internet Privacy Provider			Dialin:  510-658-6376
http://www.c2.org (or login as "guest")			sameer@c2.org

> 	The server process itself still needs access to that file
> though in order to verify passwords, so it can't be totally
> protected-- a bug in the server might reveal the password file. A
> relatively minor point..

Actually, it could communicate with a differently-privileged process.
The security gain probably isn't worth the performance hit, though.

(A possible secure channel: Give the password manager a uid of its own.
Have it listen on a unix-domain socket.  The server process opens the
socket, then fstat()s it to make sure it's really owned by the password
manager.)
-- 
Shields.

| 	Buffer overflow seems like a much greater concern when dealing
| with a server. Particularly one which is supposedly "secure", and
| accessing "secured" documents. Even with the server running as
| 'nobody' if someone can implement buffer overflow to get access to
| documents they shouldn't then that would count as a pretty significant
| hack.

	Don't forget system(), which was a major source of holes in the NCSA server.  
Also, CGI scripts, especially those that run under perl or sh, would be a good 
place to look for holes.  Don't forget to see what happens when you put 
semi-colons in the data field of various fields, such as mailto:'s.

Adam
-- 

"It is seldom that liberty of any kind is lost all at once."
					               -Hume

> 	Don't forget system(), which was a major source of holes in the NCSA server.  
> Also, CGI scripts, especially those that run under perl or sh, would be a good 
> place to look for holes.  Don't forget to see what happens when you put 
> semi-colons in the data field of various fields, such as mailto:'s.
> 

	A CGI-script hole doesn't count as a netscape server hole.
system() is probably pretty bad though. 

-- 
sameer						Voice:   510-601-9777
Community ConneXion				FAX:	 510-601-9734
An Internet Privacy Provider			Dialin:  510-658-6376
http://www.c2.org (or login as "guest")			sameer@c2.org

I take a long term view of security. Basically I don't trust security software 
until it has been released in a stable condition for a few years.

The comments about Credit Card numbers miss the point. The volumes of trade on 
the Internet today are so small that the number of card numbers floating arround 
is insignificant. There are much easier ways to find them than cracking the 
Internet. This will not be the case in a couple of years time where the trade 
volumes are far higher.

Visa and Mastercard will be comming out with a spec which will have very tight 
requirements for implementations.


	Phill

On Mon, 18 Sep 1995, Perry E. Metzger wrote:

> Not, of course, that they disclosed it before -- it was found by
> reverse engineering the distributed executable. Not, of course, that
> they have a choice in the matter of whether to disclose it -- they
> will be "disclosing" how its done as soon as they release the
> code. Not, of course, that security through obscurity does any good --
> it just magnifies the pain.

Well, now that Cypherpunks have again shown yet another hole in Netscape 
security, I think we are one pretty good standing to demand

   ACCESS TO SOURCE CODE FOR NETSCAPE,

so we can work to help make Netscape "pretty good".  Any reporters 
listening?  

-Thomas

On Mon, 18 Sep 1995, John Young wrote:

>    The New York Times, September 19, 1995, pp. A1, D21.
> 
> 
>    Security Flaw Is Discovered In Software Used in Shopping
> 
>    By John Markoff
> 
>    Today, as word of the security flaw circulated only within
>    fairly small circles of Internet users, Netscape's stock
>    closed with a slight loss, down 75 cents, to $52.50, in low
>    Nasdaq trading volume.

Gotta like that open sell order.  :)

---
"In fact, had Bancroft not existed,       potestas scientiae in usu est
Franklin might have had to invent him."    in nihilum nil posse reverti
00B9289C28DC0E55  E16D5378B81E1C96 - Finger for Current Key Information

In article <199509190355.XAA01329@frankenstein.piermont.com>, perry@piermont.com (Perry E. Metzger) writes:
> 
> Markoff's article in the Times says:
> >    Netscape officials said today that they would strengthen
> >    the system, by making it significantly harder to determine
> >    the random number at the heart of their coding system. They
> >    said they would no longer disclose what data would be used
> >    to generate the random numbers.
> 
> Not, of course, that they disclosed it before -- it was found by
> reverse engineering the distributed executable. Not, of course, that
> they have a choice in the matter of whether to disclose it -- they
> will be "disclosing" how its done as soon as they release the
> code. Not, of course, that security through obscurity does any good --
> it just magnifies the pain.

  Regardless of what Markoff implies, we do not intend to depend on
security through obscurity.

> I suspect that there are far more flaws in Netscape. String buffer
> overflows are another good guess here -- they are probably rampant
> through the code both for the browser and the commerce server they
> sell. I can't prove it myself, of course, given that I don't have the
> time to rip the thing apart, but the same folks never seemed to learn
> their lesson in release after release when they worked at NCSA, and
> the only thing thats probably keeping their dignity here is the lack
> of distributed source code.

  Sigh.  For your information the security code for 1.x versions of
netscape was not even written by someone from NCSA.  The current
security team (which does not include the person who did the 1.x
version) also does not include anyone from NCSA.  While I can't
guarantee that such buffer overflow error don't exist in our
current products since I have not personally examined every line
of code, your generalization from experience with mosaic is bogus.
In the places in the code that I have seen where it looked like such
errors could have crept in, I have found that the correct checks
for buffer overflow have been in place.

	--Jeff

-- 
Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation
jsw@netscape.com - http://home.netscape.com/people/jsw
Any opinions expressed above are mine.

On 19 Sep 1995, Jeff Weinstein wrote:

> In article <199509190355.XAA01329@frankenstein.piermont.com>, perry@piermont.com (Perry E. Metzger) writes:
> > I suspect that there are far more flaws in Netscape. String buffer
> > overflows are another good guess here -- they are probably rampant
> > through the code both for the browser and the commerce server they
....
>   Sigh.  For your information the security code for 1.x versions of
> netscape was not even written by someone from NCSA.  The current
> security team (which does not include the person who did the 1.x
> version) also does not include anyone from NCSA.  While I can't

I will defend Netscapes code on the point about the RNG even though I 
have not seen any.  I assume the Netscape code is quite large and each 
release would have to pass various fuctionality tests.  How can you test 
that the RND seeding is wrong?  You have to actually look at the code, the 
number coming out are still random.  As of last week I was told by
Mike_Spreitzer.PARC@xerox.com that the random number generator seed 
routine in my DES library was only copying in 4 bytes of passed data 
instead of 8.  Given des_cblock data;, it was

memcpy(init,data,sizeof(data));

it should have been

memcpy(init,data,sizeof(des_cblock));

Rather hard to notice unless you know that des_cblock is passed as a 
pointer and even this can be compiler dependent.

Now I had not noticed this, my library runs like a charm and things 
appear random from the random number generator.  This sort of error can 
only be checked by reading the code and specifically looking at critical 
routines like this the RNG seeding routines.  The advantage of my code 
being public is that some-one like Mike can have a look and pick up 
problems like this.
The moral of the story I suppose is to be 
paranoid about checking routines relating to RNG.

What would be interesting is to see if packages like PEM use 
similar simple systems for generating random data.  Any of the systems 
that do digital envelopes are relying on libraries to provide random data 
for encryption keys.  At least with the old 'enter passwd' type 
encryption there was a bit of secret random data coming from a human, 
pitty about packet watchers seeing those characters as they fly over the 
net :-)

eric (who has also been burned by dodgy RNG seed routines in the past and
      so now uses a rather extrem system involving MD5 and lots of state :-).
--
Eric Young                  | Signature removed since it was generating
AARNet: eay@mincom.oz.au    | more followups than the message contents :-)

Eric Young writes:
 > >   Sigh.  For your information the security code for 1.x versions of
 > > netscape was not even written by someone from NCSA.  The current
 > > security team (which does not include the person who did the 1.x
 > > version) also does not include anyone from NCSA.  While I can't
 > 
 > I will defend Netscapes code on the point about the RNG even though I 
 > have not seen any.  I assume the Netscape code is quite large and each 
 > release would have to pass various fuctionality tests.  How can you test 
 > that the RND seeding is wrong?

The seeding isn't "wrong"; it's a design flaw.  (At least that's my
understanding; maybe I missed something.)

 > You have to actually look at the code, the  number coming out are
 > still random.

Two words: "design review".

 > This sort of error can only be checked by reading the code and
 > specifically looking at critical routines like this the RNG seeding
 > routines.

Uhh... OK.  Sounds like a plan to me.  For critical pieces of code
like that, having repeated exhaustive design/implementation reviews
should be a matter of course.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Nobody's going to listen to you if you just | Mike McNally (m5@tivoli.com) |
| stand there and flap your arms like a fish. | Tivoli Systems, Austin TX    |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Jeff Weinstein writes:
> > I suspect that there are far more flaws in Netscape. String buffer
> > overflows are another good guess here -- they are probably rampant
> > through the code both for the browser and the commerce server they
> > sell. I can't prove it myself, of course, given that I don't have the
> > time to rip the thing apart, but the same folks never seemed to learn
> > their lesson in release after release when they worked at NCSA, and
> > the only thing thats probably keeping their dignity here is the lack
> > of distributed source code.
> 
>   Sigh.  For your information the security code for 1.x versions of
> netscape was not even written by someone from NCSA.

If there is ANY place in the code that I can do a data driven buffer
overflow, I can force you to execute code that I supply. I don't give
a damn if it's in the "security" code. It makes no difference where it
is. If there is a chink, thats it -- you're meat.

Besides, the "security code" obviously was written by someone who
doesn't understand anything about cryptography and yet presumed to
play cryptographer. A person who thinks seeding things off the time
makes for a good PRNG is capable of almost anything.

> In the places in the code that I have seen where it looked like such
> errors could have crept in, I have found that the correct checks
> for buffer overflow have been in place.

I have very serious doubts in this regard -- VERY serious doubts,
especially given what I've been told by several former Netscape
employees.

Perry

> > 
> >   Sigh.  For your information the security code for 1.x versions of
> > netscape was not even written by someone from NCSA.
> 
> If there is ANY place in the code that I can do a data driven buffer
> overflow, I can force you to execute code that I supply. I don't give
> a damn if it's in the "security" code. It makes no difference where it
> is. If there is a chink, thats it -- you're meat.

  How would you do this if the buffer overflow happened in a buffer
which was allocated in a separate protected heap apart from stack
and executable data?

-Ray

Ray Cromwell writes:
> > > 
> > >   Sigh.  For your information the security code for 1.x versions of
> > > netscape was not even written by someone from NCSA.
> > 
> > If there is ANY place in the code that I can do a data driven buffer
> > overflow, I can force you to execute code that I supply. I don't give
> > a damn if it's in the "security" code. It makes no difference where it
> > is. If there is a chink, thats it -- you're meat.
> 
>   How would you do this if the buffer overflow happened in a buffer
> which was allocated in a separate protected heap apart from stack
> and executable data?

You could do that, but thats not how C does things. C allocates these
things on the stack. Overflow the buffer and you fandango on stack,
allowing you to change where the program counter jumps to on
subroutine exit, and allowing you to force your own machine code into
the system for execution.

I suspect that even were subroutine data allocated in a seperate heap
you could pull nasty tricks -- your protected heap probably has data
in it that controls execution flow, so cleverness might still get you
the same results.

Perry

>    The New York Times, September 19, 1995, pp. A1, D21.
...
>    Netscape officials said today that they would strengthen
>    the system, by making it significantly harder to determine
>    the random number at the heart of their coding system. They
>    said they would no longer disclose what data would be used
>    to generate the random numbers.

and from the WSJ article:

> "The information we were using to create the key is now a known set of
> information," said Jeffrey Treuhaft, security product manager for Netscape.

It sounds as if Netscape thinks that public knowledge of the key
generation is part of the problem.  I hope somebody on the security
team convinces management that entropy is more important than publicity.

(This could be a result of journalistic cluelessness, but it came up in
two independent articles.  It's enough to worry me.)

--
   Eli Brandt
   eli+@cs.cmu.edu
(back from a nice long mailing-list vacation -- it's nice to see that
 cpunks is still at the cutting edge.  for them what cares, I'm now
 a Ph.D. student at the CMU CS program...)

On Tue, 19 Sep 1995, Eli Brandt wrote:

> It sounds as if Netscape thinks that public knowledge of the key
> generation is part of the problem.  I hope somebody on the security
> team convinces management that entropy is more important than publicity.

No matter what they say in the press, I doubt it will take more than a few
weeks to reverse engineer the new RNG seeder and figure out where the data
comes from. 

I am hoping it was more of a PR thing than a technical thing.  I hope 
that Netscape tells us their RNG seed so Cyperhpunks don't have to go to all 
the trouble.  If they tell us, we can let them know if it is a reasonable 
mechanism or bogus.

-Thomas