Saving Bugtraq

In July of 2019, many noticed that the Bugtraq mail list stopped having posts approved, including Art Manion at CERT. Since there are many other outlets for vulnerability disclosure, such as the Full-Disclosure mail list, Packetstorm, Exploit Database, and increasingly on GitHub, it didn’t receive much attention. It wasn’t like the days when the list was created when there were very few places to disclose that would be seen by other security professionals and hackers. Despite that, the list has a long history and many came up in their respective scene recognizing what it represented.

The last post to the list, as of now, is dated July 26, 2019. In December of 2019 I tweeted to SecurityFocus and Symantec, its parent company at the time, asking if they had killed the list. I received no reply. Months passed and I got curious again, so I reached out to both companies via email trying to ascertain the status of the list. Two of the three public addresses I found on their website immediately bounced as undeliverable while the third went unanswered. I shared that update with Twitter as well in May.

After the last Tweet, someone reached out and offered to help me figure out the disposition of Bugtraq. We started chatting in May and they went to work. You may think this would be a relatively simple task and it would be for smaller companies. However, remember that while Symantec acquired SecurityFocus back in 2002, Broadcom acquired Symantec in November, 2019, and then Accenture acquired Symantec from Broadcom in April, 2020. You can imagine the amount of chaos going on in that organization and the layers of management along with the vast number of departments.

During that initial chat, I said “a lot of people don’t want to see the Bugtraq list just vanish given its history. We’re hoping Broadcom starts it back up or will pass it off to someone else in the industry to run.” That same day my contact figured out the general org structure involved and where to start asking around. A couple weeks later they reported back that it fell under an Accenture business unit, that there was discussion going as to the disposition, and that the pandemic was slowing things down. Jump to August, 2020, and they reported back that they were still working on it and that “breathing life into [the list] might be possible”.

In August, before they checked in with that update, I had decided to update the Wikipedia entry for the Bugtraq list as it was pretty sparse originally. I added a significant amount to better document the history around the list as well as some highlights like some controversies. My contact said those updates were actually helpful in gaining traction which I thought was cool. Nay-sayers about Wikipedia take notes! A few months passed and my contact reached back out in November with an update saying “I have a bit of an uphill battle here”. Giving it back to the community was being discussed, but we both immediately realized the next challenge if that happened; who would run it. No chance in hell I would. I said that if they posted to the list asking, I am sure they would get many volunteers. Vetting those and figuring out a viable long-term option might be tricky though.

In January, they messaged again saying “I have a few battle scars and ultimately lost the fight for [it]”. That was almost at the same time that I read the January 15 shutdown message that was posted to the list. I was one of several that Tweeted about it, lamenting about the loss.

I sent another message to my contact thanking them for fighting for it, and that I was happy a clear message had been sent finishing off the list. There was some concern about the possible fallout for the team, and that they “still remember hiring folks who said their goal was to be referenced on the Bugtraq list.” That was a great reminder that today claiming CVEs is some misguided notion of skill while back then, getting a post to Bugtraq approved meant a lot.

We continued the conversation on January 16 and they cryptically told me “there may be hope yet”, citing a ZDnet article that apparently got the attention of some executives. I joked with them saying “that would be an epic unintentional troll, if it got resurrected weeks later” to which they agreed. The list admins allowed one response to the post through that day, a shout-out from the old-school hackers of UPT. A day after that, the list admin sent a mail titled “On Second Thought…” stating that based on feedback, they have “decided to keep the Bugtraq list running. We’ll be working in the coming weeks to ensure that it can remain a valuable asset to the community for years to come.” Accenture followed that up with a more lengthy blog about the list revival.

Here we are months later and I thought back to part of our conversation in which I told them I “wish people knew just how long you had to fight on this and how much of a hurdle it was just to post the list.” They said it was probably a story best told over a beer, or something harder, suggesting I probably don’t know the half of what they went through to get all of this rolling. So I wrote this blog with the hope that they said it was ok to post, to share the story. InfoSec is full of heroes that work behind the scenes, fighting the good fight, and trying to make things a bit better. They deserve more recognition than they get. This is just one example of that. So thank you, so much, for your work in helping keep the historic list alive.

Your yearly reminder to post to Full-Disclosure, not Bugtraq

