The blogging world has been a little quieter than usual lately... I use Bloglines as my feed reader and previously I could have 700 posts a day to go through... now if I hit 300 it's a busy day. It seems to me that people will grasp at anything to find content to blog about... Everyone picks up the same thing and puts a slightly different twist on it. The latest subjects seem to be Tipping Point/Pwn to Own and Bruce Schneier's comment. I wouldn't normally comment on either of these (they're too popular) but my Bloglines search on the keyword 'nCircle' went off today and it was a post over at McAfee. Questioning why they had triggered my nCircle query I surfed over to the link and checked it out. I was rather surprised to see them taking a shot at Tipping Point for their offer of $10,000 in the CanSecWest Pwn to Own competition. I wondered how nCircle could possibly be mentioned and then I saw it... They referenced a two year old post by a former employee and attempted to use it as ammunition in their obvious attack on Tipping Point.

I find it most interesting that their attack has so little basis that the only ammunition they could find came from a two year old post... The security industry is constantly growing and changing... It's changing so fast that I would consider a post from 6 months ago to be too old to act as a reliable reference.

To further prove that point... I, for one, think that initiatives like ZDI and iDefense are great. That is my opinion though... someone else may post and disagree with me, that's something I enjoy about working at nCircle. I have freedom to have my own opinions and express them on the blog. So when I post these opinions they are my own, and not that of the entire VERT team, but let's get back on topic.

Let's say you're sitting at your computer 5 years ago and you discover a remote code execution vulnerability in Company X's Product Y. Now you could send an email to Company X and maybe have your name show up in small print at the bottom of their website... alternatively you could fire the vulnerability off to a few mailing lists and have everyone know your name. To you the choice you made was insignificant... there wasn't really a benefit to either option and if anything the slight benefit went to the concept of Full Disclosure.

Enter ZDI and iDefense. Now you have a third option, you sell the vulnerability you discover to one of these companies and suddenly everyone benefits. You walk away with some cash in your pocket, the vendor deals with a company that believes in responsible disclosure and the purchaser of the vulnerability has new value-add for it's customers. "Yes we'll identify this vulnerability that the vendor isn't even aware of yet." Everyone wins.

Now let's take a conference... a place where you go to network with others in the industry and absorb large amounts of information. A conference that survives on registration fees and sponsors. In order to publicize the Con they hold a hacking contest. This contest draws more attendees and increases media attention. In order to make the contest even better a third party steps in and offers a cash prize. Now we have more interest in the contest, which in turn causes more media attention. So the conference benefits from increased publicity, the attendees benefit because they've absorbed knowledge and the publicity tells them that the conference will occur again in the future. In addition, the contest winner benefits from a cash prize and the third party sponsor benefits from a new vulnerability. This has got to be better than someone else finding the vulnerability and just setting it loose on the Internet.

In the end I see the negative side effects being non-existent or minimal at most. I say kudos to companies that support these vulnerability purchase initiatives and extra kudos to Tipping Point for willingly stepping forward and supporting CanSecWest.

Other Links:
Thomas Ptacek (Matasano) comments
Tipping Point Comments on QuickTime Flaw

It's that time of month again... You know what I'm talking about... it happens once a month and generally causes headaches for everyone involved... That's right... Patch Tuesday. This Patch Tuesday brings us 7 advisories and 18 vulnerabilities. The most interesting would probably be MS07-026, which includes a remote code execution vulnerability against Microsoft Exchange Server (including Exchange 2007)

We'll try and keep you posted with anything interesting that happens over the course of the day... For now here's the advisories:

• Vulnerabilities in Microsoft Excel Could Allow Remote Code Execution (934233)
• Vulnerabilities in Microsoft Word Could Allow Remote Code Execution (934232)
• Vulnerability in Microsoft Office Could Allow Remote Code Execution (934873)
• Vulnerabilities in Microsoft Exchange Could Allow Remote Code Execution (931832)
• Cumulative Security Update for Internet Explorer (931768)
• Vulnerability in CAPICOM Could Allow Remote Code Execution (931906)
• Vulnerability in Windows DNS RPC Interface Could Allow Remote Code Execution (935966)

