Posts in Category "Privacy & Security"

Two security notes

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.)

Acrobat Security update

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.

Clickjacking awareness

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.

Concise bulletproofing guide

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.

Encryption perversity

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.

No need to update

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.

Clickjacking, reporters

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.)

Clipboard pollution

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.

Software Impersonation

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.

Closed above, closed below…

… 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’”…!?