[This was originally published on the OSVDB blog.]

[10/29/2020 Update: As of February 24, SecurityFocus has stopped moderating posts to the Bugtraq mail list without explanation or warning. This is apparently related to Broadcom acquiring Symantec, the owner of SecurityFocus.]

This has been a long-recognized and proven thing, but every year we run into more glaring examples. SecurityFocus, who runs the BID database, which is part of Symantec’s DeepSight offering, routinely uses submissions to the Bugtraq mail list to seed their commercial database, sometimes days before approving the post. This means subscribers who use Bugtraq as one of many sources of ‘real-time’ vulnerability intelligence routinely get the short end of the stick. Full-Disclosure, managed by Fyodor and team, do not have that commercial interest in the content of the posts to the FD. Their average turnaround time seems to be considerably better in approving posts. So please, for the industry’s sake, post to Full-Disclosure and stop supporting Bugtraq.

Today’s example: A new CVE popped up in various places. Google showed the first hit to be the BID Database:

EMC only posts their advisories to the Bugtraq list, so we checked there first, since that would be the provenance:

There are EMC advisories visible, but not the one with CVE-2017-4985. Checking again today:

SecurityFocus delayed the post by three days while it was in their database.

Missing Perspective on the Closure of the Full-Disclosure Mail List

[This was originally published on the OSVDB blog.]

This morning I woke to the news that the Full-Disclosure mail list was closing its doors. Assuming this is not a hoax (dangerously close to April 1st) and not spoofed mail that somehow got through, there seems to be perspective missing on the importance of this event. Via Facebook posts and Twitter I see casual disappointment, insults that the list was low signal to noise, and that many had stopped reading it a while back. I don’t begrudge the last comment one bit. The list has certainly had its share of noise, but that is the price we pay as a community and industry for having a better source for vulnerability disclosure. Speaking to the point of mail lists specifically, there were three lists that facilitated this: Bugtraq, Full-Disclosure, and Open Source Security (OSS). Bugtraq has been around the longest and is the only alternative to Full-Disclosure really (remember that VulnWatch didn’t last, and was ultimately low traffic). OSS is a list that caters to open source software and does not traffic in commercial software. A majority of the posts come from open source vendors (e.g. Linux distributions), the software’s maintainer, etc. It is used as much for disclosure as coordination between vendors and getting a CVE assigned.

One of the first things that should be said is a sincere “thank you” to John Cartwright for running the list so long. For those of you who have not moderated a list, especially a high-traffic list, it is no picnic. The amount of spam alone makes list moderation a pain in the ass. Add to that the fake exploits, discussions that devolve into insults, and topics that are on the fringe of the list’s purpose. Trying to sort out which should be allowed becomes more difficult than you would think. More importantly, he has done it in a timely manner for so long. Read the bold part again, because that is absolutely critical here. When vulnerability information goes out, it is important that it goes out to everyone equally. Many mails sent to Bugtraq and Full-Disclosure are also sent to other parties at the same time. For example, every day we get up to a dozen mails to the OSVDB Moderators with new vulnerability information, and those lists and other sources (e.g. Exploit-DB, OffSec, 1337day) are in the CC. If you use one or a few of those places as your primary source for vulnerability intelligence, you want that information as fast as anyone else. A mail sent on Friday afternoon may hit just one of them, before appearing two days later on the rest. This is due to the sites being run with varying frequency, work schedules, and dedication. Cartwright’s quick moderation made sure those mails went out quickly, often at all hours of the day and over weekends.

While many vulnerability disclosers will send to multiple sources, you cannot assume that every disclosure will hit every source. Some of these sites specialize in a type of vulnerability (e.g. web-based), while some accept most but ignore a subset (e.g. some of the more academic disclosures). Further, not every discloser sends to all these sources. Many will send to a single mail list (e.g. Bugtraq or FD), or to both of them. This is where the problem arises. For many of the people still posting to the two big disclosure lists, they are losing out on the list that was basically guaranteed to post their work. Make no mistake, that isn’t the case for both lists.

