jd/adobe

Gavin O. Gorman of Symantec offers readable research into the Trojan.grups vulnerability, in which zombie computers receive updated commands by parsing instructions found in newsgroup postings. Here's the gist:

When successfully logged in, the Trojan requests a page from a private newsgroup, escape2sun. The page contains commands for the Trojan to carry out. The command consists of an index number, a command line to execute, and optionally, a file to download. Responses are uploaded as posts to the newsgroup using the index number as a subject. The post and page contents are encrypted using the RC4 stream cipher and then base64 encoded. The attacker can thus issue confidential commands and read responses.

This is a handy layer of indirection for a zombie master, because public message boards are harder to blacklist than known-compromised servers. But this public command-and-control method also allows security researchers to study message content, replies, and overall volume levels -- ironically, the zombie masters are publicly "opening up the source" of their network's communications.

In this particular case, debug strings and low posting volumes indicate preliminary testing -- but if this turns out to be a useful attack, it seems like it could be adopted fairly quickly.

So, should newsgroups be considered harmful? I don't see how they could be, considering their proven history of improving global communication. But this article shows that even innocuous network technology is vulnerable to being parasitized by those who don't yet deal honestly with each other.

When a shadow network is operating on citizens' machines without their knowledge, and when public communication methods are used to transmit exploitative commands, how should our networks evolve in response? What's the next step?

Posted by John Dowdell at 10:44 AM | Permalink | Comments (1)

The Internet is "the network of all networks". It is open to all, and this has brought many benefits. But that doesn't mean our own computers and networks should be open to all. We individuals need to discriminate.

Dan Goodin at The Register has been covering the story of legit websites serving malware. Sites you trust may be bad. Sometimes the attackers gain control through a server exploit, sometimes through password cracking, sometimes through keystrokers.

The site owners rarely know they're distributing malware to their audience. This exploit injects obfuscated JavaScript at the bottom of the site's front page, redirecting visitors to various pages which attempt to force a download via old browser/plugin exploits.

Keeping your own software up-to-date, private and secure is necessary... the websites you've trusted may no longer be trustworthy. There is no "little network" of trust in the Web world -- a browser will visit any site, and new hacks can demolish trust zones. (That's why I'll trust a separate AIR client more than I will an HTML5 uberbrowser.)

And in such a "network of all networks", other people getting infected is bad for the rest of us -- more noise, more confusion, less clarity.

Surfing the Web is like walking a strange city, particularly one with a high crime rate. The open-to-all nature requires us to be aware, and avoid unsafe situations.

Some sites we trust may be infected. We need to keep Web software up-to-date, and encourage others to do so.

Posted by John Dowdell at 10:12 AM | Permalink | Comments (1)

Striking study of web beacons and other devices on popular websites... New York Times summarizes:

"Google showed up as the most conspicuous tracker on third-party sites. Google Analytics, a free product that allows online publishers to gather statistics about visitors to their sites, was used on 81 of the top 100 online sites. Cookies from the advertising company DoubleClick, which is owned by Google, were present on 70 of those sites. When combining trackers from those two services, Google had a presence on 92 of the top 100 sites. Others weren’t far behind. Cookies from Atlas, Microsoft’s DoubleClick rival, appeared on 60 sites, and trackers from two other analytics companies, Quantcast and Omniture, showed up on 54 sites... What is striking in the Berkeley students’ report is that in a sample of nearly 400,000 Web domains, Google’s presence remained high, at 88 percent, while those of other companies declined sharply... 'Our data shows that even if you are not going to Google, if you are browsing the Web they are collecting data about you.'"

Using a cookie-blocker is not enough... any bit of third-party content on a page sends an HTTP request from your IP address to such a central service. Over a surfing session a variety of such requests build up a profile of the surfer at that IP address. This can then be compared with similar session profiles within that general IP block from other days. And, of course, if you sign into a Google service then your name is associated with your IP address.

An ad-blocker is necessary defense. Just as a Flash-blocker protects you from poor choices by site owners, an ad-blocker prevents websites from advertising your arrival to such central repositories of information.

