The Purpose of Tracking Numbers.. (IBM)

[This was originally published on the OSVDB blog.]

First it was HP, then it was Sun. Not to be outdone, IBM steps up and gives VDBs a headache.

APAR IZ00988 is “sysrouted” to APAR IZ01121 and APAR IZ01122.

Really IBM, the amount of information common to all three pages is overwhelming. Do you really need a new APAR number issued for component name or level? Can’t you just list them all in one APAR and save us time? More importantly, do we need three APAR entries that say “a security issue has been fixed” and make us dig up the information?

“high price bug brokering market just isn’t viable”

[This was originally published on the OSVDB blog.]

On January 17, 2007, SnoSoft / Netragard LLC announced a new Exploit Acquisition Program designed to compete with iDefense, TippingPoint and others. Nothing special or different other than the suggestion that they would pay more for high end vulnerabilities. A little over a year later, and they announced they were shutting down the Exploit Acquisition Program. From their post:

We regret to say that its true, we’ve shut down the Exploit Acquisition Program. The reason for the shutdown was that it was taking our buyers too long to complete a single transaction and it wasn’t fair to the researchers. While we’d expect a single transaction to take no more than a month, the average transaction time for our buyer was 4 months. The last transaction that we attempted took 7 months at which point the issues were silently patched and the transaction was dead. As it stands right now, we can’t justify asking anyone to wait that long to move a single item. So until the end players learn how to move faster, the high price bug brokering market just isn’t viable.

No offense to SnoSoft / Netragard, but their competitors have proven that the market is viable. I guess the trick is how you ‘sell’ the information. For iDefense it is early warning for their customers in case the same vulnerability is being exploited by others. For TippingPoint it is early warning and IPS signatures. For WabiSabiLabi it is more like the SnoSoft program, where one buyer gets exclusive rights to the information, and it appears to be working to some degree.

It’s patch xxxday!

[This was originally published on the OSVDB blog.]

A while back, Microsoft announced they were moving to release patches on the second Tuesday of each month, lovingly called Patch Tuesday. Soon after, Oracle announced that they too would be moving to scheduled releases of patches on the Tuesday closest to the 15th day of January, April, July and October. Now, Cisco has announced they are moving to scheduled patches on the fourth Wednesday of the month in March and September of each calendar year.

In the attempt to make life easier on administrators and help avoid installing patches every few days, these scheduled releases are now causing organizations to enjoy life between monster patches.

Mar 11 – Microsoft
Mar 26 – Cisco
Apr 8 – Microsoft
Apr 15 – Oracle
May 13 – Microsoft
June 10 – Microsoft
July 8 – Microsoft
July 15 – Oracle
August 12 – Microsoft
September 9 – Microsoft
September 24 – Cisco
October 14 – Microsoft, Oracle
November 11 – Microsoft
December 9 – Microsoft

As you can see, October 14 promises to be a lot of fun for companies running Oracle products on Microsoft systems. While the scheduled dates look safe, I can’t wait until we see the ”perfect storm” of vendor patches.