Everything In Between

Clickjacking or, more formally, user interface redressing, is a class of security vulnerabilities similar to phishing scams. The technique uses web standards to trick unsuspecting victims into performing actions they were not intending to.

Clickjacking does not rely on bugs in any software. Instead, the technique is simply an abuse of the growing graphical capabilities that advanced web standards like CSS provide to web browsers. A good introduction to clickjacking is provided by Steve Gibson and Leo Laporte on their Security Now! podcast.

As far as I’m aware, only Firefox when combined with the NoScript add-on and Internet Explorer when combined with the GuardedID product provide any measure of protection against clickjacking attacks. To date no other browser can detect, alert, or otherwise help you to avoid or mitigate the risks of clickjacking attacks.

That said, there’s gotta be something users of other browsers can do. Well, it may not be as much as what NoScript can do, but there is something: use a user style sheet to help expose common clickjacking attack attempts.

clickjane.css helps detect clickjacking attacks for all browsers

Until browser manufacturers provide built-in protections against clickjacking attacks in their software (which is arguably the best place for such logic in the first place), I’ve started putting together a user style sheet I’m calling clickjane.css that attempts to instantly reveal common clickjacking attempts. Since it’s a CSS user style sheet, this approach should be cross-browser compatible so that users of any browser including Safari, Opera, and other browsers that don’t have other means of protecting against clickjacking attacks can use it.

I’ve only recently learned about this class of exploits and so I’m not supremely well-informed on the topic. As a result, the clickjane.css file is relatively sparse and currently only reveals what I’m sure is a small set of clickjacking attmpts. However, as I research the topic further and learn more about the actual underlying HTML and CSS that clickjacking uses, I’ll be updating the clickjane.css code to reveal those attempts as well.

Naturally, contributions and assistance in any form are most welcome! Learn more about clickjane.css as well as how to use it at the Clickjane CSS Github wiki.

Before and after clickjane.css

Here are two example screenshots of a benign clickjacking demo.

1. Before:
   

   Screenshot of Safari before clickjane.css is used to expose clickjacking attempts.

2. After:
   

   Screenshot of Safari after clickjane.css is used to expose clickjacking attempts.

Good habits you should get into to mitigate clickjacking risks

Here is a list of behaviors that you should make habitual while you browse the web. Engaging in these behaviors can dramatically reduce the likelihood that you will be victimized by a clickjacking attack.

• Explicitly log out of any service you have logged in to when you are done. That log-out button is there for a reason: use it!
• Avoid providing your browser with “Auto-Complete” information for critical sites, such as your bank.
• Make sure you are running Flash Player 10 or greater, which mitigates this vulnerability for Adobe Flash content.

More resources to learn about clickjacking

• Hackademix.net – More clickjacking links to the OWASP presentation, the white paper, and a blog post showing several CSS-based exploits.

Creative agency management tool company Workamajig.com is a sizable operation with an international client base. Their product used to be called “Creative Manager Pro” which I can only assume they changed because it wasn’t actually creative enough. Anyway, it turns out that Workamajig has what is without doubt the absolute worst error message I can possibly think of from a security standpoint.

The error, which is triggered on login regardless of whether or not the username and password you enter are correct (presumably because the issue occurs while trying to authenticate), displays the username and the password the user has entered in cleartext and then (as if that wasn’t bad enough) encourages the user to email this information to their support department!

Yes, we have made the company aware of the problem. No, they have not fixed it yet. Proof in the form of a screen capture from literally 10 minutes ago:

Workamajig.com login error echoes the entered password in cleartext and encourages the user to send this to their support via email.

No, these are not real credentials, but an uninformed user may very well enter access credentials that are valid. Since this issue is not triggered by invalid credentials, that means valid login information for god knows how many Workamajig user accounts is very likely sitting in the SMTP logs of countless mail servers. Since in many countries these logs are federally mandated to be saved for at least two years, if I were a user of Workamajig I would seriously consider changing my account password ASAP, as well as changing any other account that I used the same password for!