This goes back to why Full-Disclosure was created in the first place (July 11, 2002). This was days before Symantec announced they were acquiring SecurityFocus (July 17, 2002). That was not a coincidence. While I can’t put a finger on when BugTraq changed for the worse exactly, I can assure you it has. Back in 2003, security researchers were noticing curious delays in their information being posted. One company challenged SecurityFocus/Bugtraq publicly, forcing them to defend themselves.

“The problem with SecurityFocus is not that they moderate the lists, but the fact that they deliberately delay and partially censor the information,” said Thomas Kristensen, CTO of Secunia, based in Copenhagen, Denmark. “Since they were acquired by Symantec they changed their policy regarding BugTraq. Before they used to post everything to everybody at the same time. Now they protect the interests of Symantec, delay information and inform their customers in advance.” Wong says there is no truth to these accusations. “The early warnings that our DeepSight customers get come from places like BugTraq and events and incidents that we monitor,” Wong said. “We dont give those alerts [from BugTraq] to our customers any sooner than anyone else gets them.”

Unfortunately for our community, Mr. Wong is absolutely incorrect. I have witnessed this behavior first hand several times over the years, as have others. From a series of mails in 2006:

* mudge (mudge @ uidzero org) [060120 20:04]:
Actually, this advisory is missing some important information. bugtraq engaged in this prior to the “buy out”. Security Focus engaged in this practice as well where there were some advisories that would go out only to the Security Focus paid private list and not be forwarded to the public list to which they were posted.

On Fri, 20 Jan 2006, H D Moore wrote:
FWIW, I have noticed that a few of my own BT posts will not reach my mailbox until they have already been added to the securityfocus.com BID database. It could be my subscriber position in the delivery queue, but it does seem suspicious sometimes. Could just be paranoia, but the list behavior/delivery delays definitely contribute to it.

In each case, moderators of Bugtraq vehemently denied the allegations. In one case, Al Huger (with Symantec at the time) reminded everyone that the combined lists of SecurityFocus were delivering over 7 million mails a day. That alone can cause issues in delivery of course. On the other hand, Symantec surely has the resources to ensure they run a set of mail servers that can churn out mail in such volume to ensure prompt delivery. Jump to more recently and you can still see incredible delay that has nothing to do with delivery issues. For example, RBS posted an advisory simultaneously to both Bugtraq and Full-Disclosure. Notice that the mail was posted on Sep 10 for Full-Disclosure and Sep 19 for Bugtraq. A nine day delay in moderating vulnerability information is not acceptable in today’s landscape of threats and bad actors. Regardless of intent, such delays simply don’t cut it.

In addition to the Bugtraq moderators having such delays, they will sometimes reject a post for trivial reasons such as “using a real IP address” in an example (one time using the vendor’s IP, another time using a public IP I control). They rejected those posts, while frequently allowing “target.com” in disclosures which is a real company.

With the death of Full-Disclosure, Bugtraq is now our primary source of vulnerability disclosure in the scope of mail lists, and only source for vulnerabilities in commercial software (out of scope for OSS). To those who argue that people “use mail a lot less now”, I suggest you look at the volume of Bugtraq, Full-Disclosure, and OSS. That is a considerable amount of disclosures made through that mechanism. Another mindset is that disclosing vulnerabilities can be done with a Tweet using a hash tag and a link to pastebin or other hosting site. To this I can quickly say that you have never run a VDB (and try finding a full set of your original l0pht or @stake advisories, many have largely vanished). Pastebin dumps are routinely removed. Researcher blogs, even hosted on free services such as WordPress and Blogger, disappear routinely. Worse, vendors that host advisories in their own products will sometimes remove their own historical advisories. The “Tweet + link” method simply does not cut it unless you want vulnerability provenance to vanish in large amounts. It is bad enough that VDBs have to rely on the Internet Archive so often (speaking of, donate to them!), but forcing us to set up a system to mirror all original disclosures is a burden. Last, for those who argue that nothing good is posted to Full-Disclosure, Lucian Constantin points out a couple good examples to counter the argument in his article on the list closing.

Instead, mail lists provide an open distributed method for releasing information. As you can see, these lists are typically mirrored on multiple sites as well as personal collections of incoming email. It is considerably easier and safer to use such a method for vulnerability disclosures going forward. In my eyes, and the eyes of others that truly appreciate what Full-Disclosure has done, the loss of that list is devastating in the short term. Not only will it introduce a small amount of bias in vulnerability aggregation, it will take time to recover. Even if someone else picks up the torch under the same name, or starts a new list to replace it, it will take time for people to transition to the new list.

