Bullseye equations

At eWeek, Larry Seltzer raises some good points in his article “The Big Bullseye on Adobe”… definitely worth reading.

But I think the main reason the bullseye has been growing has been because it’s increasingly financially rewarding to attack any widely-distributed code. The growing value of your digital data and digital identity now draws attacks — in areas which were previously considered safe.

Browser security practices which seemed acceptable ten years ago now entice exploit research… window requests, “javascript:” requests, cross-domain mashup requests… many of last year’s Player issues were closing off plugin requests that browsers and servers should no longer fulfill.

And even coding practices which seemed acceptable ten years ago now need to be redressed, as April’s null-reference pointer discussion showed. In networking code, domain-pinning is now seen in a very different light than even three years ago.

Web technology tends to be too accepting of innovations, and we only look for the dark side later. (That’s “imho”, btw. 😉 The people who created email didn’t foresee spam. The people who created TCP/IP didn’t anticipate actual denial-of-service attacks. The people who thought email needed colored fonts, images and JavaScript didn’t handle the subsequent problems of web bugs and beacons. Early blogging hosts didn’t anticipate comment-spam or spamblogs. The holes were there early, but weren’t valuable enough to exploit until later.

The risk of an attack does grow with the “attack surface” (the amount of code, functionality, and entrypoints), but the risk also grows with the “attack incentive” as well. When technology leaves a hole open, it remains ignored only if no one finds it rewarding enough to exploit. Lynx may have a small attack surface, but there’s little financial incentive for attack research as well. Successful technology draws continuous re-examination.

Do things like AIR and Acrobat 9 increase the total attack surface? I’m not sure… adding existing things together doesn’t concern me as much as some of the new abilities, like local file access or invoking third-party code. The team here is pragmatically paranoid about increasing any attack surface, but I think it really requires a few years of realworld probing to test whether a new combination of abilities is immune to exploitation. I’m not sure I can yet agree with Larry’s initial point about SWF-in-PDF directly adding to attack risk.

But I do agree with Larry that Adobe’s clientside runtimes are drawing increased security research, by people with vastly differing motives. Adobe Flash Player lets you reach practically anyone, and criminals will also seek to exploit such realworld accessibility. That’s why the security team here is so important, and Larry included a description from Erick Lee about their approach:

“The Adobe Secure Software Engineering team, which I manage, has industry-leading experience in building secure applications and is a core service provided to all Adobe product teams, independent of any specific business or product line. Our secure software engineering practices include threat modeling, automated code audits, in-house fuzzing, bringing in third parties for external security reviews and more. “

(I also agree with Larry on “people update Flash, but maybe not fast enough”. Last week’s “China exploit” story (which was subsequently retracted by Symantec) may not have been possible without the wide publicity given to the null-reference paper in April… the blogosphere ended up arming attackers without reminding civilians to keep their software current. Giving the public some time to react would be helpful, and appropriately updating articles and accepting comments is, of course, a vital responsibility.)

Larry Seltzer is one of the better security writers out there, and he’s got a valid point here…. Player, Reader, AIR are all under increased examination by hacker gangs. They have great incentive to perform such research. It’s hard for Adobe product teams to push back against developers who want more local-access features, but it’s best to do things slowly, open new doors one at a time, and listen for the actual results. A phrase like “The Big Bullseye On Adobe” is a realisitic description of the situation today.

2 Responses to Bullseye equations

  1. John Dowdell says:

    … and as long as I’ve got a security article here, let me republish a comment which never made it through the anti-spam process on another blog, asking about the update rate to Player 9.0.124.

    Hi, good points, thanks.
    “How does the average user know that they should update Flash and how to do so?”
    The Player’s auto-update mechanism is the most reliable way. This is turned on in each client by default, although individuals can choose to turn it off.
    The numbers you saw make sense, because we don’t usually turn on auto-update until after there have been public downloads for a bit, to guard against the theoretical case of having to revise a revision. The 9.0.124 auto-update mechanism is now on, however, so you should see those numbers start to accelerate.
    (Sidenote: Version 9.0.115, “MovieStar”, had an exceptionally rapid update rate, 62% in three months. I don’t think we put that on the auto-update schedule, because MovieStar was more a feature release than a security release. Goes to show what consumer demand can accomplish…. 😉
    (I’m also not sure of the Google Analytics method… in the past, browsers have had mixed results when JavaScript asks which plugins they have, and I haven’t tested their overall capability in a few years. The accuracy might have improved recently, but I’d like to crosscheck the methodology before taking JavaScript’s numbers too literally.)
    I also agree with you that the majority of the public was not protected against the Chinese SWF and 20,000 sites with injected HTML… everyone had the *means* of protection, by updating to the current version, but it’s true that not all of them had done so by the time Symantec issued its unfortunate announcement. That’s why I had wished that Mark Dowd’s null-reference whitepaper had been held back a little while longer, and that bloggers didn’t trumpet it so widely so quickly. Some of the analysts’ quotes suggest that the whitepaper was used as a blueprint for the China attack. Giving the public a little chance to update before sharing vulnerabilities would have been better.
    I’m not sure if anyone was actually at risk, however… those two servers in China with the bad SWF were shut down pretty quickly. Even though 20,000 mainstream websites don’t know what HTML they’re presenting (!!), the hardcoded addresses they were injected with ended up resolving to nowhere. 9.0.124 would have protected them, but theattack was stunted quickly by other means.
    Still… if _so_many_ websites can so easily be injected with foreign HTML, without the owners’ knowledge, then how long will it be until they point to new bad places? That’s the part that worries me most about this whole affair. If websites don’t know the markup they’re serving, that seems pretty dangerous to me…. 🙁

  2. Steve Flowers says:

    Hey John, I know this isn’t your department – and it’s off topic – but I’m at a loss – thinking someone screwed up big time and noone noticed it.
    Went to buy CS3 upgrade, it’s not available on the Adobe site for electronic buy for 2 weeks?? CS3.3 has replaced it. My order goes in as a pre-order for delivery on 24JUN. Can’t buy CS3 electronic.
    Opened a support case — ignored for a couple of days. Contacted phone support – I could order a boxed version but they really couldn’t help me with electronic.
    To boot the demo’s are unavailable until JUL1. SOL – I seem to be if I want to use the tools in that suite.
    I KNOW that this can’t be the intention. Adobe really want to shut down delivery of product bundles (and Acrobat) for two weeks?
    I asked for the number to someone that could straighten it (or me) out. Tell me it isn’t so Batman…