I can’t be sure from this screen shot, but I sincerely hope that user’s passwords are passed around in the application as well as stored on disk as salted cryptographic hashes. Of course, after seeing this, I wouldn’t be shocked if that wasn’t the case. The good news is that the login screen to their application is only accessible with an SSL/TLS connection, which does prevent someone from snooping on the wire. Nevertheless, there are still many attack vectors that SSL/TLS doesn’t protect against if the rest of the application is not secure or, say, if you’re encouraged to bypass those protections by sending emails with sensitive data in order to request technical support.

Anyway, hopefully this gets fixed sooner rather than later. At the very least, don’t encourage users to email cleartext passwords. That is pretty much always a Very Bad Thing.

Update: It took only a couple of days for Workamajig to notice this blog post, which is great because it means I woke up to a forwarded email in my inbox in which a Workamajig representative said:

On the issue of showing the user id and password in an error message, [we] will be changing the way that error message is displayed. […] Just to clarify the user id and password is just on the screen of the user that is logged in, and that message to copy and paste is a standard messages and it is just intended for you to copy and paste the error message; you are not required to send the user id and password.

I haven’t encountered the same issue again (but then again I only tried to login to my account twice in between then and now), so I can’t verify that the error message really has changed but I’d give Workamajig the benefit of the doubt. If you’re using Workamajig and notice a change in the way this login error is handled before I do, leave a comment to let me know it’s really been changed.

Nary a day goes by when I don’t use my computer for some extremely personal stuff. I would consider it a Very Bad Thing if some of this information (my bank account details or private SSH keys, for instance) fell out of my control.

Everyone has sensitive files that they keep on their computer and, fortunately for Mac OS X Users, Apple has made it ridiculously easy to create a cryptographically secure containers for such files. You can think of a container like this, which is just a standard Mac OS X disk image (.dmg) file, like a vault that you open, put stuff you want to keep safe inside, and then close again.

Here’s how you go about making and using one.

Create the container, an encrypted disk image

1. First, open up your copy of Disk Utility.app, which is located in your computer’s /Applications/Utilities folder. (As an aside, this program is a bit like a swiss army knife for handling disk operations in Mac OS X. You should definitely find out what else it can do).
2. Next, select the File → New → Blank Disk Image… option. This will cause the New Blank Image window to appear.
3. Fill in the typical details such as the disk image file’s name and where you want to save it to. In addition, you’ll be presented with a number of options such as Volume Name, Volume Size, and Image Format. The defaults are usually adequate except for Volume Name, which you should customize so that when you mount the disk image the disk label is meaningful for you, and the Image Format, which I recommend you switch to “sparse disk image.”

   Sparse disk images can start small and grow automatically as you write more files into them. If what you want to keep secure in this manner are very large files, say gigantic high resolution PhotoShop documents, then you might consider the sparse bundle disk image format instead.

   Also, obviously, set the Encryption to a value other than “None.”

   Here’s an example screenshot from my Mac:

   

   Screenshot of the New Blank Image window showing meaningful values entered, Encryption field set to 128-bit, and Image Format field set to sparse disk image.

4. Press the “Create” button and you’ll be presented with a standard password selection dialogue. This is the password you’ll use to mount the disk image and is analogous to the idea of setting the combination on your vault’s lock. It’s critical that the password you choose is a good one. Ideally, your password is a totally random string that may include any printable character. Since that’s hard to remember, you can have the Mac OS X keychain manage your passwords for you.

Encrypt some files by writing them to the disk image

Now that you have an encrypted disk image, a secure container for your sensitive data, you can make use of it just as you might any other disk image on Mac OS X. For instance, say I have a top secret file called “My Killer Business Plan.pages” and I don’t want anyone to get at it. All I need to do is copy the file into my encrypted disk image, as the following screenshot shows:

It should go without saying that you want to delete the original, unencrypted copy of the file you’re copying into the encrypted disk image, but I’ll say that anyway. Don’t leave unprotected copies of your files lying around. Also, be certain to unmount (eject) the disk image when you’re done using it because the only thing the password protects is opening the disk image, not the files contained within it.

External references

Here are some additional places where this technique is discussed. Check out these additional articles about this topic elsewhere for more information and other perspectives:

• Mac OS X: How to create a password-protected (encrypted) disk image
• Mac OS X: About Encrypted Disk Images
• MacOSXHints.com: Create an encrypted disk image that grows as required

In some communities, this is sort of old news, however I’ve recently become aware of an exciting and affordable security product called the YubiKey, manufactured by Yubico. The YubiKey is a $35 USD one-time password second-factor authentication token that uses 128-bit AES encryption to provide identity verification. That’s a mouthful, but what it really means is this: using a YubiKey to log in to stuff makes your logins about as secure as a military installation. Here’s how.

When you log in to just about any Web site or Internet-enabled service, say Basecamp for example, you traditionally simply type in a user name and matching password. This is known as one-factor authentication because all you need to do to log in successfully is use a matching pair of user names and their passwords. Since the user name is not hidden, the only piece of the puzzle that’s providing any security is your password.

Now, a password is something you have to remember, so this factor is called "something you know." Of course, if someone else also knows your password, this means that person can log in pretending to be you. Thus enters the need for a second factor for authentication.

The YubiKey is a physical USB fob device with a unique ID. That is, each YubiKey in the world has its own ID, meaning that no two are identical. This implies that if you have a YubiKey with you, no one else can have that same YubiKey anywhere else in the universe. Thus, this gives you a second factor with which to authenticate yourself, specifically it’s "something you have."

When you combine something you know (for instance, a password) with something you have (such as a YubiKey), you have two-factor authentication. Authenticating yourself with both of these factors is obviously more secure than relying solely on one factor because in order to compromise it an attacker needs to compromise both factors; the attacker would need to know what you know (figure out your password) and steal something you have (physically obtain your YubiKey).

If you’re familiar with one-time credit cards such as those that PayPal offers, you can think of the YubiKey like one of these cards, but instead of being used to make online purchases, it’s used for logging into stuff (and, of course, you don’t need more than one physical YubiKey). Of course, for authentication to work with the YubiKey the application or service you are logging into has to be able to understand that you’re using one of these authentication devices.

The good news here is that the entire process of using a YubiKey is a well-documented, open-source, and open-spec scheme so it’s easy for service providers to implement. And, because Yubico is also an OpenID identity provider, you can use your YubiKey to log into any site that supports the OpenID protocol right now, such as (you guessed it) Basecamp! There’s even a WordPress YubiKey plugin so you could theoretically use your YubiKey to secure your authentication to any of your WordPress blogs.

The YubiKey spec is, itself, completely independant of the OpenID spec and vice versa, which is what makes the combination so formidable. What’s so cool about this process is that the site you’re authenticating to, such as Basecamp or your WordPress blog, doesn’t have to know anything about how you’re authenticating because the OpenID provider (Yubico in this example) simply returns the answer—a perfect example of a well-constructed API at work. Either you have successfully authenticated to your OpenID provider or you haven’t, and the site can respond accordingly.

And if that’s not cool enough, want to know the coolest thing about the YubiKey? It’s environmentally friendly! The YubiKey web site states that the robust, ultra-thin and battery-free design increases lifetime and reduces environmental impact.

I’m more than seriously considering getting one of these myself, and even beyond that, getting one for all of my fellow site editors on some of the community web sites I help maintain. This is especially important for sites dealing in confidential or otherwise sensitive information, such as those which hold financial records or have other privacy concerns. Securing the authentication of privileged users such as the site administrators seems a natural step.