Is Google actually tracking and analyzing the data they collect? No one knows. They've been closed and non-transparent about their privacy practices ever since the initial controversies over their perpetual cookie. Their longtime "special advisor" is a polarizing former Vice President of the US who spearheaded the V-chip effort and was involved in ECHELON and CARNIVORE. The lack of a response to reasonable questions may itself be an answer.

The business model is to sell your exquisitely-qualified attention to advertisers. You are the product. The "open web" is used as a massive profiling tool. You are the product. The process is opaque, closed, proprietary. You are the product.

Many people initially deride their own personal privacy -- "privacy is an illusion" and all that. Many also think they would never be mugged, and so flash wallets or iPhones on subways and deserted streets. Habits can change very quickly, once your own personal experience changes.

When you visit most sites, Google Knows. That's too much power to place in such an opaque organization. To the degree you do not minimize your own exposure to such data collection, you are the product.

Posted by John Dowdell at 9:15 AM | Permalink | Comments (1)

I went through the registration process for CNET, and after creating the account it said my username was already in use. So instead of asking a clarifying question at the original article, I have to make a separate blogpost here, and hope the reporter sees it....

Elinor Mills at CNET today mentioned Flash and webcams during a clickjacking article. I'll snip out the relevant passages: "In a demo at CNET offices on Thursday, Grossman showed how someone could launch a clickjacking attack using Flash to spy on someone by getting them to turn on their computer Web cam without knowing it... In the Web cam demo, the iFrame created contains a Flash pop-up window that asks the user to grant permission to have the Web cam turned on. When the victim clicks the link, the Web cam is turned on and secretly begins recording everything the user does in front of the computer... In the Web cam scenario, the best defense is probably to put a post-it note or other item over the Web cam lens and to disable the microphone in the software, he said. Flash Player 10 provides some protection by preventing anything from obscuring the security permissions dialogue box, he said... More details are in a white paper on the technique, written by Grossman and Robert Hansen of SecTheory and published in September 2008."

Key question: Were you using the current Adobe Flash Player, or the version current at the time of last year's whitepaper?

If someone has a new way to make various browsers obscure Player's permissions dialog, then we need to know about it. But from the description above, with Player version undescribed, I can't determine whether there's a new issue here.

Background: What is "clickjacking"?

(a) It's a failure in website security where a malevolent third-party has either hacked in their own code, or persuaded a site to use third-party code through social services or advertising -- basically a trusted website hosting untrustworthy content. It's a flaw in website integrity.

(b) It's a failure in browser security where third-party code can hide what the reader is clicking on -- where What You See Is NOT What You Click. The browser vendors each seem to say their offering fixes at least some of the methods to defeat click integrity while others do not, which makes me wonder whether any browser has truly addressed this failure in browsers' click integrity.

(c) Flash isn't involved directly in this "What You See Is NOT What You Click" problem. It's used as a poster child of what can happen when infected sites can take advantage of browser failures.

Summary: There's a new article, but it is not clear whether there's a new issue.

Posted by John Dowdell at 8:45 AM | Permalink | Comments (2)

Adobe Reader 9.1 is now available. It addresses a type of "malformed PDF can crash" exploit which was heavily blogged two weeks ago. I'd recommend installing it... although I haven't seen much discussion of actual exploits, the hack itself was promoted enough that it might spur people to try. (Those early press accounts also had a good deal of inaccurate information... the Adobe Security team is circumspect in what they say, and remains the best resource on issues like this.)

If you're on a locked machine where you must use Reader 8.x or 7.x, we expect the updaters for those versions online next week.

Also, last week's Flash Player update did have auto-update turned on... I checked after reading this article at The Register which wondered. You can set your own Player preferences for how frequently to check for updates -- the default is checking every 30 days. If you use both IE and some other browser on a PC, then you'll indeed need to update both wrappers for the common Adobe Flash Player -- that's the way the browsermakers have set it up. (The article at The Register invited comments, but it's hard to justify a site-specific password which doesn't edit anonymous comments.)

