Slashdot Mirror

BTW - I have left Javascript turned off in my browser for most of a year now, ever since the CERT Coordination Center recommended everyone do so because some online discussion sites allow HTML posts but don't filter <SCRIPT> tags out of their users' posts so someone who knows how to crack javascript can eat your machine with a forum post (Slashdot filters out script tags), and I leave Java off ever since that web server thingy appeared a couple days ago - and I urgently emailed everyone I knew and told them to turn off Java too.

Yes, solutions are on the horizon but they're not here yet. Yes, there are workarounds like typing posts into a notepad and copying them in from the clipboard - so my problem can be taken care of, but not the novice users.

So I'll take my applications as locally executing programs, thank you, and I'll be happy when a solution does appear which survives extensive security auditing

My friend's opinion wasn't about doing stuff with Java or Javascript at his company - they specifically didn't use it because they said they couldn't count on it being implemented in the browser - but with plain old HTML, generated by perl scripts on the server backed by a Sybase database, and forms.

He thought this was the best thing since sliced bread, and as a long-time Mac GUI programmer, I thought he was completely clueless.

I think Carnegie Mellon is credible, especially since CMU's got CERT - which specializes in security vulnerabilities. Altough I believe CERT is still funded by the government (department of defense).

Anyway, everyone knows that Penn State students are only good at drinking and rioting.

I think Carnegie Mellon is credible, especially since CMU's got CERT - which specializes in security vulnerabilities. Altough I believe CERT is still funded by the government (department of defense).

Anyway, everyone knows that Penn State students are only good at drinking and rioting.

(Yes, Apple has always used Unix, I had a Sun 3/280 on my desk in 1990).

I got invited into the game after complaining long and loud at A/UX 2.0 wasn't living up to the CERT advisories during it's beta cycle.

You need to read Risks if you:

• Use and depend on computers in any but the most trivial way
• Program computers
• Make policy decisions regarding computers
• Operate computers in a way that affects safety (pilot a modern airplane, work in a hospital)
• Use computers in a way that may impact your own safety (flown on a modern airplane lately?)

You might also want to check out the book "Computer Related Risks" by forum moderator Peter G. Neumann ISBN 020155805X. It draws on material from the forum but discusses it in greater depth. You'll find it at all the online bookstores and many local bookstores as well.

Here's a few of my own posts to Risks:

The Sinking of the USS Gitarro

A US Navy submarine was sunk in the Mare Island channel near Vallejo, California by a test technician. He was trying to level the ship to run a test, and only knew how to take in ballast water, not expel it. The forward sonar hatch was off, power cables were run through the pressure safety doors because the sub was in for repairs, and so the might Gitarro sunk. My dad was stationed at the shipyard at the time, back in the 60's.

Algorithms Have Unclear Boundaries

Copy of a letter I wrote the patent office, on the problem of defining what is or is not an algorithm in a program when the boundaries between them cannot be precisely defined. Discussed the problems that occur when the virtual machine breaks down (as I guess happens in this case).

Excel Linked Spreadsheet Bug

In which a friend of mine bounced a business check for four thousand dollars because of a bug in Microsoft Excel - a bug he could later demonstrate at will.

Tilting at Windmills for a Better Tomorrow

Slashdot doesn't allow the SCRIPT tag but some sites do (perhaps unknowingly) and so someone can write an apparently innocent comment in a chat and include a script that eats your hard disk.

A close friend of mine told me that she's been writing largely in Javascript for a long time now and her company is in fact basing their entire online strategy on Javascript. They're making a huge investment in it and will be selling a product that will be very expensive that will require very highly paid people to leave Javascript on all day long just to do their work.

I was astonished at that idea and said they were doing a disservice to their customers by encouraging them to enable Javascript, let alone requiring it for the basic functions of their product.

She was pretty incredulous about this, even after I recounted the above CERT advisory. She told me Javascript was sandboxed and could not do anything destructive. I told her it was full of holes and highly nonstandardized and bugs were being found in it all the time.

I also advisted her to read the Forum on Risks to the Public in Computers and Related Systems (also available as comp.risks on the Usenet News).

