Symantec Paper Validates Trustworthy Computing?

Dave G. | July 18th, 2006 | Filed Under: Industry Punditry, Slashdot Rounddown

I think its great that Symantec is investing in security research. It is some an early sign that they are investing in some genuine innovation. Their latest white paper is an analysis of Vista’s Network Attack Surface, and done by Tim Newsham (Yes, the Tim Newsham), and Jim Hoagland. If you care about Windows security, you should read it.

They tested for a plethora of vulnerabilities across the attack surface of Windows Vista Beta (builds 5231, 5270, 5384). Many of the vulnerabilities identified in the earliest build reviewed were gone by the latest build. Despite Slashdot’s ominous title (and totally misleading blurb), I will say that this is a good story for Microsoft, not a bad one.

Why?

This is the kind of trend you want to see from your vendors. I say this not just because of trending, but this is also BETA software, which isn’t even scheduled to ship for 7 months. It demonstrates that they are doing active security reviews during their development lifecycle, and catching vulnerabilities before it ends up in consumer’s hands.

I took a stab at reading the paper and scoring the vulnerabilities. Here was my approach:

  1. Review paper to cull vulnerabilities. I am sure I have missed things.

  2. Score each vulnerability (+). I am sure I have misrated things.

  3. Tabulate scores for each version of Vista. I am sure I added correctly. However, see numero uno through numero dos for caveats.

  4. Make a graph. I had no choice.

(+) When it came to scoring and vulnerability identification, I tried to be ‘generous’ and give vulnerabilities as severe a rating as I could. The consequence of this is that the vulnerabilities identified by Symantec and fixed by Microsoft. Being conservative would make the chart less severe, but not by much.

Here is the scoring approach:

Score Description
6 Remote Command Execution or Retrieval of User Data
5 Remote Denial Of Service (Not on subnet)
4 On-Link Command Execution or Retrieval of User Data (on subnet)
3 On-Link Denial Of Service
2 Remote Information Gathering (non critical system information)
1 On-Link Information Gathering

And the vulnerabilities I saw were:

  • Gratuitous ARPs (3)

  • Sequential IP IDs (2)

  • Protocol 43 DoS (5)

  • Protocol 44 DoS (5)

  • Blat (5)

  • Land (5)

  • Opentear (5)

  • IP Options DoS (5)

  • SMBCrash (5)

  • RPCTCPEnum (2)

  • RPCUnfilteredAccess (2)

Here is the actual chart:

Vulnerability Chart

Now, even if we throw out my risk scoring, we still have 9 vulnerabilities going down to 2. The two that remained were gratuitous arp and sequential IP IDs. I could easily make an argument that these aren’t vulnerabilities at all, but even if I lost, I would win the ‘these are low risk vulnerabilities’ argument.

Disclosure: Matasano and Microsoft

Viewing 12 Comments

    • ^
    • v
    Is the paper publicly available?
    • ^
    • v
    Sequential ip ids is not a 'flaw' but not being able to toggle between sequential and secure random id's via a configuration setting is.

    Where is the paper? Tim's stuff is always the best.
    • ^
    • v
    • ^
    • v
    ok, there are two ways of interpreting this:
    1- the bugs are not so important and where or are being fixed, security has improved, no big deal;
    or
    2- these bugs hint at an inmature IP stack (security-wise), be careful because more (and more serious) bugs may pop up in the future.

    Really... its 2006 and if you developed an TCP/IP stack from scratch that is vulnerable to land/blat/opentear and a zero-lenght IP option DOS after 2 betas, the signs are not reassuring.
    I believe that is the rationale behind the conclusions in the paper
    • ^
    • v
    Ivan is probably right in regards to this being a bad sign for the new Vista ip stack. I reskimmed the paper and didn't find the issue of techniques specifically addressed, but most of the language around discovered vulnerabilities indicates that this research did not include any binary analysis of the stack, but instead was limited to testing it through simlpy remotely pentesting the box. If this is the case and then there will definitely be lots of interesting problems lurking behind the scenses, and if microsoft doesn't have some qualified vulnerability researchers do a binary or code based analysis of the stack before release, well then you can bet your bottom dollar the intruder community will find some 0day when they do just such a thing post release.

    Of course maybe this is just what symantec wants us to think, the two companies aren't known for cooperating, and microsoft has become one of the most aggressive vendors in the world when it comes to hiring external vulnerability researchers to review code. I'd be really surprised if mister softy would ship a new module like this without an external review. If that's what they were planning than perhaps someone there will read this comment and think twice?
    • ^
    • v
    This just in: Serious security bugs found in uncommited code on developer's hard drive!

    Security improvements, like performance improvements, are iterative improvements. After a module is functional, you do performance and security testing and improve both in iterative cycles until release. You can't get either perfect, so you just expend the amount of resources that you deem appropriate. The version of the stack that Symanted first looked at appears to have been very early in the review/improve cycle.

    I think MS should have done some security reviews and testing before the Beta 1 release, but people also need to remember that Beta 1 was released about a year prior to the planned Vista release. Does anyone honestly believe that a TCP/IP stack that can be blue screened with ISIC had received even a cursory security review?
    • ^
    • v
    Hello. It's nice to find some intellegent discussion about the paper.

    Really in the paper we were mainly just sharing what we had found out when took a look at Vista networking. Oliver Friedrichs introduces tha paper well in this blog post, which could be regarded as a foreword to the paper:
    http://www.symantec.com/enterprise/security_res...
    • ^
    • v
    BTW, for the paper, we didn't look for any new bugs in the 5384 build. We only looked if the known ones had been fixed.

    I do think it is commendable that Microsoft has spent quite a bit of effort testing it for bugs.
    • ^
    • v
    (Re: the nonsense "Symantec Spreading Vista FUD To Manipulate Stock Price")

    > And, it looks like I was right: Symantec *IS*
    > trying to use old and already-corrected Vista
    > flaws to bolster investor confidence in its
    > product lines ahead of disappointing earnings.

    Indeed, earnings were so disappointing that the stock price rose about 10% after the announcement. :)
    • ^
    • v
    My guess is that if Jim Hoaglund had an absolutely foolproof plan to boost SYMC earnings by 40%, along with a mathematical proof and a PowerPoint deck with the most kick-ass animated pie chart slide ever, Symantec still would not be capable of capitalizing on it.

    The problem with these "SYMC uses vulnerability research to terrorize the market" stories --- well, along with the fact that it's a stupid idea --- is that it attributes much too much cleverness to Symantec upper management.
    • ^
    • v
    Dino: good point but i dont buy it. I've seen pre-beta code for a quite complex and comprehensive system from the same vendor several years ago (the .NET framework) and its overall security maturity seemed better (ie. it was not vulnerable to trivial well-known attacks identified through black-box testing). They are suppossed to be way better than what they were in 2000/2001 right?.
    That being said, there's also an important difference: given the current emphasis on security MSFT can now afford to delay shipping the new stack until they get it right, and that important because they will eventually get it right

    Then again, in the words of Mr. Biafra: "right guard will not help you here..." prefix/prefast/etc and general purpose static and dynamic analisis tools will not uncover the obscure bugs, you need someone that understands the complexities of the protocol's state-machines and the security assumptions being made.
    • ^
    • v
    BTW, there is a new edition of this paper:
    http://www.symantec.com/avcenter/reference/Vist...

    Enjoy,

    Jim

Trackbacks

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus