CERT And Vulnerability Disclosure

Carnage4Life writes "In a radical departure from it's previous stance of security through obscurity, the Computer Emergency Response Team, CERT, has stated that it will fully disclose all vulnerabilities in software that come to it's notice 45 days after the fact whether or not companies have provided a fix. The change of policy can be found at the CERT site and there is also a story on C|net. The change is not a complete embrace of full disclosure because CERT will not release exploits as some other software security watchdogs do."

A User's Perspective on Exploits

While all of you are discussing the ideological and legal aspects of this, I think I would like to address the practical side.

Very few novice Redhat 6 users, myself included, actively monitor the security problems addressed at bugtraq or securityfocus, out of ignorance or lack of time. However, the Internet is crawling with 5kr1p+ k1dd135 who do, and they have preyed on our system. I do not appreciate the abstract, idealistic attitude of this community, the good-ol-boy mentality that if you aren't an expert administrator, you ought to be hacked by 14 year old malcontents. They used that goddamn wu_ftpd exploit on us and we had to reformat and waste another freaking day reinstalling and upgrading the only OS I've ever personally seen hacked.

Now RedHat wasn't the only distro affected by this exploit; this is truly an open-source security problem. Consumers will not latch onto Linux if it's this hard to keep secure. There are several items your community needs to address:

• DO NOT post exploits to the general public; insist that securityfocus, bugtraq, and others only allow legitimate developers to view them. Exploits are the equivalent of guns and ammo, and there is a great need for background checks!
• We need to express leadership in the open-source community to make the distros have secure default configurations, and automatically alert users of security problems, and allow them to choose to install patches. This could be integrated with policies at security sites.
• Realize the useability and security go hand in hand, and consumers, in the long run, are going to support the OS that gives them the fewest headaches.

You might not care if all the "dumb" users go away, but you know what? Then your OS won't win, you will always be stuck in nerd obscurity, and MacOSX will be the #1 unix in the world.

Re:"complete embrace of full disclosure"

Full disclosure is the right way to go... WHEN handled sensibly. You have no need for a coded exploit - if you can't write it yourself, what chance do you have to understand it? And if you don't understand it, what possible LEGITIMATE use do you have for it?

I as an admin have legitimate use for it. I'm able to run the exploit against my box, to check if I'm vulnerable. If its a proper description of the vulnerability in addition,i'll be able to check if the flaw is there at all in my version of the software.

Exploits is an easy was to check if you're vulnerable and needs a patch. Its helluva lot easier than to check if you've got the updated libs, and if the program is updated, and versionchecking everything.

Of course, its not foolproof. You may be vulnerable even if the exploit doesn't work. But, if you run redhat, and the exploit is for redhat, then .. :-)

Furthermore, you say that full disclosure is the way to go. And right afterwards, you say that exploits shouldn't be released. Sorry mac, its not full disclosure if you don't disclose everything. You seem to have misunderstood something.

For example, while MS didn't improve LanMan until l0pht released l0phtcrack, neither was anybody cracking it!

And how exaclty do you know that? When l0pht released the informatiom, security minded people were able to patch their systems, because they forced a fix to be made. If they had not publicised the information, you wouldn't know about it. You wouldn't know that you were vulnerable, and if you had a smartass cracker around, he could run circles around you without you understanding what the fsck were going on.

You seem like a troll, but are modded to 5.. I don't get it.

The number of people actually capable of discovering new holes AND who are shady enough to exploit them is so tiny that the odds are high an average user will never be affected by them. Most of these people spend all their time coding up "exploits" for skript kiddies today anyway!

And how can you be so certain about this? You really can't. What is unknown is unknown. You are doing nothing but theorizing right now.

Btw, as far as I know, slashdot has been cracked once without anyone having any idea on how it was cracked. Furthermore, rootshell.com was cracked about 1-2 years ago. I don't think they've discovered how yet. So, you are saying that the superhackers don't exist, even so, we see this kind of things.

Keep in mind that your enemies are the skript kiddiez, NOT the corporations or end users.

I seem to remember som corporations using more than a year in patching some holes. I think they are my enemies, not the scriptkiddies. And I've been cracked by scriptkiddies. If the tools weren't widely published and available, I would never've known what hit me. (maybe i wouldn't have been hit, but that i can't know).


--

"complete embrace of full disclosure"

So this isn't a "complete embrace of full disclosure" huh? What exactly do you want? Possibly CERT should crack the app or site for you and hand you the root password as proof?

Full disclosure is the right way to go... WHEN handled sensibly. You have no need for a coded exploit - if you can't write it yourself, what chance do you have to understand it? And if you don't understand it, what possible LEGITIMATE use do you have for it?

I am always irritated by people who make flip remarks like "security through obscurity is proven not to work", when the basis for their remarks is that some vendors didn't patch known vulnerabilities in the days when STO was more prevalent. In reality, the aim of information security is NOT to eliminate all security holes. The aim is to prevent legitimate users from service interruptions and abuses. It's not that difficult a distinction, guys. For example, while MS didn't improve LanMan until l0pht released l0phtcrack, neither was anybody cracking it! The theory of some full disclosure zealots is that if all vulnerabilities aren't released and coded up within 24 hours of discovery, some shadowy breed of "super hackers" out there will find it in time and exploit it. Guess what - these super hackers DON'T EXIST. The number of people actually capable of discovering new holes AND who are shady enough to exploit them is so tiny that the odds are high an average user will never be affected by them. Most of these people spend all their time coding up "exploits" for skript kiddies today anyway!

CERT has it right. Disclose the vulnerability to the vendor. Give them A LOT of time to fix it, and a lot of goodwill. Software companies can be slow on their feet - they can't address every problem that crops up in the 12 hours you give them until you announce "they haven't responded". But if the problem is not patched in that liberal amount of time (45 days seems enough to me) THEN feel free to shout from the rooftops and embarrass the suckers.

Keep in mind that your enemies are the skript kiddiez, NOT the corporations or end users. For some reason it is easy to lose sight of that fact in the world of infosec, where everybody believes they are unusually smart and the companies they correspond with unusually stubborn. I know - I work in that field and ego is a dangerous thing. Don't let it blind you to what should be your real goal - helping people improve their lives.


-konstant
Yes! We are all individuals! I'm not!

Too Much or Not Enough

Let me first say that, in general, I welcome this change to CERT policies. CERT announcements have become increasingly less relevant as the bugtraq list has grown and as the SecurityFocus team has added better tools for tracking and researching vulnerabilities. One interpretation of this change is that it represents a desperate cry for relevance by the CERT folx.

Here's the rub, though: there are some vulnerabilities that cannot be fixed in 45 days. 45 days is plenty to fix a buffer overflow in a single software package (or even a common overflow in a group of packages). It is not nearly enough to fix a protocol weakness.

An excellent example of this is the SYN Flooding attack perpetrated on PANIX in NYC years ago. Let's rewrite history and suppose that the attack was mailed to CERT first (and not used in public first). CERT then would mail the details of the attack to the security contacts of every operating system at the time (since the idea of SYN queue resource exhaustion was viable on every IP stack at the time). And then those vendors and maintainers would do what?

Well, fix it, of course, right? The problem is that the fix isn't obvious (it still isn't obvious, years after the attack). You can reduce the SYN queue and time things out, but then you can get in trouble with timing out connections from viable end-hosts. You can use Dan Bernstein's SYN cookies (although it took someone like Dan to come up with these--they are entirely inobvious to the average protocol stack maintainer).

The problem is that the TCP protocol didn't envisage the presence of an entry on the SYN queue (SYN received, SYN+ACK sent, waiting for SYN+ACK to connect) as a resource that needed to be managed carefully. As a result, there's no easy way, in the protocol, to avoid resource exhaustion for this correctly in all cases.

In situations like these, 45 days is woefully inadequate. It's not clear if a year is adequate. I like the idea of forcing vendors to respond promptly and get this stuff fixed. I worry about the trend of using the innocents as cannon fodder (as described by Marcus Ranum, whose homepage at http://www.clark.net/pub/mjr appears to have disappeared. anyone know where it is now?).

Anyway, just wanted to point out that this is not as simple as the shrill FULL DISCLOSURE!!!!! folx are making it out to be.

Re:"complete embrace of full disclosure"

Your apparent "super hackers" do exist. It is solely because they are not script kiddies that they don't show up on your radar. Dude, when a sploit is released it has been floating around the underground for at least six months. In a moment of weakness, the people who own thousands of boxen a year have picked over their list of sploits for the oldest and most common ones and handed over a particularly useless one for some zero-day warez that some pup on irc says he's got. Pup gives sploit to pup and eventually it ends up in the hands of a "white hat" who goes and posts it on bugtraq. This happens a LOT. The problem is that admins don't beleive that there is a bug unless they have been cracked or can prove it to their peers by cracking themselves. Why? Well, getting the source, applying a patch, recompiling, reinstalling, testing, dealing with someone bitching that you broke something because you touched a config file (or an install script did)... etc, is a LOT of trouble and your admin is not gunna do that unless there's a damn good reason. So either make your patches easier (yes, I know binary patches are infeasible) or release the sploit and the patch as fast as possible so these "super hackers" and these "script kiddies" don't get on our boxes.

Re:A User's Perspective on Exploits

Very few novice Redhat 6 users, myself included, actively monitor the security problems addressed at bugtraq or securityfocus, out of ignorance or lack of time.

Or, as it was for me, SuSE 5.1 or 5.2 (don't remember which one) that had the qpopper vulnerability. I was cracked, and afterwards I *love* the resources secfocus, rootshell, packetstorm and so forth has provided for me.

wu-ftpd exploit

If an open source program has a security fix , people will run a diff, and find the bug. If you've seen the exploit floating around, they are mostly written by kiddies / friends of kiddies. People that put "DO not distribute" in the top of the comments of the code. The code is of course circulated among 'the eLiTe uND3Rgr0und' - and after a relative short time, it gets onto kiddie-hands, via irc or whatever. They don't need bugtraq for this.

DO NOT post exploits to the general public; insist that securityfocus, bugtraq, and others only allow legitimate developers to view them. Exploits are the equivalent of guns and ammo, and there is a great need for background checks!

No way. I insist on being able to review the exploits, review the vulnerabilities and so forth. I want to patch my holes, but I want that they're there before I go ahead and patch. Also, the exploits puts a fire in the asses of the developers. It makes sure that they do produce a fix, and fast. I, as a security admin for my company want those fixes asap. I don't want to live months without them because there is a bunch of lazy admins in the world that should "be protected". No thank you..

We need to express leadership in the open-source community to make the distros have secure default configurations,

Agreed. Nothing but sshd and auth should be started by default. Everything else than that should have to be specified explicitly, imho.

and automatically alert users of security problems,

No way. NOOO way. I don't want the distro to automagically check for anything. That should be made an OPTION to ENABLE, not something that should be forced upon people. NO way..

*shudder*

Realize the useability and security go hand in hand, and consumers, in the long run, are going to support the OS that gives them the fewest headaches

Yup, and therefore distros should be shipped without many daemons enabled by default. The full disclosure policy is not affected by this.


--

CERT is useless nowadays

I've been working for a Linux security company for the past few months, and was pretty much on top of security before that. I can honestly tell you that to me CERT looks like a joke.

1) CERT is way behind anybody else

They issued an advisory about wu-ftpd and rpc.statd in July or August when exploits, and proof of concepts, were on bugtraq in late May.

2) CERT has turned into a laughing stock.

The funniest thing I think I've seen in a long time is Jamie Rishaw's mock advisory about the Sony Aibo [securityfocus.com]. This is just a slap in the face of CERT.

I'm not mocking the concept... an entity such as CERT serves a very big purpose. Being associated with the SEI one would think a much more active one. However since white hats are just as skilled as the black hats it doesn't take somebody at the SEI to write an exploit. By the time they do, somebody has already posted it to bugtraq or it's already out in the wild.

Just my $.02.

not REALLY...

