Page 1 of 2
There’s a newly discovered bug in Internet Explorer that allows any currently visited website to learn the contents of the address bar when the user hits enter. This feels important; the site I am at now has no business knowing where I go next.
Good information on how Internet Explorer, Chrome, and Firefox store user passwords.
Who are these certificate authorities? At the beginning of Web history, there were only a handful of companies, like Verisign, Equifax, and Thawte, that made near-monopoly profits from being the only providers trusted by Internet Explorer or Netscape Navigator. But over time, browsers have trusted more and more organizations to verify Web sites. Safari and Firefox now trust more than 60 separate certificate authorities by default. Microsoft’s software trusts more than 100 private and government institutions.
Disturbingly, some of these trusted certificate authorities have decided to delegate their powers to yet more organizations, which aren’t tracked or audited by browser companies. By scouring the Net for certificates, security researchers have uncovered more than 600 groups who, through such delegation, are now also automatically trusted by most browsers, including the Department of Homeland Security, Google, and Ford Motorsand a UAE mobile phone company called Etisalat.
In 2005, a company called CyberTrust—which has since been purchased by Verizon—gave Etisalat, the government-connected mobile company in the UAE, the right to verify that a site is valid. Here’s why this is trouble: Since browsers now automatically trust Etisalat to confirm a site’s identity, the company has the potential ability to fake a secure connection to any site Etisalat subscribers might visit using a man-in-the-middle scheme.
EDITED TO ADD (9/14): EFF has gotten involved.
I should probably first speak about how adware works. Most adware targets Internet Explorer (IE) users because obviously they’re the biggest share of the market. In addition, they tend to be the less-savvy chunk of the market. If you’re using IE, then either you don’t care or you don’t know about all the vulnerabilities that IE has.
IE has a mechanism called a Browser Helper Object (BHO) which is basically a gob of executable code that gets informed of web requests as they’re going. It runs in the actual browser process, which means it can do anything the browser can do—which means basically anything. We would have a Browser Helper Object that actually served the ads, and then we made it so that you had to kill all the instances of the browser to be able to delete the thing. That’s a little bit of persistence right there.
If you also have an installer, a little executable, you can make a Registry entry and every time this thing reboots, the installer will check to make sure the BHO is there. If it is, great. If it isn’t, then it will install it. That’s fine until somebody goes and deletes the executable.
The next thing that Direct Revenue did—actually I should say what I did, because I was pretty heavily involved in this—was make a poller which continuously polls about every 10 seconds or so to see if the BHO was there and alive. If it was, great. If it wasn’t, [ the poller would ] install it. To make sure the poller was less likely to be detected, we developed this algorithm (a really trivial one) for making a random-looking filename that was consistent per machine but was not easy to guess. I think it was the first 6 or 8 characters of the DES-encoded MAC address. You take the MAC address, encode it with DES, take the first six characters and that was it. That was pretty good, except the file itself would be the same binary. If you md5-summed the file it would always be the same everywhere, and it was always in the same location.
Next we made a function shuffler, which would go into an executable, take the functions and randomly shuffle them. Once you do that, then of course the signature’s all messed up. [ We also shuffled ] a lot of the pointers within each actual function. It completely changed the shape of the executable.
We then made a bootstrapper, which was a tiny tiny piece of code written in Assembler which would decrypt the executable in memory, and then just run it. At the same time, we also made a virtual process executable. I’ve never heard of anybody else doing this before. Windows has this thing called Create Remote Thread. Basically, the semantics of Create Remote Thread are: You’re a process, I’m a different process. I call you and say “Hey! I have this bit of code. I’d really like it if you’d run this.” You’d say, “Sure,” because you’re a Windows process—you’re all hippie-like and free love. Windows processes, by the way, are insanely promiscuous. So! We would call a bunch of processes, hand them all a gob of code, and they would all run it. Each process would all know about two of the other ones. This allowed them to set up a ring…mutual support, right?
So we’ve progressed now from having just a Registry key entry, to having an executable, to having a randomly-named executable, to having an executable which is shuffled around a little bit on each machine, to one that’s encrypted—really more just obfuscated—to an executable that doesn’t even run as an executable. It runs merely as a series of threads. Now, those threads can communicate with one another, they would check to make sure that the BHO was there and up, and that the whatever other software we had was also up.
There was one further step that we were going to take but didn’t end up doing, and that is we were going to get rid of threads entirely, and just use interrupt handlers. It turns out that in Windows, you can get access to the interrupt handler pretty easily. In fact, you can register with the OS a chunk of code to handle a given interrupt. Then all you have to do is arrange for an interrupt to happen, and every time that interrupt happens, you wake up, do your stuff and go away. We never got to actually do that, but it was something we were thinking we’d do.
EDITED TO ADD (1/30): Good commentary on the interview, showing how it whitewashes history.
EDITED TO ADD (2/13): Some more commentary.
Details from TheRegister.
The title of the article says it all: “Internet Explorer Unsafe for 284 Days in 2006.” Here’s a chart.
Microsoft has a new anti-phishing service in Internet Explorer 7 that will turn the address bar green and display the website owner’s identity when surfers visit on-line merchants previously approved as legitimate. So far, so good. But the service is only available to corporations: not to sole proprietorships, partnerships, or individuals.
Of course, if a merchant’s bar doesn’t turn green it doesn’t mean that they’re bad. It’ll be white, which indicates “no information.” There are also yellow and red indications, corresponding to “suspicious” and “known fraudulent site.” But small businesses are worried that customers will be afraid to buy from non-green sites.
That’s possible, but it’s more likely that users will learn that the marker isn’t reliable and start to ignore it.
Any white-list system like this has two sources of error. False positives, where phishers get the marker. And false negatives, where legitimate honest merchants don’t. Any system like this has to effectively deal with both.
EDITED TO ADD (12/21): Research paper: “Phinding Phish: An Evaulation of Anti-Phishing Toolbars,” by L. Cranor, S. Egleman, J. Hong, and Y. Zhang.
To kick off his new Browser Fun blog, H.D. Moore began with “A Month of Browser Bugs”:
This blog will serve as a dumping ground for browser-based security research and vulnerability disclosure. To kick off this blog, we are announcing the Month of Browser Bugs (MoBB), where we will publish a new browser hack, every day, for the entire month of July. The hacks we publish are carefully chosen to demonstrate a concept without disclosing a direct path to remote code execution. Enjoy!
Thirty-one days, and thirty-one hacks later, the blog lists exploits against all the major browsers:
My guess is that he could have gone on for another month without any problem, and possibly could produce a new browser bug a day indefinitely.
The moral here isn’t that IE is less secure than the other browsers, although I certainly believe that. The moral is that coding standards are so bad that security flaws are this common.
Eric Rescorla argues that it’s a waste of time to find and fix new security holes, because so many of them still remain and the software’s security isn’t improved. I think he has a point. (Note: this is not to say that it’s a waste of time to fix the security holes found and publicly exploited by the bad guys. The question Eric tries to answer is whether or not it is worth it for the security community to find new security holes.)
Another commentary is here.
John Dvorak makes an interesting argument that Internet Explorer was Microsoft’s greatest mistake ever. Certainly its decision to tightly integrate IE with the operating system—done as an anti-competitive maneuver against Netscape during the Browser Wars—has resulted in some enormous security problems that Microsoft has still not recovered from. Not even with the introduction of IE7.
I’m just starting to read about the new security features in Internet Explorer 7. So far, I like what I am reading.
IE 7 requires that all browser windows display an address bar. This helps foil attackers that operate by popping up new windows masquerading as pages on a legitimate site, when in fact the site is fraudulent. By requiring an address bar, users will immediately see the true URL of the displayed page, making these types of attacks more obvious. If you think you’re looking at www.microsoft.com, but the browser address bar says www.illhackyou.net, you ought to be suspicious.
I use Opera, and have long used the address bar to “check” on URLs. This is an excellent idea. So is this:
In early November, a bunch of Web browser developers got together and started fleshing out standards for address bar coloring, which can cue users to secured connections. Under the proposal laid out by IE 7 team member Rob Franco, even sites that use a standard SSL certificate will display a standard white address bar. Sites that use a stronger, as yet undetermined level of protection will use a green bar.
I like easy visual indications about what’s going on. And I really like that SSL is generic white, because it really doesn’t prove that you’re communicating with the site you think you’re communicating with. This feature helps with that, though:
Franco also said that when navigating to an SSL-protected site, the IE 7 address bar will display the business name and certification authority’s name in the address bar.
Some of the security measures in IE7 weaken the integration between the browser and the operating system:
People using Windows Vista beta 2 will find a new feature called Protected Mode, which renders IE 7 unable to modify system files and settings. This essentially breaks down part of the integration between IE and Windows itself.
Think of it is as a wall between IE and the rest of the operating system. No, the code won’t be perfect, and yes, there’ll be ways found to circumvent this security, but this is an important and long-overdue feature.
The majority of IE’s notorious security flaws stem from its pervasive integration with Windows. That is a feature no other Web browser offers—and an ability that Vista’s Protected Mode intends to mitigate. IE 7 obviously won’t remove all of that tight integration. Lacking deep architectural changes, the effort has focused instead on hardening or eliminating potential vulnerabilities. Unfortunately, this approach requires Microsoft to anticipate everything that could go wrong and block it in advance—hardly a surefire way to secure a browser.
That last sentence is about the general Internet attitude to allow everything that is not explicitly denied, rather than deny everything that is not explicitly allowed.
Also, you’ll have to wait until Vista to use it:
…this capability will not be available in Windows XP because it’s woven directly into Windows Vista itself.
There are also some good changes under the hood:
IE 7 does eliminate a great deal of legacy code that dates back to the IE 4 days, which is a welcome development.
And:
Microsoft has rewritten a good bit of IE 7’s core code to help combat attacks that rely on malformed URLs (that typically cause a buffer overflow). It now funnels all URL processing through a single function (thus reducing the amount of code that “looks” at URLs).
All good stuff, but I agree with this conclusion:
IE 7 offers several new security features, but it’s hardly a given that the situation will improve. There has already been a set of security updates for IE 7 beta 1 released for both Windows Vista and Windows XP computers. Security vulnerabilities in a beta product shouldn’t be alarming (IE 7 is hardly what you’d consider “finished” at this point), but it may be a sign that the product’s architecture and design still have fundamental security issues.
I’m not switching from Opera yet, and my second choice is still Firefox. But the masses still use IE, and our security depends in part on those masses keeping their computers worm-free and bot-free.
NOTE: Here’s some info on how to get your own copy of Internet Explorer 7 beta 2.
Sidebar photo of Bruce Schneier by Joe MacInnis.