Archive for the IE Category

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

I'm happy to learn that IE8 is going to implement a less ambitious version of a feature which NoScript users have enjoyed for more than one year now. The announcement posts seem not to notice the resemblances of "XSS Filter" with NoScript's Anti-XSS Protection, the most striking being their non-blocking approach: loading the target page in a "neutralized" form and emitting a warning as an info-bar, which doesn't require interaction and therefore doesn't necessarily interrupt user's workflow. But that's fine: in facts, under the hood, their filter looks quite less sophisticated than NoScript's InjectionChecker engine, as it is based on a limited blacklist, apparently targeted to the most common reflective XSS attack patterns as seen in proofs of concept:


The XSS Filter defends against the most common XSS attacks but it is not, and will never be, an XSS panacea. [...]
The fact that our filter effectively blocks the common "><script>"… pattern we see most frequently in Type-1 XSS attacks is inherently a step forward. Pushing that further and blocking other common cases of reflected XSS where possible, as the XSS Filter does, is extra goodness.
Caveats aside, it will be great to see the tens of thousands of publicly disclosed Type-1 XSS vulnerabilities indexed on sites like XSSed.com simply stop working in IE8.

And there I started smiling: you realize, guys, that those listed "on sites like XSSed.com" are not "XSS vulnerabilities" which will "stop working in IE8", but just minimal exploit test cases --

<script>alert("XSS")<script>

-- which can be refactored and obfuscated in endless ways to obtain the "IE8 compatible" certification. Yeah, it will be great to see.

Anyway, such a feature being deployed as a built in of a popular browser, rather than as an add-on for an awesome browser, will likely keep script kiddies busy for a while, maybe taking a filter evasion crash course. I just hope it won't give some site owners an alibi not to fix their bugs, though, putting a "This site is best viewed with IE8" badge near to their McAfee Hackersafe logo.

Final thought: echoing the news on his blog, RSnake did swiftly mention NoScript (thanks), but at the end of that post, calling for adoption of his own bright Content Restrictions idea, he forgot to say that one (experimental) implementation already exists... Do these cross-site scripting filters suppress legitimate cross-site references as well? ;)

Share of most secure browser versionsAccording to an independent study by Google Switzerland, IBM Internet Security Systems and CSG ETH Zurich, Mozilla Firefox users are the safest among web surfers (on average), because they are more likely to be running the latest and most secure version of their browser.
This research analyzed the user agent headers sent with Google search queries beetween January 2007 and June 2008 (lots of data points!), finding that more than 83% of the surveyed Firefox browsers were up-to-date. Safari scored 65.3%, Opera 58.1% and IE, not surprising, was the worst with 47.6% (it should be noticed, though, that IE6 has been considered, rightly, an "insecure version").

The most important factor in this achievement is probably Firefox's streamlined patching process, which is painless and hard to avoid: in facts, security updates are downloaded in background and proposed to the user as soon as they're ready. He can refuse installing (e.g. not to interrupt his work), but as soon as the browser restarts they get installed nonetheless.
There's obviously room for improvement. For instance, upgrading requires administrative privileges. Therefore, a warning to low-permissions users saying something like "You're running an outdated version of Firefox, please ask your administrator to upgrade" would be helpful. But even so, Firefox already shows a stunning lead over its competitors.

One of the declared limits of this study is that nothing could be said about browser plugins, universally recognized as an endless source of security pain. Even on this side, though, Firefox has some clear advantages: plugins can be disabled either manually, from the Tools|Add-Ons|Plugins panel, or automatically through a centralized blacklist. Last but not least, if you're really security minded, you can always adopt a whitelist approach.

After hearing me crying for help, my friend Sirdarckcat went hunting and entrapped a poltergeist which haunts IE only.

Is it this the one Manuel Caballero was talking about?
Or was that a different cross-browser evilness?

However, I ain't afraid of no ghosts :)

Casper on PaypalI would be very interested in learning some technical details of Manuel Caballero's talk at BlueHat, titled A Resident in My Domain, but so far news are very scarce, fragmented and contradictory.

Its abstract is intriguing:

A Resident in My Domain

Do you believe in ghosts? Imagine an invisible script that silently follows you while you surf, even after changing the URL 1,000 times and you are feeling completely safe. Now imagine that the ghost is able to see everything you do, including what you are surfing and what you are typing (passwords included), and even guess your next move.

No downloading required, no user confirmation, no ActiveX. In other words: no strings attached. We will examine the power of a resident script and the power of a global cross-domain. Also, we will go through the steps of how to find cross-domains and resident scripts.

Then we've got two quite reticent posts by Nate McFeters, who was there but pretends he doesn't remember well enough and/or he can't disclose such an atomic bomb ;)

There's some discussion at TSSCI, but it adds more questions than answers: the article devises similarities with two distinct old and fixed bugs, the nastier affecting IE and the other Firefox; some comments speculate about an IE7 only, possibly patched, vulnerability; but why so much secretiveness if it was already fixed?
Nate, on the other hand, wrote that this is "a horribly serious issue that affects all browsers and is currently not fixed on any of them".

Direct inquiries in security circles I'm member of did not bring anything less ectoplasmic on the table.

Therefore, all the juice we've got so far is a couple of photos authorizing only the following statements:

  1. It is scary.
  2. It has something to do with JavaScript and IFrames.
  3. It definitely works in IE7.

If you can summon anything useful, you're very welcome!

Bad Behavior has blocked 2242 access attempts in the last 7 days.