To conclude, I would also ask that John Cartwright practice full disclosure himself. Shuttering the list is one thing, but blaming the action on an unnamed person with no real details isn’t what the spirit of the list is about. Give us details in a concise and factual manner, so that the industry can better understand what you are facing and what they may be getting into should they opt to run such a list.

“Threat Intelligence”, not always that intelligent.

I’ve been in the security arena for some time now, like many of my friends and colleagues. For over a decade, we have been presented with several vendors that deliver yearly reports summarizing various attributes of the industry: vulnerabilities, hack attacks, spam, malware, breaches, and more. They are typically delivered in summaries that can be read by any level of an organization. More recently, they center around ‘infographics‘ that attempt to convey the major points in an aesthetic fashion.

Most reports are released with a lot of fanfare; news articles that praise the report, hem and haw over the findings, and tell users things are bad. What we rarely see is any establishment, news or otherwise, challenge the data. The few that do are typically lost in the mass of blogs and are given as much scrutiny as the articles they debunk. Even when data is out there to quickly refute such a report, the people seeking to do so are few and far between; even when it is their job to do so.

The reason? Security companies, professionals, and journalists are complacent. They are happy to get the numbers that help them. For some, it sells copy. For others, it gets security budget. Since it helps them, their motivation to question or challenge the data goes away. They never realize that their “threat intelligence” source is stale and serving up bad data.

All of this came up again with today’s release of the Symantec Internet Security Threat Report (ISTR) [Full report – PDF]. Note that I am an officer of the Open Security Foundation (OSF), and we track two of the many general data points that Symantec does. We run a vulnerability database, and we run a database that tracks breaches. Symantec has previously used OSF breach data, but recently stopped after being informed that it was not acceptable to do so commercially without a license. I believe this is the first report that uses their own. And it shows. That said, I am only going to focus on vulnerability data, as that is my real area of interest and where I spend a majority of waking hours.

In addition, Symantec maintains one of the world’s most comprehensive vulnerability databases, currently consisting of more than 51,644 recorded vulnerabilities (spanning more than two decades) from over 16,687 vendors representing over 43,391 products.

Given the number of vulnerability databases (VDBs) out there, at least ones that could be considered sizable by any measure, this is technically true. However, the rest of the quoted material reminds us that they are not even close to comprehensive, and their numbers are in line with specialty databases that focus on a specific purpose or type of information. According to the report, they cataloged 6253 vulnerabilities in 2010, 4989 in 2011, and 5291 in 2012. To put that into perspective, that is 2877 less than IBM/ISS X-Force, 4485 less than Secunia (note: their abstraction will result in duplicates and a higher count to some degree), and 1289 less than CVE/NVD, which is the “no child left behind” of VDBs. Seriously, Symantec isn’t even keeping a 100% mapping to CVE, and they call their database “comprehensive”. Symantec’s 5291 vulnerabilities in 2012 is approximately 58% of the vulnerabilities cataloged by OSVDB. As one project moderator said, a generous professor might even round that to a D-.

Looking further, Symantec’s report says they cataloged 14 ‘zero day’ vulnerabilities in 2010, 8 in 2011, and 14 in 2012. In this context, ‘zero day’ means “A zero-day vulnerability is one that is reported to have been exploited in the wild before the vulnerability is public knowledge and prior to a patch being publicly available.” This is basically the same definition OSVDB uses for our “Discovered in the Wild” flag. However, our numbers differ from theirs: 39 in 2010, 31 in 2011, and 25 in 2012. Note that tracking this specific statistic is very difficult for any VDB. I can say with certainty that we have not flagged all of the vulnerabilities that fit this bill, but we have made a considerable effort to do so based on the information available.

