Researcher sat on critical IE bugs for THREE YEARS

Security outlet VUPEN has revealed it held onto a critical Internet Explorer vulnerability for three years before disclosing it at the March Pwn2Own hacker competition. The company wrote in a disclosure last week it discovered the vulnerability (CVE-2014-2777) on 12 February 2011 which was patched by Microsoft on 17 June (MS14 …

[Paul Crawford]

3 years?

Time-line is claimed to be:

VIII. DISCLOSURE TIMELINE

-----------------------------

2011-02-12 - Vulnerability Discovered by VUPEN Security

2014-03-14 - Vulnerability Reported to ZDI and Microsoft During Pwn2Own 2014

2014-06-10 - Vulnerability Fixed by Microsoft

2014-07-16 - Public disclosure

Do we really believe they told no one before Pwn2Own?

[Malcolm 1]

Re: 3 years?

VUPEN's business is selling exploits to governments and law enforcement, so it seems unlikely that it has been kept entirely private.

[Paul Crawford]

SourceFire report

It is worth reading the SourceFire report as it gives an interesting look at the disclosed vulnerabilities over the years.

Forum trolls will delight in being able to quote it for/against any fanbois of OS as well. It has some correct, possibly controversial, ways of reporting, for example counting the webkit browser engine as "Apple" so the CVE count is way higher than you might have expected. Similarity it treats Linux as one product, but the different versions of Windows as separate (mostly, this is discussed).

However, what the report lacks is the exploit count relating to these. For example, it has the iPhone as much worse than Android by CVE count (210 versus 24), but we all know that Trojans and general shit-ware, etc, for Android are much, MUCH bigger problem in practice.

Oh, and check your buffers please? That is the No.1 vulnerability of the quarter-century!

[Paul Crawford]

Re: SourceFire report

Oh, the other thing lacking from the report is the time-to-patch. That is a big factor in how secure you can be with a given product/supplier.

[Anonymous Coward]

Re: SourceFire report

That thing is so full of bad statistical practices that it would be a lot shorter to list what they did right than what they did wrong.

The good news, if there is any, is that it doesn't look like they're playing favorites and trying to make one thing look better or worse than it really is, they just aren't that clueful about how to properly present this type of information.

The other problem is their sources of data may be suspect. Who determines whether a given vulnerability is critical or severe or whatever, and have consistent criteria been applied throughout the past 25 years? I very much doubt that. Not to mention that back in the 90s, there was a lot less attention paid to the issue.

For example, Windows NT looks a lot more secure than any other version of Windows based on the number of vulnerabilities, but people just weren't looking very hard at it compared to how much attention is paid (literally paid, as there's a lot of money in it now) to finding Windows vulnerabilities today.

If someone offered a bounty of $10,000 per critical security issue in Windows NT today, I'm sure that total would grow by leaps and bounds - a lot of it by finding "yes, this bug that was recently found in Server 2008 is present in Windows NT as well, but no one had bothered to look because no one uses Windows NT anymore"

[Anonymous Coward]

to paraphrase J W Pepper

A secret agent! vulnerability researcher! On whose side?

[John Smith 19]

Software written more carelessly? More buggy libraries inhereting faults? More reporting?

Is the bug count really rising or is it simply that more software is being (in the widest sense of the word) "written"?

Just to be clear the #1 fail is buffer overflow at about 25% of all bugs and about the same of critical bugs.

IOW teaching people only how to do this part of their job properly would eliminate 1/4 of all web vulnerabilities.

And that's been the case for the last quarter century.

[Anonymous Coward]

Re: Software written more carelessly? More buggy libraries inhereting faults? More reporting?

"And that's been the case for the last quarter century."

Make that at least half a century. As a now retired support programmer much of my career consisted of finding bugs in other people's code. Most developers didn't think "defensively". They usually didn't exhaustively test the limiting conditions that were supposed to control the filling of data buffers. One of the common early mistakes was to allow people to backspace more than the number of characters they had already entered. Good contingency handling is 80% of the development work.

The ICL VME target architecture used data descriptors to try to avoid unintended data overflows. IIRC that effectively established a hardware range protection specifically for each data item

[John Smith 19]

Re: Software written more carelessly? More buggy libraries inhereting faults? More reporting?

"The ICL VME target architecture used data descriptors to try to avoid unintended data overflows. IIRC that effectively established a hardware range protection specifically for each data item"

The Burroughs machines also seemed to use this. A mainframe sized stack based processor built in the early 60's and programmed in something like ALGOL at a time when the common state of practice was still assembler.

I've long joked proper software could be 1/4 the size it is if you could just make 2 assumptions about the users. 1)They always know exactly what they are doing 2) They never make mistakes.

IRL both are a total fantasy.

[Captain TickTock]

Stale bread and butter...

...perhaps the reward system is working against timely reporting?

[Sir Runcible Spoon]

Re: Stale bread and butter...

perhaps there is a parallel reward system that encourages delay?

[Anonymous Coward]

Re: Stale bread and butter...

VUPEN makes money selling zero-day exploit. While you get rewarded once for a disclosed vulnerability, you can sell it more than once to different LE agencies (and other kind of governmnet agencies...)

[Don Jefe]

Re: Stale bread and butter...

There are always going to be people who game any system for maximum advantage. There's simply no avoiding that. That's just Human nature.

If you are into analyzing the failure of systems (it's a lot of fun and perfectly designed for wagering) an interesting thing to watch is how systems deal with those who game a given system. Making rules to stop the gaming is quite possibly the fastest way possible to destabilize a system and create chaos. Every new rule creates a new opportunity for someone else to game the system, so you end up providing the perfect growth medium for the sort of people that think about gaming systems. More rules creates more ways around the rules.

Point is, the idea of rewarding flaw finding shouldn't be modified to deal with special cases.

[Dr Scrum Master]

Re: Stale bread and butter...

But it's just a Dutch Auction.

Do you have the nerve to hold out longer than the potential other guy?

[Al Jones]

Oldest Bug

The LZO bug may had been sitting there for 20 years, but there's no indication that someone discovered it 20 years ago, and didn't tell anyone about it so that it could be fixed.

There's no comparison with a known critical bug that was not revealed to the people that could fix it.

[P. Lee]

Bug or Design Flaw?

Surely this is yet another example of MS putting security (or lack of it) into the GUI where it doesn't belong. The security should have been on the file system and the GUI should run as the user. Even if you have have horrible buffer over-runs in the code, a dialogue box should be running at the same level as any other user process.

Ah, you've put stuff in the kernel because you value speed over security? That isn't careless coding, that's a design fault.

I know, I think all major OS's do it, but I think Windows is almost the only one left that you pay for isn't it? Rather like in most citrix configs I've seen. You're blocked from accessing C:\...\cmd.exe in Explorer, but you can go through a file->open dialogue box and get to it.

Pretty much the whole point of an OS is to sandbox applications and provide them with their own "virtual machine." At least, that's what I was taught over two decades ago. Now we have more CPU power than most people can use, perhaps it is time to do things properly.