hackademix.net

Latest updates from Microsoft: the critical remote execution bug which we already talked about affects all IE versions (included IE8 beta) on every supported Windows operating system.
The bulletin also corrects some early assumptions about this unpatched vulnerability, which is being actively exploited in the wild from apparently legitimate sites infected through automated SQL injections:

• The hole is in data binding, and not in XML processing like many (me too) reported initially.
• Increasing the security level of the Internet Zone to “High” and disabling active scripting does not suffice to protect you, even if it makes attacker’s life slightly harder. Not harder than yours, though, since Microsoft’s “Security Zones” have nothing of NoScript’s usability…

The only work-around suggested by Microsoft is disabling both active scripting and the OLEDB32 library, which is unluckily required by most applications working with databases.

So, do you really want to keep inflicting yourself that blue “e”? Or are you ready for a red panda?

You may have heard of Microsoft Update’s debacle past Tuesday, with two critical Windows vulnerabilities disclosed when it was too late for this patching cycle:

• A flaw affecting the Word97 converter for WordPad on Windows XP SP2 and below, which is exploited by enticing users into opening a document with “.wri” file extension.
• A juicier bug in Internet Explorer 7’s XML parser, any version, related to data binding, affecting all recent Windows operating systems up to Windows 2008 and Vista SP1. It is exploited automatically, without user intervention, to execute arbitrary code from malicious web sites.

I said “is exploited“, rather than “can be exploited”, because both these 0 day vulnerabilities are being actively exploited in the wild.
I also deleted “malicious” near “web sites”, because exploits for the latter vulnerability are being massively infiltrated inside legit web sites using automated SQL injection attacks.
Give yourself a Christmas gift: if there’s a best moment for switching to a safe or to a safer browser, that’s now.

During the past few days I’ve been repeatedly asked the same question:

Is there anything that users of IE, Chrome and other browsers (who cannot use NoScript) can do to protect themselves from clickjacking?

If you read my previous post about it, you already know that currently the only way to protect yourself is disabling JavaScript, plugins/ActiveX and IFRAMEs.
NoScript is the most elegant and usable solution to do it for browsers based on Mozilla technology (like Firefox), because it gives you a quick one-click way to enable the missing technologies on sites you trust and remembers your choices in a whitelist, becoming almost unnoticeable after some “training” about your surfing habits.

Unfortunately, this is not as easy, bearable or even feasible if you use a browser not supported by NoScript (other than Linx or Elinks).
Let’s see what you can do with IE, Safari, Chrome and Opera:

• Internet Explorer

  Open Internet Options|Security, select the “Internet” zone and set the “Security level for this zone” control to “High”.
  Bad news: there’s no apparent way to disable IFRAMEs in IE: you can just disable “Launching programs and files in IFRAME”, which is definitely not enough to prevent clickjacking.
  Furthermore, while Microsoft’s “Internet Zones” can allow individual sites for scripting or active content, their usability is extremely poor if compared to NoScript, requiring several clicks and typing to build a whitelist. So, to recap: MSIE can’t be secured 100% against clickjacking, and the protection you can get comes with a big usability cost.

• Safari

  Apple’s browser has a central place to disable active content in its Preferences|Security tab.
  Bad news here are two: there’s no mean to enable features selectively (per site), and IFRAMEs cannot be disabled in any apparent way (Mac users, please let me know if I’m missing something¹). Therefore Safari can’t be secured 100% against clickjacking, and the protection you can get comes with an enormous usability cost.

• Chrome

  If you’re a Chrome user, you’re really out of luck: the only apparent way to disable active content is starting the browser with the following command line:

  chrome.exe -disable-javascript -disable-java -disable-plugins
  

  Of course, you cannot enable back any of these features until you restart your browser with different command line arguments. Even worse, there’s no “-disable-iframe” option. So Chrome can’t be secured 100% against clickjacking, and the protection you can get comes with the worst usability cost.

• Opera

  Opera has the best built-in security user interface among browsers, very similar to NoScript’s concepts: you can set restrictive defaults if you want, and relax some restrictions on selected sites you trust, using Site Preferences and Quick Preferences. It’s just slightly less usable than NoScript, and it can be configured to prevent clickjacking: you need to disable everything you can see in Preferences|Advanced|Content, then enter opera:config in your address bar, click the “Extensions” handle and uncheck the “IFrames” line.

Final note: current NoScript development versions (1.8.1.7 and above) provide protection against IFRAME-based clickjacking even without disabling IFRAMEs. This is a further usability/security advantage over any other solution, and it’s being tested by Sirdarckcat (a pioneer of malicious CSS overlays) with a final stable released planned for the end of this week. Therefore, if you can choose, your best usability+security choice is still Firefox+NoScript.

Proof of concept:

1. Disable IE7’s Protected Mode
2. …

OK, I was just joking.

I’m confident this blog post is a joke as well.
After all, its author is a MVP…

As you’ve probably heard, the Firefox Summit 2008, albeit great for meeting face to face people I only knew through IRC or Bugzilla, has been quite challenging:

1. Besieged by bears
2. Cut away from the rest of the world by a crash bug in the Whistler-Vancouver communication module
3. Lost in the dark because of a truck-based DOS attack

We must all thank Dan Portillo for the (much) good of the Summit he masterly organized and the great job he made in working around the issues listed above, but on the other hand they might have been prevented perhaps by choosing a less hazardous place, since “Whistler” was the code-name for Microsoft Windows XP…

However, when yesterday night, after a 36 hours trip, I was finally back in Palermo believing it was all over, I went to get back my baggage — including most of my t-shirts, 3 pants, 9 bottles of maple syrup for my relatives and friends — but… it obviously wasn’t there. OK, I should have expected some problems since I packed also one leg of Wladimir Palant’s, which I had to smoke (on pure maple wood) the day of the power outage, before it started smelling inside my useless fridge.
After waiting about one hour because nobody in the airport could say if the unloading operations were done or not yet (what about implementing a callback architecture or a notification bus?), I had to formally claim it lost and was given a link to a website for tracking the baggage recovery process.

So this morning I tried submitting this form, but I got redirected to a page showing the following error message:

Il sistema non può indviduare* una lima valida per la vostra entrata.

For those who don’t speak Italian (like the author this disturbing text, I hope), this sounds like

The system cannot find a rasp suitable for your entrance.

As you can imagine, I was quite glad the system couldn’t ;)
Nonetheless, I still needed to know about the destiny of my baggage, so I retried on a clean profile: same result!
In the end I reluctantly switched the rendering engine through the IE Tab extension, and the system finally decided to be more collaborative: it reported there was no available tracking info yet, but at least it stopped threatening “my entrance” with steel tools.

At that point I checked all the browsers I’ve got at hand, with the following results:

• Gecko-based: RASP
• IE: OK
• Linx: RASP
• Opera: OK
• Safari: RASP

Before you ask, yes I tried to fake my headers via the User Agent Switcher extension.
Any clue?

* this misspelling seems even to rule out a machine translation with no human intervention