Several reports including Symantec, IBM / ISS X-Force, and others have recently started highlighting statistics surrounding the vulnerabilities in web browsers. This probably seems simple to most people, even many security professionals. I can assure you, that is not the case. As a recent example, Carsten Eiram of Risk Based Security (a sponsor of OSF / OSVDB) has spent the last three months doing extensive analysis and reworking of WebKit vulnerabilities. WebKit serves as the central rendering engine for several browsers including Google Chrome, Apple Safari, RIM / BlackBerry, and soon Opera. This generally means that any vulnerability in WebKit will likely affect the four browsers mentioned, and more. In the real world, due to vendors not playing well with others, we see Apple release vague vulnerabilities attributed to WebKit months after Google Chrome does the same. Carsten’s digging and analysis has found a considerable amount of duplicate CVE assignments as a result. In addition, he has found many additional vulnerabilities that were either silently patched by vendors, or remain unpatched currently, simply by using the same resources as the developers. With this in mind, the Symantec statistics are more revealing:

symantec-browser-vulns

In 2012, they show 38 Apple Safari, 30 Google Chrome, 21 Mozilla Firefox, 7 Microsoft IE, and 4 Opera vulnerabilities. Given that OSVDB has cataloged 219 vulnerabilities in WebKit in 2012 alone, that means the Symantec statistics are worthless. Those 219 vulnerabilities largely affect both Chrome and Safari, as well as other browsers. Even if we switch to look at vulnerabilities specific to Google Chrome we see 221, and for Apple Safari we see 66 distinct vulnerabilities. This kind of oversight in browser statistics is, for lack of better words, amateur hour.