I told her I felt that reading Risks was a very basic requirement for anyone who wrote software for a living, and was doubly important for someone like her who wrote software that would effect people's lives in a substantial way (I can't be too specific - but she's not writing entertainment software). She thought this was all very silly.

Now, slashdotters, what can I say to my friend - what can I say that is of real substance not just flaming? Can you give me literature references or URL's? Pertinent CERT advisories would be good.

BTW - here's a suggestion - while I leave Javascript turned off most of the time, I often find I have to turn it on to use some sites. It really gets me down that some sites don't even function if Javascript is not enabled.

But Junkbuster is a simple proxy that will filter out ads and stop cookies, but allow them in controlled ways. For example, I only allow cookies from Slashdot and my bank, so I don't have to have cookies from any other site and I don't have to keep turning cookies back on to read slashdot.

I think it would be a fairly simple matter to modify the Junkbuster source code to filter out SCRIPT tags for most sites except those that are on an approved list. The source code is GPL'ed so someone with the inclination could just get the source and do it. I'd do it myself but I'm real busy for the next little while.

Frankly, partial or non-disclosure keeps the information from the people who really need it. Academics need the information to keep up with and understand what a vulnerability really is. Things like CERT advisories are useless for this. They don't have the information needed to figure out what the vulnerability really is and how to classify it. Another group hurt by partial or non-disclosure is sysadmins. If a sysadmin scans bugtraq even weekly, he can often have a patch or workaround for a vulnerability in his systems long before the vendor releases anything. Open source really rules here where there are usually alternatives such as fixing the code or getting a different free package put up instead.

Even if there exists some cabal of fully informed individuals, they are always going to leave out many of the folks that need the info. Face it, most vulnerability information is useless without enough info to exploit it.

security can't be improved unless "gray hat" hackers stop disclosing security holes to the public and stop creating tools for so-called "script kiddies" to exploit the holes.

This is FUD, pure and simple. There's nothing gray about CERT (they provide a legitimate and valuable service). And there's nothing gray about rootkits or the people who write them (there's no legitimite purpose rootkits can be put to)

-y

While my complaints about A/UX fell on deaf ears in the A/UX team, the people who maintained the Unix machines for Apple employees to use (yes, some Apple employees do use Unix, they even used to have a Cray running Unicos) invited me to play capture /flag.

In the root directory of some of the multiuser machines was a file named flag that was not writeable. The objective was to write into it and then tell the admins how you did it.

When I started the current contents was "such and such a department rules". I guess I would have written "Mike was here" or something.

While I was able to crack A/UX 2.0 every which way, I never could capture /flag.

My understanding is the security holes got fixed in A/UX 3.0. It's a dead product now.

The way I found the security holes was to start methodically working through the CERT advisories and checking which ones A/UX was not compliant with. When I'd find one and they'd refuse to fix it, I'd file a bug report and send some emails around with explicit details of how you can break root because they weren't listening to CERT.

If you administrate a computer on a network, you should go through the CERT advisories yourself and tighten up your system.

Fyodar's exploit world has a good collection of scanners, articles, and known exploits (if that's what you want).

Word of advice though, don't ask about the back doors in the various Quakes (here and here) during interviews on /. unless you've got Karma to spare . . . ouch.

It's mostly a conglomerate of different sources, but a number of the articles are kinda interesting. Keeping up with CERT advisories would probably be better for self defense though (always good to know what they do though). The scanners are pretty good, especially if your, um, on the "testing" end and the the detection end . . .

Cert published an advisory not to long ago regarding scans on port 137 (netbios)

the advisory

rosie_bhjp

• Security cannot be achieved by debugging.
  Read the decade of CERT advisories for Sendmail and BIND to convince yourself of this.
• Linux, and UNIX, contain some terrible basic security-related design decisions.
  The notion of "root" is bad enough, but "set-UID to root" is worse. This results in far too much code being trusted. In particular, it should be impossible to run non-trusted code as root. This means no root log-ins, for example. In a secure system, as your privileges go up, the amount of software you're allowed to run goes down. In a sandbox, you can run anything. As administrator, you can only run a few tools that do very specific things with lots of checking. This is completely alien to UNIX.