They've set up a 45-days after the fact disclosure policy, but they also put a bunch of loopholes in there allowing for later (or earlier) disclosure based on "negotiations" with the affected vendor and also the severity and sensitivity of the hole. So essentially what it says is "we'll disclose holes 45 days after they are reported, unless anyone gives a good reason why not, where "good reason" is solely up to our discretion." Not really very cut-and-dry, when you get down to it.

Exploits not needed

I don't see as the exploits are needed. Sure, they should release them to those responsible for fixing the software, but there's no need to release them to the general public (unless the general public is who is responsible for fixing the software, as in Linux).

Besides, it shouldn't take anyone more than a day or two to write an exploit, anyway.

Security through Obscurity

I think in general when bugs are first found, there should be a small window of time given to the developers to fix the bug. There is no need to publish a bug only to let every script kiddy out there crack your box. 45 days is pushing it way too far. Sure it's good that CERT is going to release more information, but I think that a more realistic set of time is three days. I think I read somewhere in which someone from OpenBSD [openbsd.org] stated that most security bugs can be fixed within an hour if the bug is known. Three days would be plenty of time. I know that some open-source zealots might think that all bugs should be reported immediately, but in truth this should only be the case when it is a true community project such as the linux kernel. Just because something is put under the GPL, does not mean that it doesn't have a main set of centralized developers.

Re:Security through Obscurity

I might buy the "within an hour" statement if the disclosure report fully described the problem and a fix.

Three days is short for a large organization. Somebody in charge needs to be convinced of the problem (managers do have many responsibilities and despite what we might hope to believe, fixing vulnerabilities cannot always be worked into a tight schedule). Then a competent developer needs to be allocated to do the work.

Most organizations will have to do some sort of quality assurance/testing on all changes to the software. It's irresponsible to not do this. That's another group, another manager, another several days. If you're close to an already-scheduled release date, the fix will probably be bundled in there. It costs A LOT of money to create new installation media, to mail the fixes to customers or to even go through (yet another) group to provide fixes on an external FTP server. In all, 45 days could be quite short!

Opinion [flamebait] section - it seems that in an open source environment, the testing sometimes isn't quite as disciplined (offset by more frequent releases). An acceptable fix may already exist in the disclosure report because somebody other than the programmer who applies the main source tree fix has been able to think about the problem. This also reduces the time to provide an official fix for this sort of project.

Re:"complete embrace of full disclosure"

For example, while MS didn't improve LanMan until l0pht released l0phtcrack, neither was anybody cracking it! ... CERT has it right. Disclose the vulnerability to the vendor. Give them A LOT of time to fix it, and a lot of goodwill.

It's funny that you mention Microsoft during your argument about giving vendors time to fix things. Microsoft won't even fix widely known vulnerabilities, much less things that are pointed out to them and kept private. You're talking about the company that maintained for DAYS after ILOVEYOU destroyed data everywhere that there was absolutely no problem with the way Outlook worked. They had been notified of this problem MONTHS before ILOVEYOU hit, and chose to do nothing. And then after it hit, they still chose to do nothing for a few days.

Keep in mind that your enemies are the skript kiddiez, NOT the corporations or end users.

Hmm, none of my friends have been sued by script kiddiez, or been threatened by their lawyers. I'm not saying I'm in love with script kiddiez, but the corporations are capable of doing a lot more damage.

Re:Exploits not needed

being against the disclosure of exploits is being against a form of open source, isn't it?

I'm not trying to be a smartaleck; it seems like an interesting question to me.

Re:Exploits not needed

there's no need to release them to the general public

I disagree. The public at large must have some way to test to see if their systems are vulnerable to attack. The easiest way to do this is by running the exploit to see if you are safe or not. This is especially true for systems that aren't too popular today as their might not even be a vendor for the product any more (When was the last time mips hardware company issued a bug fix).

Developers of similar code also have a keen interest in the exploits. As do writers of secure code. When the exploits are analized, often they relveal areas of exploration which heretofore might have been thought completely safe, or whose danger was unknown. Executable stacks and printf format strings come to mind here (a hardware problem and software sloppiness).

Besides, it is just against the freedoms that this country was founded upon to restrict speech.

Warner Losh
FreeBSD Security Officer

They should just make it illegal.