Posted by John Dowdell at 1:55 PM | Permalink | Comments (0)

There was a lot of press Friday on a new "malformed PDF can crash Reader, potentially leading to foreign execution code". Unfortunately, there was far more press text than source text. The Adobe Security team has better source info in this blogpost.

If you regularly open PDF files from untrustworthy sources, it can help to disable JavaScript, but this does not address the root issue, for which Adobe will be issuing new versions of Reader and Acrobat.

Better than disabling JavaScript is to make sure that your security software is updated. The Adobe Security blog has a list of third-party vendors who have already updated their scanners to deal with such malformed PDF.

I do not know whether non-Adobe PDF renderers are vulnerable. I do know that folks within Adobe have agonized about the wait for public information disclosure, and that organizationally we'll be able to move faster in the future, but (as the "disable JS" rumor showed) it's vital to go past the surface issue to the root issue, and it's vital to consult with industry partners to meaningfully improve the security situation.

Anyway, please accept my apologies for the delay, but solid info is now at hand. New software due in 14 days.

Posted by John Dowdell at 7:18 AM | Permalink | Comments (0)

How did the recent "Don't Click" clickjacking attack on Twitter come about? Pretty innocuously, according to this report... a funny hack went viral, and refused to be defused. (I haven't confirmed the author's account, but it seems plausible, and is interesting in its own right.)

"Clickjacking" is when third-party content tricks a webpage visitor into making an undesired click. Complete remedies are difficult, because DHTML added JavaScript page-rewrites, and Web2.0 added unvetted third-party content. Browser makers are now struggling to find ways to guarantee that What You See Is What You Click.

A novel aspect of the Twitter-jacking is that the third-party content was introduced via URL-shortening services. Fixes have been attempted, and rebuffed. Check out the explosive growth in this chart.

This "Don't Click" isn't a serious exploit in itself, but it's a serious step along an existing vulnerability. Stay tuned.

Posted by John Dowdell at 1:14 PM | Permalink | Comments (0)

Excellent security resource here: "2009 CWE/SANS Top 25 Most Dangerous Programming Errors". Lots of apps get burned by improper input validation, SQL injection, cross-site scripting. But it's hard enough to make stuff, much less defend against all the ways to break stuff.

Here's an efficient way to protect yourself. Read through each of the 25 "discussion" paragraphs first, to see the most frequent ways sites are attacked... get the big picture, fast. You can then drill into any particular topic if you want. Very efficiently organized.

Thanks to Brian Prince at eWeek for the tip, in "Keeping an Eye on Adobe Flash Security Means Catching Common Programming Errors". Related recent story: IBM Rational AppScan.

Posted by John Dowdell at 6:39 PM | Permalink | Comments (0)

As computing continually becomes cheaper, and as encryption becomes more efficient, it also becomes easier to guess passwords. That's the takeaway from this security note by John Landwehr of Adobe.

Acrobat 9 features stronger passwords -- longer passwords, Unicode characters -- yet opens encrypted documents much more quickly than before. That's a good thing.

But the speed increase also means it takes hackers less time to scan through a dictionary of common passwords... the faster decryption helps crack marketers. That's not a good thing.

The implications for us?

• If you're choosing a password, it should be more secure than a few years ago. It's getting cheaper to guess simple passwords.
  
• And if you're creating a system which requires a password, and if you can't use server-based authentication for that local file, then requiring some complexity in the reader's password can help protect that document from unauthorized reuse.

A self-contained file which is distributed is difficult to completely protect. Digital encryption helps make it more expensive to crack, but can't protect to the same degree as if that file communicates with your servers before opening. Standalone files can't offer the same security as server-connected files.

But even the difference between an eight-character password and a nine-character password can determine whether it's worth the time of someone to attempt to guess the password which the file includes.

Some tips on password strategy:

• Choose longer passwords, or even entire pass-phrases. (Reader 9 can use up to 127 7-bit characters.)
  
• Avoid words found in dictionaries, common names, etc.
  