• Fixing known holes only protects against the inept.
  A serious attacker will find their own holes, and will keep quiet about them until they break in and steal something. Fixing known holes protects against script kiddies.
• If you don't have a security model you can write down on a small piece of paper, you can't enforce it.
  DoD has a simple security model, which is reasonably enforceable. See the Orange Book. There's Linux support for it. You take a performance hit and can't run some popular software. But in that direction lies real security.
• Discretionary security doesn't work.
  With discretionary security, users can turn off security. "chmod 777" is the usual way. With mandatory security, if you're processing SECRET information, nothing you or your programs can do makes it non-SECRET. The problem with discretionary security is that it's extremely difficult to tell if the system is in a secure state, and it's very easy to make a change that opens a security hole.
• Secure systems are no fun
  OK, you've got a secure system. Want to run Napster? No way; it's acting as a server and transmits your files. Want to download a game? If it will run in a sandbox, OK, but it can't talk to other players. Running a web browser may be OK, but the browser will be shot down if it tries to launch MS Word to read a .doc file. And the browser will need some work to live within the restrictions of a secure system.

A secure open-source system is quite possible. But it won't be Linux as we know it.

I challenge you to find a security bug in any version of VMS past 4. Here's one in 7.1.

--

It's actually en exploit discussed on CERT where a malicious web site can embed some script in a link to a cgi script, which in turn pastes it into the resulting page unaltered and the victim's browser executes it.

In this case the script is a bit of javascript that outputs your slashdot cookie via search.pl. All javascript enabled browsers are affected by this.

It's just a result of sloppy coding.

As anyone who reads /. should know, you can't put anything programmatic in a cookie (and that includes jscript).

Oh, really ?

Why don't you check this Cert Advisory then. I'll post a snippet for you:

Attacks May Be Persistent Through Poisoned Cookies

Once malicious code is executing that appears to have come from the authentic web site, cookies may be modified to make the attack persistent. Specifically, if the vulnerable web site uses a field from the cookie in the dynamic generation of pages, the cookie may be modified by the attacker to include malicious code. Future visits to the affected web site (even from trusted links) will be compromised when the site requests the cookie and displays a page based on the field containing the code.

There have been numerous examples given on how to exploit this. They all involve inserting javascript code into a cookie.

It is specifically MS Outlook and its tight integration that is the course of the problem (plus the total lack of unprivileged accounts in Windows 9x). People who don't use Outlook, eg. Eudora users are also not as vulnerable. But stupidity can always overcome whatever advantage these different mailers grant.

There's also a CERT advisory a few months back about a similar problem: Malicious HTML Tags Embedded in Client Web Requests

I couldn't get through when using www.slashdot.org, but when I tried slashdot.org it worked. There seams to be alot of name server dropouts on the net lately. You guys need to keep your name servers code up to date. The Bind that comes with RedHat 6.1 on the CD has a known root exploit that is actively being exploited. You need to upgrade to BIND 8.2.2 patchlevel 5.

Oh, joy!

Here's a buffer overflow.

Quote:

Date: Thu, 5 Nov 1998 02:38:51 +0200

This message contains information relevant to people who compile ssh with --with-kerberos5. There is one or more potential security problem in the Kerberos code. These issues are not relevant for people who have not explicitly specified --with-kerberos5 on the configure command line.

Here's a bounce attack Here's another one.

Two examples of the same thing, from August and September 1997 and version 1.2.17. You realize that skript kiddies prey upon those who don't keep their software up-to-date?

Now what would happen I used a more current source of attacks? There were a couple on BugTraq a couple months ago...

You mean this CERT advisory dated 13 Dec 1999?

Quote:

Some versions of sshd are vulnerable to a buffer overflow that can allow an intruder to influence certain variables internal to the program. This vulnerability alone does not allow an intruder to execute code. However, a vulnerability in RSAREF2, which was discovered and researched by Core SDI, can be used in conjunction with the vulnerability in sshd to allow a remote intruder to execute arbitrary code.

I think the lessons are:

1. Keep your software up-to-date.
2. Don't believe for a moment you're completely protected.
3. Keep informed of the latest in security threats.

The only completely safe computer is one that is incapable of being turned on.

James

Before you go too far into JAVA, JITs etc, please read this warning about using executable content languages via html