That's right folks. It should be illegal to post cracking tools and exploits. Why? Well because it's damaging to eCommerce because crackers will use it. Besides most of this stuff could be considered illegal because of reverse engineering which is indeed banned under the DMCA which, before you start bitching, is a morally just and much needed law to protect large corporations. So just shutup and eat at McDonald's and wear Nike shoes, and drink Coca-cola, and listen to Britney Spears, Nsync, or whatever other trendy music the RIAA wants you to listen to. Remeber, you don't have the right to choose what you do with your so called property or even your body so just live with it.

Full Disclosure Good

Knowing the detail of a vulnerability enables real risk assessment. How much of your systems are at risk? What's the value of what's at risk. It's impossible to figure this out without some notion of what the vulnerability is.
Security Admin: "We need to immediately upgrade all our servers to fix a serious security bug?"
Executive With Money: "What's our exposure if we don't?"
Security Admin: "I don't know. CERT just says to fix the bug."
Executive With Money: "And we are supposed to pull people off our Vitally Important Marketing Strategy Project to immediately fix a security problem, when we don't know what the problem is and what it costs us?"

BugTraq has it right

It's not that BugTraq has a "policy" of releasing exploits. BugTraq releases what gets submitted, through moderation. The people who submit each report or exploit decide how they want to handle it, and this is how it should be. Freedom of speech means if I have something to say, I can say it.

A lot of the "early" reports are motivated by the desire for credit for finding the bugs. It might seem petty and small minded, but so what? If that's your motivation for putting in useful work and publishing, who are we to criticize: go to it. If the companies/developers that have the security hole in their products enhance the glory for the discoverer, they might get more cooperation.

But early reports with exploits really light a fire under the fixers and create more awareness in the vicitms and potential victims, so in the long run it's a good thing, IMHO. But, MHO opinion doesn't matter: as I said, it's all about free speech.

CERT's Change in Policy

This change is needed. There have been too many cases of vendors and users burying their heads in the sand about vulnerabilities. In practical terms, the threat usually exploits software bugs. not weaknesses of existing security mechanisms. The lack of vendor liability for errors and omissions in their software has meant that security-related bugs have been fixed only grudgingly. The UCITA has been a step backward; perhaps this will be a step forward.

CERT is no longer an acronym

CERT is no longer the "Computer Emergency Response Team."

According to their FAQ [cert.org]:

CERT" does not stand for anything. Rather, it is a registered service mark of Carnegie Mellon University.

Its history, however, is that the present CERT® Coordination Center grew from a small computer emergency response team formed at the SEI by the Defense
Advanced Research Projects Agency (DARPA) in 1988. The small team grew quickly and expanded its activities. As our work evolved, so did our name.

When you refer to us in writing, it's OK to refer to us as the CERT® Coordination Center or the CERT/CC. Although you should not expand "CERT" into an acronym, it's appropriate to note in your text that we were originally the computer emergency response team.

Sounds good to me...

First, if there's a hole in a product that has been found, the company has been notified, and nothing has been done about it for 45 days, I'm sure someone has and is using an exploit by then.

Second, by publishing the details, and saying "hey, you knew about this for 45 days; don't you think your customers should know?", you're encouraging software companies to get their act together.

If left to themselves, no, they won't fix bugs out of the goodness of their hearts. The only people this sort of thing affects are the consumers; big businesses have firewalls and probably use better, more expensive products internally, wherever possible.

I think it's pretty sad that it has to be this way, but that's the way it is. Taking a laissez-faire attitude to big software companies doesn't seem to work, because there is too much potential for abuse.

I also don't like the whole "unauthorized negative reviews aren't allowed" business. Who cares about freedom of speech, eh? We can have unauthorized biographies of Bill Gates, and not unauthorized reviews of Front Page. Whatever you say, guys. For example, I did a lot of benchmarking between DOS and Linux's DOSEmu; my findings at the time were that DOSEmu was about 3% slower in raw CPU than actual native DOS (testing using the DOS 32-bit BYTEMarks), but that defragging a native DOS partition was *much* faster under DOSEmu, due to Linux's cache subsystem. Those are the facts; why should they be censored just because someone else isn't happy about it?
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].