Posts in Category "Privacy & Security"

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.