Re: NYT on Internet Flaws

> From: "K. M. Ellis" <kelli@zeus.towson.edu>
> 
> This one is _really ripe_ for a response to the editor.  Ideas?
> 
> We could start something off-list if there are several interested in 
> co-authoring.
> 
I'd love to see something in there about most commercial sites being behind
firewalls without nfs access across the firewall.  This greatly reduces the
risk from the nfs problems.  If you get your binary via nfs from a trusted
host inaccessible from the internet, then if you have this problem management
can handle it as an employee problem;)  There are ways to make secure
firewalls, it's fairly well understood.  Sometimes people point to things
like the hack Mitnick did last Christmas, but his attack took advantage of
a couple of things a security expert shouldn't have allowed, first and
foremost two machines were accesible from the internet, and one of them
trusted root logins from the other without a password:(

I could write something up about it if you'd like.

Patrick
   _______________________________________________________________________
  /  These opinions are mine, and not Verity's (except by coincidence;).  \
 |                                                       (\                |
 |  Patrick J. Horgan         Verity Inc.                 \\    Have       |
 |  patrick@verity.com        1550 Plymouth Street         \\  _ Sword     | 
 |  Phone : (415)960-7600     Mountain View                 \\/    Will    | 
 |  FAX   : (415)960-7750     California 94303             _/\\     Travel | 
  \___________________________________________________________\)__________/