Even better yet, because the only cost to implementing this system is developer resources and the cost of the physical YubiKey device, I’m also seriously considering baking this right into any new sites I develop. At $35, a YubiKey is actually cheaper than an SSL certificate, and even though they don’t protect against all the same attack vectors, I think a device like the YubiKey is clearly a vastly superior solution in the majority of use cases.

I never really had a compelling reason to begin to propagate an OpenID identity before but now, at last, I do.

Security provisions are one of those “things” that Mac users have been snooty about—for good reason—for decades. However, I’d dare say that, even though the UNIX architecture of the underpinnings of Mac OS X is much more secure than most other popular operating systems (cough, Windows, cough), much of the security benefits that Mac users have enjoyed are really security-by-obscurity, which is not very secure at all. With the added popularity of Mac OS X, lots of responsibility suddenly shifts from the vendor (Apple, Inc.) to the individual users (this means you) to keep your data secure.

Apple has been on point, however, providing good security utilities built right into the operating system and easily available to end users. Of most common use is probably “Secure Empty Trash” which securely deletes files that you put into the trash. The counterpart to this function available in the Finder is, too few Mac users know, the srm or secure remove command-line utility.

srm can be thought of as simply a version of rm that overwrites file data before unlinking it from the file system. It comes with a few more options than rm comes with all geared towards tweaking just how it overwrites files. My favorite is -m, which the manual page says:

overwrite the file with 7 US DoD compliant passes (0xF6, 0×00, 0xFF, random, 0×00, 0xFF, random)

I had the perfect occasion to use srm today: I was transporting my SSH private key from one laptop to another via a temporary drive. I wanted to securely remove all traces of the private key file from the temporary drive after installing it in the new computer. (See this SSH public key tutorial if you don’t know why this might be important.)

After copying the private key file over, removing it securely looks like this:

srm -m private_key_file

It’s that easy.

To be confident that your file is truly overwritten with garbage, you can use the -n option. This is one way to retain a file, but completely corrupt it. Observe:

Meitar:~ meitar$ cat testfile
Hello world.
Meitar:~ meitar$ srm -mn testfile
Meitar:~ meitar$ cat testfile
?
 ?)c?I
      P?Meitar:~ meitar$

That garbage you see after the second invocation of cat shows that the file really was trashed, that is, overwritten with garbage data. Now, a simple rm testfile can do the rest of the work.

As always, man srm will give you all the other juicy details.

Since Mac OS X 10.2 Jaguar, Mac users have been accustomed to the ease of use of Apple’s very cool Keychain Services technology. The Mac OS X Keychain basically a secure database of all your passwords, sorted into files called (unsurprisingly enough) “keychains.” Each user account on a Mac OS X system has a login.keychain, and the system itself also has a system.keychain.

Whenever you tell an application to “Remember this password in my keychain,” what you’re doing is writing a new encrypted entry into your user account’s ~/Library/Keychains/login.keychain file. Then, the next time the application needs to access a restricted resource, it just asks Mac OS X to get the password for it. Of course, all of this happens automatically, so except for that single checkbox most users probably don’t know that the keychain even exists.

What’s even more awesome than all of this automagic password storing action, though, is the fact that Apple has also provided an easy-to-use application to manipulate the keychain yourself. What good does this do us? Plenty! Observe.

Say you’ve just signed up with a new ISP. They send you a username and a password to log on to their ADSL network with. Of course, they send this password to you on paper—how insecure! Instead, after changing the password to something else first (something other than mypassword, which is the example password I’ll use here), we can use Mac OS X Keychain to securely store the password and retrieve it later.

1. First, launch the Keychain Access application located in the /Applications/Utilities folder of your startup drive.
2. Next, click the “Create a new Keychain item” button (the +) button near the lower left-hand corner of the window. The Add Keychain Item sheet appears.
3. Enter a meaningful name, such as “ADSL ISP Account” in my example, in the Keychain Item Name field.
4. Enter the username or account name associated with this password in the Account Name field.
5. Enter the password into the Password field.
6. Click the Add button.