• Mix alphabetics with numerics and punctuation.
  
• Remember longer passwords by using a long phrase, interspersed with other characters in a memorable pattern.
  
• Writing passwords on paper is safer with some kind of coding: something you can understand, but which someone who finds the paper cannot.
  
• CERT has more tips, as do others.

It makes sense that faster decryption of documents would be used by hackers too. The passwords we used ten years ago aren't as secure as they were. Perverse, but that's the way it is.

Posted by John Dowdell at 11:59 AM | Permalink | Comments (0)

Not if you're in Player 10, that is.

Newspaper headlines this week urge "Update your Reader 8!" and "Update your Player 9!" Careful readers might notice something odd with this advice....

Why the news cycle? Adobe released new versions of old software this week, for people on locked intranets and others who cannot yet use the current versions. Once even people on locked systems have updates for old versions, at that point we can describe in general terms what was addressed. That new documentation is what's driving the headlines.

(I tried leaving a comment at BetaNews, but after writing it, they told me my email address was already in use. ZDNet also uses a membership system for comments, as do many others. Even the Washington Post now has a membership wall... particularly sad because some pseudonymous commenters there are seeking info about version-detection implementations on some sites. Shouting through the wind is not my strong point, but these simple truths remain.)

If you've got to use old software, then yes, please do use this week's downloads to protect against the later JavaScript intrusions.

But you're already protected if you're using current versions.

I wish the headlines were updated as easily.

Posted by John Dowdell at 8:10 AM | Permalink | Comments (3)

I've written on this before, so will just post a reminder here about how reporters may not always be accurate... PCWorld puts it this way today:

Adobe Systems has released a new version of its Flash Player software, fixing a critical security bug that could make the Internet a dangerous place for Web surfers.

The new Flash Player 10 software, released Wednesday, fixes security flaws in Adobe's multimedia software including bugs that could allow hackers to pull off what's known as a clickjacking attack, wrote Adobe spokesman David Lenoe in a blog posting.

Actually, David wrote nothing of the sort, as you can confirm by following the link which PCWorld (thankfully!) supplied. This is not a security flaw in Flash; there is not a "Flash bug" to fix.

The changes in Player 10 just prevent the browser's existing and unpatched clickjacking flaws from affecting the Flash cam/mic dialog. David doesn't go into details, but it's something like Player calling out beyond the browser to the operating system to make sure Flash's pixels are actually displayed, and the browser isn't letting something else slide in on top to hide the dialog.

Clickjacking is a browser flaw. It is not addressed. (NoScript addresses some implementations but seems a stopgap.) Adobe took the lead in recognizing the issue, and bringing it to the attention of the browser vendors. Adobe has also mitigated the damage the browsers' clickjacking problems can cause for Flash. But that's it -- the core problem still exists.

I'm glad that Adobe folks recognized the issue early, worked collaboratively on it, and have the first minimizations of the exploit path. But I'm not glad that reporters are saying it's a Flash issue, just because other reporters said it was a Flash issue.

In Player 10, the permissions dialog for the webcam can't be hidden by some other browser element, so you can't be fooled into clicking on it. This will soon be rolled into Player 9, too, for those who need it. That's all we did. Until the browsers can assure that what you click is what you think you click, and until websites assure that they're not hosting untrustworthy third-party content, clickjacking in general will still be an issue. Flash is incidental to this whole clickjack story, not its focus.

(That PCWorld article is requesting material from google-analytics.com, quantserve.com, doubleclick.net, yimg.com, digg.com, industrybrains.com, pricegrabber.com, on24.com, and 2mdn.com. The ad networks among them receive files from strangers. Third-party requests like these are not only possible infection vectors for a clickjacking attack, but also enable cross-site surveillance through IP logging. Both browser makers and website owners have work to do to disable clickjacking.)

Posted by John Dowdell at 3:09 PM | Permalink | Comments (3)