Apart from the other recommendations made (Essential Sys Admin and Practical Unix Security are must-haves), I would suggest:

• Install TCP Wrappers and configure it appropriately. Block anything that you don't need, log everything else.
• Read the corresponding tech tips from CERT, depending on what you need (e.g. if you want to set up an FTP server, read the "Anonymous FTP Configuration guidelines")
• Read the WWW security FAQ if you are planning on running a web server.
• Use Tripwire. They have a commercial version, but you can always use the free version (1.3). I think they also give the newer version for Linux for free.
• Read other documents at http://www.cert.org/nav/securityim provement.html and http://xforce.iss.net/library/faqs/.
• Be always alert for anything strange that happens on your system. There is no substitute for an alert and informed sysadmin.

Apart from the other recommendations made (Essential Sys Admin and Practical Unix Security are must-haves), I would suggest:

• Install TCP Wrappers and configure it appropriately. Block anything that you don't need, log everything else.
• Read the corresponding tech tips from CERT, depending on what you need (e.g. if you want to set up an FTP server, read the "Anonymous FTP Configuration guidelines")
• Read the WWW security FAQ if you are planning on running a web server.
• Use Tripwire. They have a commercial version, but you can always use the free version (1.3). I think they also give the newer version for Linux for free.
• Read other documents at http://www.cert.org/nav/securityim provement.html and http://xforce.iss.net/library/faqs/.
• Be always alert for anything strange that happens on your system. There is no substitute for an alert and informed sysadmin.

Apart from the other recommendations made (Essential Sys Admin and Practical Unix Security are must-haves), I would suggest:

• Install TCP Wrappers and configure it appropriately. Block anything that you don't need, log everything else.
• Read the corresponding tech tips from CERT, depending on what you need (e.g. if you want to set up an FTP server, read the "Anonymous FTP Configuration guidelines")
• Read the WWW security FAQ if you are planning on running a web server.
• Use Tripwire. They have a commercial version, but you can always use the free version (1.3). I think they also give the newer version for Linux for free.
• Read other documents at http://www.cert.org/nav/securityim provement.html and http://xforce.iss.net/library/faqs/.
• Be always alert for anything strange that happens on your system. There is no substitute for an alert and informed sysadmin.

How sad is it that Suck has, by far, the best article on this subject so far? Pointing out the real problem, IP, the people who should fix it, the "dot coms", and the reason they won't, money.

How can you properly protect against many DOS attacks?

How can you properly protect yourself against real world vandalism? Vigilance, monitoring, and prosecution. We just need another generation to grow up and realize, by being taught from a young age, that these antics do nothing but hurt in the long run. What we have is a generation of kids and young adults who have no moral framework for their activities on the Internet. It has also empowered the disenfranchised (*cough*) to make their voices heard both far and wide.

Anyway, you can't stop them through normal means, here's the offical word (from over two years ago)

--

Once you stop SYN flood attacks, and have the fixes in for stupid bugs like the "Ping of death" and IP broadcast packet expansion, everything else that can happen has a reachable IP address associated with it. Those attacks are traceable back at least one level, and you can make them ineffective by imposing some kind of quota system or block based on source IP address at various levels of the server. Web servers like Apache might need to be smartened up a bit so they don't choke when a huge number of requests come in from the same IP address (and that mechanism needs to know about major proxy servers like AOL), but that's not too tough.

The key points to understand are this:

• There are technical fixes to these vulnerabilities. We're talking weeks of work on a few specific pieces of software, not re-engineering the whole Internet.
• We don't need a massive FBI presence, $2 billion, or Presidential involvement to fix the problem.
• Journalistic coverage of this event has grossly overstated the problem.

John Nagle / Menlo Park, CA

Also, as someone who works on NT as well as other OS's, there is no reason why such attacks cannot be mounted from MS OS's. It's just that the set of tools that apparently were involved in this set of attacks work on Solaris and Linux boxes. For example, another similar attack strategy, IIRC, has been identified for Macs running OS9.