That’s all there is to it. To later retrieve your password if, say, you ever forget it:

1. Launch the Keychain Access application.
2. Locate and double-click the keychain item that stores the account and password information you want to retrieve.
3. Tick the “Show password” checkbox. You’ll be presented with a dialogue box that asks for your keychain’s master password. Unless you’ve already set it to something else, this is the same password you use to log in to your Mac OS X user account.
4. Enter your keychain password and click “Allow.” If you click “Always Allow” instead, Keychain Access will not prompt you for your login keychain’s password the next time you ask to see this particular password. I never press that button.
5. Your password’s plaintext is now visible.

This effectively obviates the need for third-party applications such as Password Gorilla, PasswordWallet or KeePassX which are great programs, but all suffer from a lack of a good user interface. Furthermore, there’s no reason why we can’t store short arbitrary strings of sensitive information in the keychain temporarily. Sure, it might clutter up your keychain, but you can always search the entries using the standard Mac OS X filter search bar at the top right of the window.

In fact, Apple’s been kind enough to offer an interface to do just that in an even more effective way, called Secure Notes. These are simply plain text strings of arbitrary length that can be stored securely inside your keychain, and that use the same interface to access (requiring your password to view). The only real difference is that instead of a single line, you’re given a fully scrollable text area in which to type your secure note.

Moreover, because keychains can be synced to multiple Macs with .Mac Sync (or a third-party synchronization solution), you can always have access to all your passwords regardless of which physical Mac you’re using. Best of all, since you never have to remember another password ever again, you can quit using the same password for multiple accounts, and you can always use really hard-to-crack passwords.

If you are wondering why it seems that everyone today is so defensive, you need look no further than your own television set, or newspaper. Bruce Schneier says it best: stop the war on different. And, going hand-in-hand with that slogan: refuse to be terrorized.

This is already horribly old news, and by old I mean several days ago since that’s about as fast as it takes technology news to grow old, but Apple is releasing Mac OS X 10.5 “Leopard” at the end of this month. Apple is calling this release a “major upgrade,” and indeed Apple has rarely made its users wait so long between operating system releases as they have done between Tiger (Mac OS X 10.4) and Leopard. So, I’m already excited.

But then today I was glossing over Apple’s featured features list and I got even more excited. There are the usual, largely meaningless, fluff updates that are nice for Joe Schmo or his mother, but that power users simply don’t care about, like the new iChat support for animated buddy icons, but the list is also chock-full of really cool, really useful features.

What’s interesting is that a good deal of these features aren’t really new features at all. For instance, if you knew how to manipulate the NetInfo database on your Mac, you could already share any folder via Apple’s “Personal File Sharing” feature. (Here’s a Mac OS X Hints hint explaining how to do it.) In Leopard, however, Apple claims that this functionality is now integrated straight into a folder’s Get Info… window. If it works as smoothly as Apple claims, this is finally going to bring Mac OS X (client) into decent competition with Windows XP Professional in terms of GUI-level power-user features.

However, while all of these features are really cool, here’s a list of the ten geekiest features I will probably absolutely love, for one reason or another.