Just saw a Friday article in The Register titled "Mystery web attack hijacks your clipboard". The symptom was that someone was surfing and something started perpetually writing his clipboard. Dan Goodwin referenced "sandi" at a MSMVPS.com blog (sorry for not quoting your last name, Sandi, but you don't make it obvious and I didn't remember it), which in turn referenced a number of forum threads which were said to describe the issue.

This forum thread seems to have the most descriptions (possibly of multiple issues), but the screenshots and partial descriptions don't seem to mention any particular SWF at MSNBC.com. As in previous Flash warnings through this venue, it's hard to summarize the main evidence, drawn from various disconnected forum posts. Dan Goodin said Sandi mentioned Flash, but I didn't see where she did (other than with her weblog template about "flash malvertizements"). There's not yet a succinct case.

It's plausible that some webpage has some rogue SWF which acts obnoxiously with the clipboard. Might be a JavaScript thing too. But let's say that there's indeed some rogue browser element which just yak-yak-yaks into your clipboard.

Two questions:
1) How did you get to be executing some logic which acts so obnoxiously?
2) If you're using a browser to surf the web, should strangers have so much power?

(The answers are already here, but let's run it fresh again anyway.... ;-)

How'd some rogue interactivity get into your browser? Probably because of a trustworthy webpage with untrustworthy third-party content. Ad networks are big vectors for third-party resources. Web-based services are another way to introduce third-party scripting into a composite webpage. Even a third-party GIF can no longer be completely trusted. Sandi's page is pretty secure, but even this is executing scripts from three domains... the article at The Register is executing scripts from six different domains.

As Nat Torkington described, if you're republishing third-party JavaScript, even trustworthy sources may prove untrustworthy. If you're accepting interactivity through an ad network, then they don't seem to have formal processes to vet the people they forward to you for republishing.

If you use Firefox and AdBlock Plus, or have another way of inspecting third-party content on webpages, take a look at just how many domains are involved in creating the page you're viewing. Each HTTP request for a GIF or a JavaScript or an RSS or even a ping is registered on a server log at those unanticipated third-party sites, and for interactivity (.SWF, .JS, whatever), your browser will be accepting instructions from parties other than the site you're visiting. Modern sites like TechCrunch invoke dozens of scripts and ping even more domains whenever you visit.

Should webpages have so much power, as to be able to copy to the clipboard? Probably not, because you can't trust everyone else we allow on the network. Early email architects didn't imagine spam, but spam is what we got. If we want to safely click from link to hypertext link on the World Wide Web, the most stable solution is to give the browser experience few privileges.

(The alternative (which failed for Microsoft in the 1990s, and which Google is reviving in a different way with their search warnings) is the concept of giving some groups of publishers greater trust than others, which leads into an additional class of permission-raising exploits, spoofing, and so on, as well as all the subsequent social opposition from the less-privileged classes. In these days, when even your local domain-name server can't always be trusted, favoritism doesn't scale at all well.)

Web browsers need to be able to safely visit any hypertext link, safely execute any instructions they may contain. To gain greater privileges, it seems smarter to use a separate codebase with a more generous sandbox, than it is to set up permission schemes. This is the fundamental reason that I believe the various brands of WWW browsers won't be able to act very much like desktop apps... the needs of visiting any strange site safely conflict directly with the needs to be trusted and powerful parts of your daily environment. Theoretically possible; pragmatically fragile.

Anyway, on this story at The Register, I haven't yet been able to identify the exact situation from the descriptions. Clipboard-spamming does seem a possibility. And the trends of composite webpages with third-party content makes it increasingly difficult for in-browser apps to act like desktop apps.

Summary: This report needs further investigation.

Posted by John Dowdell at 2:06 PM | Permalink | Comments (1)

At ZDNet, Ryan Naraine of security firm Kaspersky Lab advises to doublecheck the links you click in Twitter or weblogs: "A Twitter profile has started lending links with lures to a pornographic video of Brazilian pop star Kelly Key... If you click on the link, you get a window that shows the progress of an automatic download of a so-called new version of Adobe Flash which is supposedly required to watch the video. You end up with a file labeled Adobe Flash (it’s a fake) on your machine. In reality, this is a Trojan downloader that proceeds to download 10 bankers [password-theft malware] onto the infected machine, all of which are disguised as MP3 files."

Bottom line: Clicking on links in social media is like not washing your hands after being out in public -- you just can't know what you will pick up.

The part that worries me the most is the "says it's Adobe Flash" part. We've seen such impersonation before with files ("Naked Wife", eg). But to actually impersonate a very well-known runtime? I'm not sure how that will play out. Some people will fall for it, and I feel for them, but most would see through it. Still, some real people will be hurt.

David Lenoe, from Adobe's Security Team, had a blogpost up about it today. I don't think that the people who need that reminder would ever see it though. I'm still concerned.

Adobe is not directly involved, but the infection relies upon using the existing goodwill towards the overall Adobe Flash ecology... without all those sites which made Flash a standard, this social exploitation would not work. (And Ryan's article doesn't clearly state whether the link is to an .HTM, .EXE, or other file, so it's unclear to me yet whether URL-shortening services are currently enabling the exploit.)

A bigger bottom line: Someone out there in the world is going to get their bank accounts stolen because they saw a dialog that said "Adobe Flash" and they said "Okay". I don't feel right about that.

Do you have thoughts, advice, observations on this? I'm seeking different ways to look at this problem, different approaches we might take. Open to anything, thanks in advance.

Posted by John Dowdell at 7:47 PM | Permalink | Comments (3)

... and a wee little bit of "The Open Web" sandwiched in the middle?

derStandard.at holds an interview with Novell's Miguel de Icaza, about their Mono and Moonlight emulations of Microsoft runtimes for Linux. Miguel also points out the convenient blindspots of those who argue against technology solely on the grounds of "It's not The Open Web":

I mean, how many people outside of the technology world really know about Linux at the moment? And even the Mozilla guys - the keynote we had here was done on a mac, every single Mozilla developer uses a Mac. And it's funny, they constantly attack Silverlight, they constantly attack Flash and then all of them use proprietary operating systems, they don't seem to have a problem doing it. And then they had the Guiness record thing for Firefox 3 and you went to the website and it had a flash map to show where people are downloading - so there definitely is a double standard here. And that's after all their claiming that you can do everything in AJAX - so they definitely don't 'walk the walk'."

If evangelists try to say that practical realworld web technologies can be tossed aside because of alleged philosophical impurity, then why aren't these proselytizers using some type of Linux box, instead of the super-secret tightly-controlled Apple hardware?

And it goes up a level too -- if you're really concerned about open use of the World Wide Web, and are against proprietary secrecy, then wouldn't you avoid accepting primary funding from Google, who has the biggest databases tracking consumer behavior on the Web, and who refuses to allow people to access the files Google holds on them? (If you're not up-to-speed in this area of cross-site tracking via third-party content, then try EFF, Wikipedia, or me.)

When your mortgage is ultimately paid by selling consumers' attention, it's a little disingenuous to throw rocks at others who just sell software.

We accept "proprietary hardware" and "proprietary OS", and run through "proprietary service providers" to bulk up "proprietary ad networks" and "proprietary social services", all to build "proprietary behavioral databases" for a sugardaddy, but dadgum we can't be using no "proprietary plugins", nosir (unless'n they're our "proprietary plugins" that is)!

It's like seeing a supermarket ad for "all natural ingredients"... nice enough at first listening, but just what does it mean? And if you met someone who insisted on eating only "all natural ingredients", but couldn't describe what they were, then that could get more than a little weird too.

I think it makes a lot more sense to just neutrally weigh the benefits and potential risks of various choices, and not to dismiss any choice out-of-hand for religious reasons. But if I were to argue that certain choices may not be tolerated, then I'd likely try to make for some reasonable consistency in that intolerant stance. Why feed Apple below and Google above, if you insist "Flash is subverting 'The Open Web'"...!?

Posted by John Dowdell at 2:42 PM | Permalink | Comments (1)

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.

Posted by John Dowdell at 10:45 AM | Permalink | Comments (2)