The main point of the post is dead on -- the problem is large numbers of unneccessarily insecure machines on the net -- in this case *nix boxes -- that act as hosts or agents for staging the attack. CERT has been warning about this general topic for many months, with specific warnings about just this kind of technique using the tools (TRINOO and TFN2K) now suspected. There are specific things you can do to prevent your servers hosting this kind of attack, but too many sites have not carried out these safeguards -- and this week has proved it. Ingress filtering and better packet filters on the backbones will cut back on smurfing, but there are ways around that. If you are a sysadmin, and you are not monitoring the CERT current activity page as well as others, subscribing to some of the appropirate mailing lists and keeping your systems up to date accordingly, this will keep on happening, and Microsoft has nothing to do with it.

Paranoiac whining will not get us anywhere.

Also, as someone who works on NT as well as other OS's, there is no reason why such attacks cannot be mounted from MS OS's. It's just that the set of tools that apparently were involved in this set of attacks work on Solaris and Linux boxes. For example, another similar attack strategy, IIRC, has been identified for Macs running OS9.

The main point of the post is dead on -- the problem is large numbers of unneccessarily insecure machines on the net -- in this case *nix boxes -- that act as hosts or agents for staging the attack. CERT has been warning about this general topic for many months, with specific warnings about just this kind of technique using the tools (TRINOO and TFN2K) now suspected. There are specific things you can do to prevent your servers hosting this kind of attack, but too many sites have not carried out these safeguards -- and this week has proved it. Ingress filtering and better packet filters on the backbones will cut back on smurfing, but there are ways around that. If you are a sysadmin, and you are not monitoring the CERT current activity page as well as others, subscribing to some of the appropirate mailing lists and keeping your systems up to date accordingly, this will keep on happening, and Microsoft has nothing to do with it.

Paranoiac whining will not get us anywhere.

You know, I remember checking out CERT last December and reading/downloading the "notes" they provided regarding their conference on "Distributed-Systems Intruder Tools workshop.". Anyways, I find it peculiar that these floods are now becoming a problem only a month and a half after the notes were made available. That, in my eyes, proves one reason not to make such information available. On the other hand, by providing the info it allows us, the OSS community, to create and make available to all tools necessary to combat the problem. It really pisses me off to see news sites jump to conclusion on things, ESP if they have no valid proof. Now I wonder what would happen if the mrBoB News Network (MbNN) made a clain either/both online or TV that M$ had been to blame? I'd be sued for slander or whatever. It's a shame that we have no real way to enforce the same protections for a good name (for linux + OSS) So, IMHO, I figure it serves current.net right to be DoS'd or /... or whatever you wanna call it. BoB

Quoting David Dittrich from http://staff.washington.e du/dittrich/misc/trinoo.analysis

Trinoo daemons were originally found in binary form on a number of Solaris 2.x systems, which were identified as having been compromised by exploitation of buffer overrun bugs in the RPC services "statd", "cmsd" and "ttdbserverd". These attacks are described in CERT Incident Note 99-04:

http://www.cert.org/incident_notes / IN- 99-04.html

So basically this guy is making it all up as the method he is spouting was not used, it took me ten mins to find this out. Windows is vulnerable to buffer overruns as much as anything else.

BTW, I ran the program at work. But what do I care, I work for THE MAN!:-) Let the FBI mess with my agency, we'll kick their butts. Finally, if the program came from FEMA, then I would be worried.:-)

I've always been rather partial to CERT's alert

My best suggestion though, if you want a real answer to this question, ask a lawyer, not a geek.

CERT put out a thing about this a few months ago in this document - also see some of the links they have to past documents.

It looks like the script kiddies are basically getting a bunch of insecure machines to just all start pinging the hell out of something from different places around the net. Ya gotta admit, you could flood the hell out of a connection pretty fast just by finding even 20 insecure hosts.

I myself fail to see what the point of attacking Yahoo is. AFAIK, they are not domain name hijacking like a certain e-tailer nor are they trying to enforce a stupid patent like another certain e-tailer, and they did not try to trademark WHOIS, so what is the point of going after them?

1) stacheldraht"
2) trinoo
3) tfn tribe flood network
4) tfn2k
5) Cert's denial of service tools
Useful?

This only lists a small portion of browsers that are capable of running in linux, there was an article not long ago with quick reviews on 21 Linux Web Browsers?, the article can be found here.