• Ruby on Rails, out of the box — The hot thing in web development right now is Ruby on Rails. Macs have already been the best personal desktop and web development platform because they have built-in support for the Apache web server and a host of other features, but now they will come with a ready-to-roll installation of Ruby on Rails, sporting Mongrel and (better yet) Capistrano! Specifically with the addition of Capistrano, which is terribly undersold as simply a Ruby on Rails deployment platform, these UNIX-y “toolbox” items are bound to make Macs that much more useful right out of the box.
• Safari’s full history search — As their recent public partnerships with Google have shown, Apple is very clearly invested in search technologies. Spotlight gets a huge number of improvements in Leopard, but none which I think are going to be more useful to more people than this one: spotlight searches on the full text of each web page in your visited history list. That’s just awesome. Also awesome: using spotlight as a calculator and as a dictionary, which also shows just how Google-like Apple is trying to be. (Google also lets you ask it arithmetic questions and a dictionary.)
• Wikipedia articles in Dictionary.app — I love Wikipedia because it’s one of the fastest ways to get (relatively) reliable information quickly. Now that Dictionary.app has built-in integration with Wikipedia, imagine the possibilities for getting that knowledge instant-gratification craving fixed. Apple has not yet announced this capability, but I can easily envision a scenario where all Cocoa text fields are instantly “wikified” (with text that matches Wikipedia articles highlighted) much in the same way that current Cocoa text fields allow you to right-click on a misspelled word and have it corrected by Dictionary.app.
• Application-based firewall — In classic Apple fashion, functionality that was previously available via third-party additions is now available from Apple itself. In this case, I have to wonder how well Apple’s updates to its firewall will obviate the need for Little Snitch, which is basically an application-based firewall, too, and a good one at that.
• Built-in guest log-in account — If you’re as paranoid about security as I am, you’ve already created a special, limited-access user on your system (called Guest or Visitor or whatever) and whenever friends are over, you tell them to use that account instead of your own. Now in Leopard, Apple has gone through the trouble of setting this up for us already. A small change that is going to have a big impact.
• Scriptable System Preferences & applications — With AppleScript, you can automate the things your computer does with scripts, as long as those things are “scriptable.” In previous versions of Mac OS X, huge gaping holes of what things shipped by Apple were scriptable existed, causing me (personally) some really annoying headaches. AppleScript GUI scripting helped me get around many of those roadblocks, but now it seems Apple is finally filling in some of the most notorious gaps in this functionality with scriptable System Preferences. Yay!
• Automator workflow variables — Automator brings the power of AppleScript I just mentioned to more people with a completely graphic programming environment. There is no need to open up a text document and write AppleScript code because Automator lets you create a script (called a Workflow in Automator jargon) using your mouse by dragging and dropping actions into the order you want them to be performed. It’s very slick, but until now it’s been very limited. With Leopard, Apple is beefing up Automator so that it includes things like variables, basic programmatic capability that was sorely lacking before. (Also majorly cool: a command-line utility to access Automator!)
• Finder.app’s path bar — Every serious Mac user knows that the Finder needs a lot of help. Now, it’s getting some. Something the Windows Explorer has had forever (as had every desktop environment for Linux, of course) is a visual cue to show you where in your filesystem tree a given folder is located when you are viewing said folder. Now the Finder gains this capability (though Apple’s description implies that it’s going to be off by default) with what Apple is calling a “Path Bar”. Finally!
• Cocoa and scripting bridges — Even though no one really seems to know about it, it has long been possible for languages other than AppleScript to do things like send Apple Events to Mac OS X applications. Specifically, Ruby and JavaScript, two of the most well-known web development languages in existence, can already do this with a single ScriptingAddition (OSAX). But now Apple is making this functionality a central feature and fully extending it to their Objective-C (and Cocoa) language and applications such as Xcode and Interface Builder. This means people like me will have a shallower learning curve before we’re able to create full-fledged, native Mac OS X applications. Now that’s exciting!
• Xcode 3 refactoring — This is something you kind of have to see to believe. I got the opportunity to see it demoed at Apple’s Leopard Tech Talks last year and I was really excited by it. With the new Xcode, Apple’s development IDE, you can do away with find-and-replace searches for things like renaming functions because Xcode understands what parts of your code are what structures and, when you tell it to “change the function named myFunction to myNewFunction,” it’ll only find-and-replace function names instead of every instance of the string “myFunction.” That’s pretty big, and if it were available for more languages, it’s almost enough to make me ditch vim.

