Archive for the 'For vendors' Category

Adobe Reader might be patched, but it’s hard to tell

Saturday, June 28th, 2008

Michael Horowitz is annoyed that users cannot easily tell if they have a major Adobe Reader security patch installed. Both the unpatched and patched versions report themselves as version 8.1.2. He reports various ways to check on different versions of Microsoft Windows, but even security software is having trouble checking correctly.

Upshot for vendors: a version number bump for patches is important!

Popularity: 45% [?]

Ubuntu and bugs

Saturday, June 28th, 2008

Mark Shuttleworth describes the particular problems operating system distributions have with bugs: they are a collection point for bugs in many products and have a responsibility to their users to get the bugs to the places where they will be fixed:

Our primary goals should be to ensure that fixes we produce, and information we generate in the QA process, make their way upstream where they will benefit the broadest cross-section of the community. Separately, we want to ensure that each Ubuntu release ships without major issues, regardless of where those issues originated. We are responsible for the user experience of every line of code, even though we don’t produce every line of code.

For Shuttleworth, upstream cooperation is the key to providing the best user experience when it comes to distributing projects you did not write.

Popularity: 38% [?]

When a security report is treated as a feature request

Saturday, June 28th, 2008

Dave Goldsmith has some experience trying to report a security vulnerability to a company that does not have a security-specific process:

I reply:

Can you give me some guidance on your response guidelines to security vulnerabilities? Is there a timeframe that you try and have vulnerabilities fixed by?

They reply:

Hi David,

We’re always looking for new ideas and fixes to roll out in future updates but as as rule we don’t comment on possibilities or timeframes.

His commenters discuss the lack of reporting guidelines for security flaws in websites. In a more recent post, he reveals that 37signals was the previously unnamed vendor, and writes:

Vulnerability reporting should not be handled in the same way that you manage feature requests.

[Via ZDNet, which discusses whether treating security flaws as defects is a more effective way to communicate the problems they cause.]

Issues to consider here are the usual with security bugs: vendor communication versus disclosure. In the case of security problems in end-user software the problem with disclosure is the race for users to patch their systems against attacks being launched on those systems, with consequences that vary per attacked system. When it’s a website with a security problem, disclosure has a different weight, as rather than leaving some users in the lurch while a fix is rushed out (or leaving them to fight for one), the vulnerability can largely be fully exploited immediately. There’s only one target. You may be writing off this vulnerability’s consequences all together in the hope of future responsiveness from the vendor.

Popularity: 64% [?]