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.
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
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 :-)
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
participants (8)
-
Adam Shostack -
fc＠all.net -
Jeff Weinstein -
Nesta Stubbs -
patrick＠Verity.COM -
Paul A Gauthier -
Perry E. Metzger -
Philip J. Nesser