So there you have it. Ten features you might not have already known about that are some of the most promising features I can see in Leopard. And I didn’t even get into Wide-Area Bonjour, which could make services like DynDNS or No-IP a thing of the past (and which I still want to learn more about), or the new Terminal application (finally with tabs!), or even the multiple user certificates for S/MIME encrypted email.

Note: One of the least known security features available on Mac OS X is also possibly one of the best, and the simplest. Evidently, all Intel-based Macs are shipped with the XD (aka. NX, aka. DEP) bit turned on—and thankfully there doesn’t seem to be any way for users to turn it off. However, this isn’t a silver bullet and if you want to learn why you should check out this excellent Anandtech article: A Bit About the NX Bit.

I have the simplest personal email spam solution in the world. I use Apple’s Address Book and, in it, I keep all the email addresses I ever want to get mail from. In Apple’s Mail program, I simply tell it that email from an address in my address book is exempt from being treated as junk mail. Then I set up a Mail rule that says if the sender is not in my address book, the message should be moved to the Junk Mail folder.

Voila. This system is flawless. You will never be able to send me loads of spam that go anywhere but my spam box, and I hardly ever look in there.

Naturally, there is a caveat to using this technique, but I actually consider it to be an advantage. By necessity, this technique, keeps me pro-active about getting people’s contact information when I meet them (and want to talk again). If I don’t get that person’s email address, I’ll probably never see that person’s email unless I’m looking out for it. Nine times out of ten, however, that’s what I want to have happen anyway.

So this solves the problem of unwanted mail. However, what if I want to let people contact me that I don’t know ahead of time or have previous whitelisted? Well, in that case I rely on an out-of-band communication, such as an introduction from a friend, leaving a comment on my blog(s), or some other method such as an instant message to let me know that there is someone who wants to talk to me.

My contact information is so available (in so many places), and many IM services are now equipped with store-and-forward messaging that there really is no reason for email to be the first time I hear from someone. Even better, if I’m contacted over Google Talk (as an example), I automatically have an email address for that person.

Voila. Simplest. Spam. Filter. Ever.

As if there weren’t enough reasons not to use Internet Explorer for Windows, this week alone two new threats were discovered. The first is a Trojan horse that exploits a (still unpatched) bug found in Internet Explorer first discovered in May.

Microsoft has yet to provide a fix for the vulnerability, but is working on a patch, according to the security advisory. Security-monitoring company Secunia deems the problem “extremely critical,” its rarely given highest rating.

The vulnerability puts computers running Windows 98, Windows Millennium Edition, Windows 2000 and Windows XP at risk. An attacker could gain complete control of vulnerable systems by hosting malicious code on a Web site. Once an IE user visits the site, the malicious program would run without any user interaction.

[via ZDNet]

The second is a design flaw in the way Internet Explorer handles CSS import commands and allows an attacker to retrieve private user data or execute operations on the users behalf on remote domains, Matan Gillon, who discovered the vulnerability, wrote in his article. The reason this is so troubling is because, by exploiting this vulnerablity, attackers can actually bypass extremely strict security limitations and create JavaScripts that have inter-domain communications ability (XSS attacks). If that sounds scary it’s because it should.

[Unlike] classic XSS holes […] in this case the target site doesn’t have to be vulnerable to script injection. All an attacker has to do is lure a user to a malicious web page. Thousands of web sites can be exploited and there isn’t a simple solution against this attack at least until IE is fixed. That means millions of IE users are affected by this design flaw.

This vulnerability has been tested to work on a fully patched Microsoft Internet Explorer 6 browser and earlier versions are possibly vulnerable as well. Mozilla Firefox seems to adequately keep domain restrictions in CSS imports and doesn’t seem to be vulnerable to this type of attack. Opera isn’t vulnerable because it doesn’t support the styleSheets collection. Possible solutions for users to mitigate this attack would be to disable Javascript in IE or use a different browser.

If you haven’t yet, now it’s really time to switch.