I got up this morning... and got ready for work... Like most days I noted the date on the calendar. Friday, May 11th... excellent. I got in to the office and decided to check out the RSS feeds to see if anything interesting was happening... I came across a post on SearchSecurity and the first thing I did was double check my calendar to ensure it wasn't April 1st. Reading the article, all I could think was, "It's got to be April Fool's Day". Yet it wasn't... it was indeed May 11th and I was supposed to take the article seriously.

The author of the article was submitting the idea that Patch Tuesday should be eliminated... that admins and security people dread Patch Tuesday. Now it's not really a secret that we don't all get excited for Patch Tuesday... given our SLA we generally work a rather long day to get quality coverage to our customers as quickly as possible... but at the same time, at least we know when to expect them and how to co-ordinate our resources. Then I think about the "other side"... what I call corporate security... When you hear about Patch Tuesday you hear that Microsoft decided to take that route because admins were asking for it. They wanted to know exactly when the patches were being released so they could schedule for downtime and resources. I can understand this, when I was an admin at a small business I knew I had a couple days to test the patches and a day or so to roll them out. If I was constantly testing single patches, I'd have never had time to do anything else.

On the subject of testing patches... the author of the article uses that as a reason why patches should be released as they are ready. Apparently if companies perform tests prior to applying patches to production machines they are opening themselves up to serious security issues. Is author's theory that; "if you only get a single patch you don't need to test it first"? Otherwise you'll have the same issues whether or not the patches are released on a schedule and in bulk. Maybe I learned something today... One patch can't cause a production machine to blow up... you can apply it without internal testing... it's only bulk patching that requires initial testing. Now, raise your hand if you think only an idiot would believe that.

Reading these comments makes me wonder if the author has ever been in an enterprise environment; if he's ever had to worry about the deployment of patches across hundreds, if not thousands, of machines. Has he ever had to question what would happen when a ASP.NET patch was applied to a server running a homegrown ASP application? We've all heard stories about how delicate SCADA systems are... Should we simply apply patches to systems running automation software at a manufacturing plant or perhaps the systems responsible for power and water distribution? I foresee a number of problems with just haphazardly applying a patch.

Other issues were brought up... and these two are really good. The first is that there are more public vulnerabilities the day after the patches than the day before... This follows the same principal as patch testing. Even if you have a continuous release as ready patch cycle, exploits will still appear as patches are released. The bad guys have access to the patched and unpatched binaries and with a little effort they can find the source of the vulnerability. Releasing patches independently of each other without a schedule won't stop this... Sure the number of exploits released the day after a patch release may drop but the number of days that patches are released would increase. That makes this yet another moot point in a pointless article.

The second issue is in regards to "time till patch". The author chose the DNS vulnerability as his example... citing that it was used in numerous attacks and that a worm even spread... Other than the initial ISC postings and the initial mention of the worm how often did we hear of this problem? It wasn't making headline news and it wasn't as serious as say the WMF exploit. The worm was so poorly coded that it looked for a single port. Since the DNS RPC Management interface listens on a dynamic port (which you can change by simply restarting the service) it was actually fairly useless. There were also mitigation techniques made available that were 100% effective in curbing this vulnerability. All of this leads to the DNS vulnerability being a really poor example to try and prove that Microsoft's patch timeliness is horrid.

When MS06-040 was released we saw numerous references to the "end of the worm". Yet the author of this SearchSecurity article comments on how many recent vulnerabilities require emergency (out-of-band) patch releases... This article is a page of FUD from start to finish... I'm guessing, given the number of banners on the page, that their revenue comes entirely from pay-per-click sites... and for that reason I refuse to even link to the original article (Instead here's the Google Cache link)... I don't want to be responsible for increasing their revenue by linking to their FUD.

A regulated patch cycle is exactly what this industry needs... and it obviously works well. We are seeing other vendors, such as Oracle, moving to the same scheduled, regular release cycle. I leave the readers of this blog with a simple message: "Beware of FUD". The internet is crawling with it and it will make your head spin and your skin crawl... you just need to be able to distinguish between the drivel and the useful information