[Update 6/7/2013 – As pointed out in a comment below, I misread this as # of vulns rather than percentage. I am leaving the paragraph above in full for posterity. However, please note that all of my comments would also affect their percentages as well. I certainly screwed this part up, but their stats are still wrong. =)]

Another hot topic the last two years are vulnerabilities in SCADA (Supervisory Control and Data Acquisition) systems. These are the systems that run vital parts of the world’s infrastructure, including electric, gas, sewage, and more. According to the Symantec report:

In 2012, there were 85 public SCADA (Supervisory Control and Data Acquisition) vulnerabilities, a massive decrease over the 129 vulnerabilities in 2011.

These statistics, if used for any guidance in SCADA facilities, should be criminal. OSVDB cataloged 167 SCADA vulnerabilities in 2011, and saw it jump to 211 in 2012. We’ve already cataloged 66 SCADA vulnerabilities in 2013, due to increased diligence in monitoring SCADA vendors for reports that may not make their way to ICS-CERT.

Toward the end of the report, in their “Looking Ahead” section, they give some general predictions of what is to come. “More State-sponsored Cyber Attacks”, “Social Media Will Be a Major Security Battleground”, “Sophisticated Attack Techniques Trickle Down”, “Attacks Against Cloud Providers Will Increase”, “Websites Will Become More Dangerous”, and “Increasingly Vicious Malware”. These are hardly ground-breaking or interesting, as they have all been the status quo for many years. What I find interesting is that the statistics they offer show a drop in vulnerabilities, both overall and in specific sectors such as SCADA. Symantec’s numbers don’t support their predictions very well.

I think it is fair to say that Symantec has lost sight of the real value of such reports. Instead, I envision Symantec planning meetings about the graphics, presentation style, and narrative they’re presenting. Vulnerability statistics are not easy; in fact, they are exceedingly difficult to get right. You would think that a company with the resources and longevity of Symantec could figure that out. Unfortunately, the report has become the focus, not the reliable data that should drive it.

VDBs Devolving?

[This was originally published on the OSVDB blog.]

I’m big on Vulnerability Database (VDB) evolution. I tend to harp on them for not adding features, not making the data more accessible and generally doing the exact same thing they did ten years ago. While the target of my ire is typically functionality or usability, today it is about a little more.

Last night I wanted to check for details on a CVE entry that was rather vague and had a single reference to BID. This is fairly common in the VDB world as one database will add an entry and not provide a link to the source of the data (Secunia and BID primarily). As luck would have it, BID was down. Almost twelve hours later and their VDB is still down. What annoys me is that while they aren’t delivering vulnerability information, they sure are delivering advertisements. Why can’t VDBs get the same dedication and resources that ad farms get?

Next, I wanted to find out if the other VDBs created an entry for the latest OpenBSD flap yet, so I went to X-force which is a pretty reliable database. Much to my dismay, it appears that the ‘advanced’ search is now gone. While it wasn’t extremely powerful, it let you do some basic sorting that was immensely helpful in finding what you need. I have mail out to them asking for confirmation that it is indeed gone versus a web geek error. I certainly hope it is the latter…

Update: Over 24 hours later, the BID database is finally available again. ISS has not replied to at least two mails from VDB managers asking about the missing advanced search feature.

Who’s to blame? The hazard of “0-day”.

[This was originally published on the OSVDB blog.]

This blog entry is probably worth many pages of ranting, examining and dissecting the anatomy of a 0-day panic and the resulting fallout. Since this tends to happen more often than some of us care to stomach, I’ll touch on the major points and be liberal in pointing fingers. If you receive the “wag of my finger“, stop being part of the problem and wise up.

I blinked and missed someone disclosing that there was a dreaded 0-day vulnerability in Adobe Flash Player and that it was a big threat. Apparently Symantec noticed that evil Chinese sites were exploiting Flash and the current 9.0.124.0 could be successfully exploited. When pressed for details, Symantec backtracked and said that they were wrong and it appeared to be the same exploit as previously disclosed by Mark Dowd (CVE-2007-0071). Bad Symantec, poor research.

To make matters worse, Symantec then further claimed that even though it was an old issue, the “in-the-wild exploit was effective against stand-alone versions of Flash Player 9.0.124.0” and that not all versions had been patched correctly. Way to save face Ben Greenbaum of Symantec!! Oh wait, today he changed his mind and said that Symantec’s claims were based on erroneous conclusions and that the behavior of Flash on Linux they were observing was indeed intended by Adobe and not proof it was vulnerable. To make matters worse, Symantec researchers downloaded the “latest” Flash and found it “vulnerable”, which lead to their sky-is-falling panic. Shortly after, they realized that they didn’t download all of the security patches and had been exploiting a known vulnerable version of Flash. Oops?

Two rounds of hype-driven 0-day threat warnings, and no real new threat. Whew, hopefully Symantec raised their THREATCON to blood red or whatever is appropriate for such 0-day threats. You do monitor that don’t you?

This fiasco lead many news outlets and vendors to issue warnings about the new 0-day threat. Secunia, SecurityFocus/BID, SecurityTracker, CERT, and FrSIRT all released new warnings and created entries in their respective databases as a result. In the VDB world, this is a royal pain-in-the-ass to deal with. Secunia ‘revoked’ their entry, BID ‘retired’ their entry, SecurityTracker flaged theirs ‘duplicate entry’, FrSIRT ‘revoked’ their entry and CERT still has it listed.

Fortunately for OSVDB, we were a few hours behind the rest and noticed the discrepancies and waited for more information. Unfortunately, the rest of the world, including ALL of the VDBs and news outlets listed above (and others) failed miserably in using common sense and a government funded resource to better prevent this kind of problem. As of this posting, Secunia, BID, SecurityTracker, FrSIRT, CERT, Dancho, ComputerWorld and eWeek still don’t link to the CVE ID for the vulnerability. Only Adobe’s updated blog entry actually references CVE-2007-0071 (but doesn’t link to it). Secunia links to a previous ID that has seven CVEs associated with it. The original CVE was assigned 2007-01-04 and published around 2008-04-08, a month and a half prior to this mess.

VDBs, shame on you for adding to the confusion. Symantec, shame on you for crying 0-day when your own engineers screwed up badly. Shame on everyone for not clearing it up fully by linking to the correct CVE entry or their own previous entries.

Before any of you receiving a “wave of the finger” bitch, consider the real world impact of your actions. In this case, only 12 MILLION people ended up seeing a vague warning when they loaded their favorite game. Blizzard included the correct fix information which was the same as a month or more before, but the sudden ‘security alert’ (that is extremely rare) only prompted their customers to wonder, possibly panic and definitely kill some demons as a result.

Vulnerability Research In Numbers

[This was originally published on the OSVDB blog.]

I’m so far behind in my daily routine and missed Thomas Ptacek’s post on Vuln Research In Numbers. Fortunately, Dave Aitel referenced the blog entry which prompted me to check it out. I so desperately want Ptacek to run his numbers against a complete OSVDB data set, but alas, I know that we do not have a complete data set for 2004. Symantec’s BID database has some problems with consistency, citing sources (aka provenance) and missing vulnerabilities (which plagues most VDBs to one degree or another). In my mind, OSVDB tends to be more complete than most VDBs and maintains a creditee field, but due to a lack of volunteers we just don’t have enough entries public for him to do the same generation of statistics. Some day maybe! Until then, this is a very neat post with a different slant.

No Exception for Symantec

[This was originally published on the OSVDB blog.]

Symantec posted a message to Bugtraq earlier this month announcing the availability of a new advisory. The advisory presumably covers a vulnerability or issue in Symantec On-Demand Protection. If you are reading this blog entry a year from now, that is all you may find on it. Yes, even in this day and age, not everything is archived in Google cache or archive.org! In December of 2000, Elias Levy (moderator of Bugtraq at the time) said that such posts were not acceptable because security company web sites had a habit of disappearing, leaving no trace of the information behind. Years later, Symantec bought SecurityFocus (who hosts/moderates the Bugtraq mail list) and we see this rule being ignored, and of course the approved post comes from their owner. Some may argue that Symantec is huge and won’t disappear like those other companies. Many said the same about @stake but shortly after they were purchased, their new owner (Symantec) opted to yank all of the old advisories off the web site making Elias Levy’s concerns reality. As Chris Wysopal said in reply, Symantec needs to post their advisories to the list just like everyone else. While Symantec may stick around, their web site may change or corporate policy may be altered, and that information may not be readily available in the future.

Depending on how you count flaws..

[This was originally published on the OSVDB blog.]

http://www.computerworld.com/%5B..%5D/0,10801,109278,00.html

After flap, Symantec adjusts browser bug count
Depending on how you count flaws, either IE or Firefox could be considered less secure
News Story by Robert McMillan

MARCH 07, 2006 (IDG NEWS SERVICE) – A report issued today by Symantec Corp. seeks to satisfy users of both Mozilla Corp.’s Firefox browser and Microsoft Corp.’s Internet Explorer.

In its latest Internet Security Threat Report, covering the last six months of 2005, the company now features two different ways of counting browser bugs: one that finds that Internet Explorer has the most vulnerabilities, and a second that reveals Firefox as the bug leader.

Thank you Symantec, for generating completely useless vulnerability statistics. When you can manipulate them to support either side of an argument (and do so intentionally), what’s the point? Just define your criteria for counting a vulnerability, define your time frame, and let the results speak for themselves.

OSVDB ThreatRiskWarnFUD Level 6.32

[This was originally published on the OSVDB blog.]

While chatting with a journalist about risks and ratings. I think the conversation started with a discussion on CVSS, but moved on to more general risk ratings. This lead me to wonder about the usefulness of Internet risk/threat ratings that some security companies maintain. Does anyone use them? Do they help anyone other than journalists who tend to reference them as if it gives us a meaning or measure of the current risk?

Such ratings suffer from the same problem any other vulnerability/risk scoring system does. They tend to be overly complex, too subjective, or too simple. When I took notes to remind myself to blog about this, I noted the ratings of a few security outfits:

Symantec Threatcon is Level 3: High (currently at 1, max 4)

ISS Alertcon is Level 2 and says we will be at this level until Jan 6 (currently at 1, anticipated through Feb 2, max 4)

SANS is at Yellow (currently at Green, 1 of 4)

Does any of that really help you?

The initial ratings were taken in the midst of the WMF massacre, in which thousands of sites hosted hostile code that could compromise a system just by browsing a web page. Attack vectors quickly spread to spam/email and IM networks. According to SANS, “It is extremely hard to protect against this vulnerability“. Secunia and Symantec flagged the vulnerability “Extremely critical,” and rated it 9.4 on its 10-point scale respectively. Within hours, computer virus and spyware authors were using the flaw to distribute malicious programs that could allow them to take over and remotely control afflicted computers. This vulnerability affects all flavors of Windows which runs on an estimated 90% of personal computers. Some reports indicate 10% of computers had fallen victim to this exploit.

Now, we’re in the middle of the CME-24/Blackworm/Nyxem/Blackmal/Mywife outbreak, and all three are at level 1. Does this rating system help you?