I have a personal preference to any browser that is not capable of javascript, although, it does have it's uses, as we have seen this week, with the CERT release, there are some things it can do that we may not like...

I personally use some of these browsers after Netscape has Crashed (TM) for the 10th time in as many minutes, it reminds me too much of another OS I do my best to get away from :)

It is not an Apache problem. It is not a Microsoft problem. It is not a Netscape problem. In fact, it isn't even a problem that can be clearly defined to be a server problem or a client problem. It is an issue that is truly cross platform and is the result of unforeseen and unexpected interactions between various components of a set of interconnected complex systems.

Don't forget the other following security references:

Cert: http://www.cert.org/

Packetstorm: http://packetstorm.securify.com/index.s html

and Attrition has some stuff too http://www.attrition.org/

God damn right, and what will drive the last nail in is if "Shrub" Bush take the White House in November. Not that the Democrats are so much better, look at how eager Clinton's Reno's Department of "Justice" has been to trample all over citizens's freedoms, but at least no Dem ever put anybody close to as awful as Rehnquist or Scalia on the Supreme Court, not in my lifetime, anyway. If Shrub wins, expect him to nominate at least another one or two Rehnquist/Scalia clones to the Supreme Court, and then the game's up. The Scalia gang clearly don't believe that any constitutional rights at all exist for anyone besides corporations and cops. Shrub's new revanchist Supreme Court will rule those evanescent "constitutional rights" of yours right out of existence; we'll graduate to a full-fledged police state.

Take the current full-bore legal assault upon open-source software to the next step. I wouldn't put it past such a Supreme Court to rule that possession of gcc could be considered a felony. After all, isn't that the master software tool that those villainous, felonious "hackers" all use to break into high-security Internet messaging systems and manufacture malicious, insidious, destructive computer viruses?

Well, no it's not, you know that and I know that, but the wide public doesn't know Jack and the press are in full propaganda/panic mode over hackers and that evil Internet (as they see themselves being scooped out of business by the likes of a Matt Drudge, that is, a nobody, a zero like you or me, with a web page). Besides, when has unwillingness to promote a lie ever even once restrained a cop on a mission of righteousness or a politician trying to panic a herd of voters into the chute?

Yours WDK - WKiernan@concentric.net

I would wager by the fact that it's been confirmed by Apple labs and is detailed in a PGP-signed CERT advisory that you can stop calling it a hoax now.

Normally people do things like prove that vulnerabilities do not exist (by testing or by intimate knowledge of the way a system is designed) before calling them hoaxes. Since I had no access to MacOS 9, and no verifiable sources were saying that it was a hoax, I was definitely not going to propagate that rumor.

Security problems are real. Let's help them get solved instead of shooting off our mouths.

There is also a CERT advisory covering this and a few other DoS's (i.e. TFN2K). The CERT advisory is available at http://www.cer t.org/advisories/CA-99-17-denial-of-service-tools. html.

The problem is that the script kiddies crack a few hosts sitting on T1s or better and then run the attack from there.

You might check out CERT's paper on distributed DoS attacks. They don't go into great detail, but it does explain how the kiddies operate.

The problem is that the script kiddies crack a few hosts sitting on T1s or better and then run the attack from there.

You might check out CERT's paper on distributed DoS attacks. They don't go into great detail, but it does explain how the kiddies operate.

MacOS 9 can be abused by an intruder to generate a large volume of traffic directed at a victim in response to a small amount of traffic produced by an intruder. This allows an intruder to use MacOS 9 as a "traffic amplifier," and flood victims with traffic. According to [3], an intruder can use this asymmetry to "amplify" traffic by a factor of approximately 37.5, thus enabling an intruder with limited bandwidth to flood a much larger connection. This is similar in effect and structure to a "smurf" attack, described in

http://www.cert.org/advisories/C A-98.01.smurf.html

Unlike a smurf attack, however, it is not necessary to use a directed broadcast to achieve traffic amplification.

and

Appendix A. Vendor Information Apple Computer We've reproduced the problem in our lab and we are working now to create a fix that can be easily distributed to our customers. The problem only affects customers running our most recent release of networking software on machines that are continuously attached to the internet.

