Tag Archives: security

HTML5 security

Yesterday, February 24, Ming Chow gave a talk to the ABCD security group at Harvard on HTML5 security. As far as I can tell he hasn’t made any of the content publicly available online, but here are some high points:

  • HTML5 has a lot of new features, giving it a bigger “attack surface.”
  • There’s no effective security to local and session storage, so writing sensitive information there is a bad idea.
  • The database feature raises all the standard concerns about injection of malicious SQL code into fields.
  • Application caches can be written by any website. It may be possible to spoof pages this way.
  • There is now a function, XDomainRequest, in JavaScript, which allows communication between different sites. The receiver of the request must specify Access-Control-Allow-Origin to indicate whose requests are allowed. Wild-carding this allows anyone at all to send data to a page, which may be dangerous. Implementers of a receiver should always verify the sender’s identity.
  • With the audio, video, and canvas tags, the codecs can be vulnerable. Opera has been hit with a heap buffer overflow exploit in HTML5.
  • The noscript tag is no longer supported. Users who try to make themselves safer by disabling Javascript are more screwed than ever.
  • The problems are new, but the approach to safety is the same: common sense, input validation, being careful with unsecured connections, etc.

SourceForge security incident and doppelgänger characters

This morning I got an email from SourceForge saying that all passwords had been reset because of a password sniffing incident. Naturally, I’m suspicious of all email of this kind, but I do have a SourceForge account. So rather than follow any of the links in the mail, I tried to log in normally and found that passwords were in fact reset. I followed the procedure for resetting by email and my account’s working again.

I’m sure some of you reading this also have SourceForge accounts, so this bit of reassurance may be helpful, especially if your phishing filters (philters?) kept you from seeing the notice in the first place. It’s likely some fakers will set up scams to take advantage of this issue, so always go to the SourceForge website by typing in the URL or using a bookmark, rather than by following a link from email. It’s easy to mistake a near-lookalike URL on a quick glance.

Worse yet (yes, this post has something to do with formats), there are now exact lookalike URL’s, thanks to the unfortunate policy of allowing Unicode in URL’s. There are numerous cases where characters in non-English character sets normally look just like letters of the Roman alphabet. Someone could, in principle, register sourceforgе.net, which looks just like sourceforge.net — but do a local text search for “sourceforge” in your browser, and you’ll notice the first “sourceforgе.net” (and this one) are skipped over. The sixth letter isn’t the ASCII letter “e” but the Russian letter “e,” which usually looks the same or very nearly.

If your browser doesn’t have a Cyrillic font, you may be seeing a placeholder glyph instead. Or if it views the page in Latin-1 instead of UTF-8, you may see a Capital D followed by a Greek lower-case mu.

With any email that offers to correct a password issue, exercise extreme caution, even though some are legitimate.

PDF exploit

A number of web sites are talking about a vulnerability in PDF. So far I haven’t found an exact description; anyone who explained it in detail would get the blame for everyone who uses it for malicious purposes. But the idea seems simple enough that anyone with the necessary technical knowledge (including me) could work it out given a little time. Apparently it’s a means by which the user can be presented with a legitimate-looking dialog and tricked into approving the launching of arbitrary executable code. The exploit can be added to an existing PDF without changing its appearance. JavaScript isn’t required. The vulnerability is in the format specification, not in a software bug. This is the really nasty kind of vulnerability that designers have nightmares about.

Here’s an article on CNET on the issue. There seems to be substantive discussion of the root of the problem here. I’ve got to get to work now. I’ll post something more later.

Update: OK, it’s not so bad as it sounded. Here’s the real account, which doesn’t say exactly how to do it, but gives enough clues that it’s not too hard to figure out the rest.

As you might have guessed if you know PDF, it uses the PDF Launch Action. The PDF specification actually doesn’t mandate any safety features in the Launch Action; if you implemented a PDF reader that automatically launched anything a PDF document told you to, you’d be within the spec. But Adobe Reader, exercising normal common sense, prompts the user for permission to launch. The trick is just that the text which describes the application to be launched can be modified. The user still gets a stern warning not to launch anything untrusted.

This trick will doubtless catch some people, as even simpler tricks do (just saying “don’t worry, it’s safe” in the document itself will trick a rather large number of fools). But it isn’t really anything to get hugely worried about.