> I'd love to see something in there about most commercial sites being behind
> firewalls without nfs access across the firewall.  This greatly reduces the
> risk from the nfs problems.  If you get your binary via nfs from a trusted
> host inaccessible from the internet, then if you have this problem management
> can handle it as an employee problem;)  There are ways to make secure
> firewalls, it's fairly well understood.  Sometimes people point to things
> like the hack Mitnick did last Christmas, but his attack took advantage of
> a couple of things a security expert shouldn't have allowed, first and
> foremost two machines were accesible from the internet, and one of them
> trusted root logins from the other without a password:(
> 
> I could write something up about it if you'd like.

You might want to refer the NYT to the recent study published by
Computer Security Institute (in info-sec super journal on our W3 site).

There are alse several papers there on "Internet Holes" under Network
Security in the same on-line journal.  Every month, another 5-10 holes
are added to those published in this forum.

-- 
-> See: Info-Sec Heaven at URL http://all.net
Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236

Dr. Frederick B. Cohen wrote:

| There are alse several papers there on "Internet Holes" under Network
| Security in the same on-line journal.  Every month, another 5-10 holes
| are added to those published in this forum.

	And how many of those holes are published by bugtraq/CERT/8lgm
first? Just curious to see if this is another list I should be on...

Adam

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

> | There are alse several papers there on "Internet Holes" under Network
> | Security in the same on-line journal.  Every month, another 5-10 holes
> | are added to those published in this forum.
> 
> 	And how many of those holes are published by bugtraq/CERT/8lgm
> first? Just curious to see if this is another list I should be on...

I am writing a series of atricles - one per month - for Network Security
Magazine, and am putting lat month's article up as they publish the next
one.  Probably 20% have appeared on bugtraq, etc.

All I am doing is going through the TCP/IP protocols (and other such
stuf) one at a time, writing a short piece on each, describing the most
obvious holes, giving some ideas of how they have been/can be exploited,
and describing in general terms what we might do to fix them.  Next
issue covers NNTP - then comes a 2-month (I think) issue on TCP as a
protocol (lots of holes there) - then whatever strikes my fancy next.  I
figure it will take a few years at this rate to get through the most
important protocols and services.

-- 
-> See: Info-Sec Heaven at URL http://all.net
Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236

Patrick Horgan wrote:
> 
> > From: "K. M. Ellis" <kelli@zeus.towson.edu>
> >
> > This one is _really ripe_ for a response to the editor.  Ideas?
> >
> > We could start something off-list if there are several interested in
> > co-authoring.
> >
> I'd love to see something in there about most commercial sites being behind
> firewalls without nfs access across the firewall.  This greatly reduces the
> risk from the nfs problems.  If you get your binary via nfs from a trusted
> host inaccessible from the internet, then if you have this problem management
> can handle it as an employee problem;)  There are ways to make secure
> firewalls, it's fairly well understood.  Sometimes people point to things
> like the hack Mitnick did last Christmas, but his attack took advantage of
> a couple of things a security expert shouldn't have allowed, first and
> foremost two machines were accesible from the internet, and one of them
> trusted root logins from the other without a password:(

  It might also be worth noting that people accessing the net
via an ISP from home do not typically use NFS either.

	--Jeff

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

>From: Jeff Weinstein <jsw@netscape.com>
>Date: Wed, 11 Oct 1995 16:03:11 -0700

>Patrick Horgan wrote:
>> 
>> > From: "K. M. Ellis" <kelli@zeus.towson.edu>
>> >
>> > This one is _really ripe_ for a response to the editor.  Ideas?
>> >
>> > We could start something off-list if there are several interested in
>> > co-authoring.
>> >
>> I'd love to see something in there about most commercial sites being behind
>> firewalls without nfs access across the firewall.  This greatly reduces the
>> risk from the nfs problems.  If you get your binary via nfs from a trusted
>> host inaccessible from the internet, then if you have this problem management
>> can handle it as an employee problem;)  There are ways to make secure
>> firewalls, it's fairly well understood.  Sometimes people point to things
>> like the hack Mitnick did last Christmas, but his attack took advantage of
>> a couple of things a security expert shouldn't have allowed, first and
>> foremost two machines were accesible from the internet, and one of them
>> trusted root logins from the other without a password:(

>  It might also be worth noting that people accessing the net
>via an ISP from home do not typically use NFS either.

>	--Jeff

It might be even better to note that the amount of NFS traffic that passes
outside of a given local network/geographical area is small NFS does
reasonably poorly from a performance perspective over WAN connections in
general so most organizations don't use it for more local are use.
WUarchive allowed it for a while but it was infinitely slow compared to
ftp.  I suspect that a protocol analysis of a major interchange point
(MAE's, NAP's, etc) would show NFS traffic at far less than 1% of the
total.  

The NFS threat should be delegated to that class of problems which are
characterized as locally insecure, which can be easily exploited by a
malicious user (internal or external who has broken in), locally useful,
something which can be made better (kerberos version for example), but
generally isn't for ease of use.

--->  Phil


(BTW my 'mount ftp.netscape.com:/pub /mnt' command failed for some reason,
can you look into it :-)

> 
> Patrick Horgan wrote:
> > 
> > > From: "K. M. Ellis" <kelli@zeus.towson.edu>
> > >
> > I'd love to see something in there about most commercial sites being behind
> > firewalls without nfs access across the firewall.  This greatly reduces the
> 
>   It might also be worth noting that people accessing the net
> via an ISP from home do not typically use NFS either.
> 

They don't often have the skill/knowledge/concern to verify a PGP checksum
to ensure someone didn't patch their browser, either.

People seem to miss that the NFS hack was only an _example_ of a powerful
way to silently destroy the integrity of an executable. Spoofing the
insecure FTP session they used to retrieve it works. Sending them a random
trojan horse works. The point was not that NFS is insecure. It was that
unless you can authenticate your executables as being trustworthy NOTHING
ELSE MATTERS.

SSL, good RNGs for session key selection, etc, are all null
and void if you run (any) untrusted software that patches
your Netscape executable, for example, or if you got a bum copy to
start with.

Paul

Paul A Gauthier wrote:
> 
> >
> > Patrick Horgan wrote:
> > >
> > > > From: "K. M. Ellis" <kelli@zeus.towson.edu>
> > > >
> > > I'd love to see something in there about most commercial sites being behind
> > > firewalls without nfs access across the firewall.  This greatly reduces the
> >
> >   It might also be worth noting that people accessing the net
> > via an ISP from home do not typically use NFS either.
> >
> 
> They don't often have the skill/knowledge/concern to verify a PGP checksum
> to ensure someone didn't patch their browser, either.

  I don't believe that my posting of PGP signed checksums last night
is a final solution that will make the world safe for all end users.
I'm rather insulted that you imply that I do.  If you read Markoff's
article, you will see that we have stated that we are working on
a more global solution.

> People seem to miss that the NFS hack was only an _example_ of a powerful
> way to silently destroy the integrity of an executable. Spoofing the
> insecure FTP session they used to retrieve it works. Sending them a random
> trojan horse works. The point was not that NFS is insecure. It was that
> unless you can authenticate your executables as being trustworthy NOTHING
> ELSE MATTERS.
> 
> SSL, good RNGs for session key selection, etc, are all null
> and void if you run (any) untrusted software that patches
> your Netscape executable, for example, or if you got a bum copy to
> start with.

  I think everyone agrees that if you don't check the bits you
get from an insecure FTP session, or if you let a bad guy write to
your disk, then you may be in trouble.  The point is that you and a
few reporters are running around yelling at the top of your lungs
that internet commerce is totally doomed because it is possible for
users to infect their systems with viruses.  In the case of
Netscape, users who are worried about their binary being infected
during downloading could actually buy the product, either in their
local computer store or from us directly.

  Perhaps you have a solution to offer to this whole problem?

	--Jeff

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

> Jeff Weinstein wrote:
> > Paul A Gauthier wrote:
> > > Patrick Horgan wrote:
> > > > > From: "K. M. Ellis" <kelli@zeus.towson.edu>
> > > > >
> > > > I'd love to see something in there about most commercial sites being behind
> > > > firewalls without nfs access across the firewall.  This greatly reduces the
> > >
> > >   It might also be worth noting that people accessing the net
> > > via an ISP from home do not typically use NFS either.
> > >
> > 
> > They don't often have the skill/knowledge/concern to verify a PGP checksum
> > to ensure someone didn't patch their browser, either.
> 
>   I don't believe that my posting of PGP signed checksums last night
> is a final solution that will make the world safe for all end users.
> I'm rather insulted that you imply that I do.

That's not what I was saying. The implication of the comments I was
responding to was that "firewalls and ISP users w/o NFS make this whole
issue a non-problem". And I think we all know that's not true. Presumably
if you have a firewall, sure, you have a sysadmin who will check the
integrity of the executable when it is installed behind it.

But ISP users w/o NFS are exactly the unparanoid unwashed masses who would
be perfectly targetted for this type of attack, and even worse would be
the least likely to do checksumming to protect themsevles. That is
the only point I was trying to make.

> your disk, then you may be in trouble.  The point is that you and a
> few reporters are running around yelling at the top of your lungs
> that internet commerce is totally doomed because it is possible for
> users to infect their systems with viruses.

In our post I don't believe there was any yelling, or any serious
doom and gloom. Mainly we just were trying to prod people to internalize
that these old protocols we're all still using are soon going to come under
heavy attack now that there is financial incentive to do it.


>   Perhaps you have a solution to offer to this whole problem?

So I am actually quite fond the idea of a company becoming a well-known
distributor of checksums. Users could either subscribe to a quarterly
bootable CD-ROM which checks out their system. Or a bootable read-only
floppy which causes their modem to call "1-900-CHEKSUM" and download
the needed checksums on demand.

This would be low-cost thing for the user, doing it once every few months
it would be pretty low hassle. Spoofing the phone line is a risk that I
can live with, as can I live with the risk of someone spoofing these
CD-ROMs that are mailed out 4 times a year.

And please, cypherpunks, don't start talking about "oh, but your CMOS
could have a trojan in it", and "do you really trust your boot code
in your SCSI". Because, yes, I sure do trust those things. And I think
it's entirely reasonable to trust them for the purposes we're discussing.

There are of course ways to minimize these attacks through crypto.
If you do have the correct CD-ROM/bood disk it can easily authenticate
the party on the other side of the phone. No phone spoofing.

To minimize the chances of getting a spoofed copy of the disk in
the mail, inclose a magic cookie inside the box. The magic cookie
must appear on the mailing label of the next box otherwise the user
is suspicious. Some other random sugar and now the user can tell if
they are getting legit disks as long as their first disk was legit,
and someone isn't opening their mail in a specific attempt to attack
them.

Paul

On Wed, 11 Oct 1995, Jeff Weinstein wrote:

> > I'd love to see something in there about most commercial sites being behind
> > firewalls without nfs access across the firewall.  This greatly reduces the
> > risk from the nfs problems.  If you get your binary via nfs from a trusted
> > host inaccessible from the internet, then if you have this problem management
> > can handle it as an employee problem;)  There are ways to make secure
> > firewalls, it's fairly well understood.  Sometimes people point to things
> > like the hack Mitnick did last Christmas, but his attack took advantage of
> > a couple of things a security expert shouldn't have allowed, first and
> > foremost two machines were accesible from the internet, and one of them
> > trusted root logins from the other without a password:(
> 
>   It might also be worth noting that people accessing the net
> via an ISP from home do not typically use NFS either.

	And that this is the segment of the user population that is most 
important to commerce online.  But I still hate to see these types of 
solutions being used to try and cover something that should, and could be 
fixed in the underlying protocol itself.  Wouldnt AH and ESP take care of 
a large portion of the existing security holes?  Certainly not all of 
them, but it would solve alot of problems and make development of secure 
applications much easier.

note: is anyone working on implementeing some of the things outlines in 
R(1825?) ?  I think Perry posted regarding it awhile back, but havent 
heard much about it since.

Nesta Stubbs		     "Betsy, can you find the Pentagon for me? 
Cynico Network Consulting     It has five sides and a big parking lot" 
nesta@cynico.com			-Fred McMurray-

Nesta Stubbs writes:
> note: is anyone working on implementeing some of the things outlines in 
> R(1825?) ?  I think Perry posted regarding it awhile back, but havent 
> heard much about it since.

Yes, work is going on on the IPSEC stuff, though my own is stalled at
the moment because of excessive personal scheduling load...

Perry