While most Macintosh customers are not affected by this problem, we are moving quickly to put a solution in place.

Don't know if this is related, but here is a link to the Cert Advisory discussing how Mac OS9 can be used as a 37.5 times DoS amplifier.

Hope this helps.

CA-99-17 Denial-of-Service Tools

A new denial-of-service tool known as Tribe FloodNet 2K was released; a weakness in certain versions of MacOS allows intruders to use MacOS 9 as a "traffic amplifier."

CERT Advisory

37.5x traffic amplication. Wheeeeeeee.

Although that is incredibly dangerous, this guy is actually making a claim of an expected international y2k attack on the basis of two foreign port scans. hmmmm. Someone had a bit too much coffee.

Anyhow, I can't seem to find any reference of this on Bugtraq. He appears to have only informed CERT and his local network admin.

matt

Yes, this is a double standard. Let's examine why.

First, the Melissa virus is possible due to the dominance of one specific piece of software on the average users desktop. The only open source equivalent to this kind of dominance -- that I know of -- is sendmail. It is not the same for a variety of reasons, but let's continue on for the sake of discussion.

Compare the closest open source equivalent "virus" -- again, that I know of -- that happened with sendmail to the Melissa-Macro Virus. You will notice two interesting things. First, the CERT advisory for Melissa states: "This macro virus is not known to exploit any new vulnerabilities." Second, note the options they give for correction: block the mail, utilize virus scanners, and encourage users to disable Word macros. The free software solution would be to fix the problem at the source -- pun intended. In a free software environment the option to: fix the problem, is available whereas in a closed source solution it is not. You have to wait for company X to fix the problem for you, and in the mean time, get by with blocking, anti-virii programs and the like. Since this problem is not new and any user that buys Microsoft products has to wait for them to deign to fix it, it would seem that there is a powerful argument for some culpability on Microsoft's part.

There are of course the issues that other people have mentioned here: no warranty, free software is not a "product" sold by a business (let us remember companies like Red Hat make money off the service not the CD), etc. However, I think this is the central point. They have different standards because they are not analagous. You are not comparing like things.

Or to put it another way: Sure, a "thief" is responsible for his own actions. However, if I entrust the security of my home to some company, it seems quite reasonable to say that if someone steals something because that company left my door open, the company is also at fault.

For free software, you use it with the understanding that you are not entrusting anything to anyone so the same standard does not apply.

Cheers.

Its interesting to see all the discussions on slashdot about this set of vulnerabilities and the CERT Advisory. I'll try to answer some of the questions raised here.

1) What was the delay?

We try very hard to be as "correct" as possible when writing an advisory, and to put the problem in the proper scope, which sometimes means we're slower than other sources, but also usually means that we are generally pretty accurate. The original ssh vulnerability was not directly exploitable, but the CORE SDI folks found the RSAREF vul, which can be exploited through the ssh vul. In working with them, we understood the problem, and began to contact vendors who might be affected. We then discovered that the original fix as provided by CORE SDI wasn't complete, and worked with them to develop a more complete fix. Also, there were a wide variety of legal issues to discuss with our legal counsel. It takes a while to get all the ducks in a row. By far, though, the biggest chunk of time was trying to understand the whole scope of the problem -- what products might be affected, etc.

In my experience, most compromises happen well after the fix has been known for a long time anyway, so I believe that a delay to make sure we've got the facts straight is usually better than being the first one to get it wrong.

Having said that, though, I believe it is crucial for sites concerned with security to monitor sources like BugTraq and Security Focus. We don't pretend to be a replacement for sources like that.

2) What about product X?

If we have information about a particular product, its in the advisory.

3)Is CERT trying "to act like international users are not affected?"

I don't think anything in the Advisory implies that international users are not affected. We do say "sites not restricted by patent law may choose to use a non-vulnerable implementation of RSA." But that's not the same thing.

If you have other questions not addressed in the Advisory, or suggestions, comments, or criticisms about the advisories in general, you can mail them to cert@cert.org> . I'll do my best to personally respond, modulo the slashdot effect. :-)

Shawn Hernan,
Vulnerablity Handling Team Leader,
CERT/CC

Why don't you read the advisory?