Microsoft Archives - Page 14 of 17 - Schneier on Security

Entries Tagged "Microsoft"

Page 14 of 17

Microsoft's BitLocker

BitLocker Drive Encryption is a new security feature in Windows Vista, designed to work with the Trusted Platform Module (TPM). Basically, it encrypts the C drive with a computer-generated key. In its basic mode, an attacker can still access the data on the drive by guessing the user’s password, but would not be able to get at the drive by booting the disk up using another operating system, or removing the drive and attaching it to another computer.

There are several modes for BitLocker. In the simplest mode, the TPM stores the key and the whole thing happens completely invisibly. The user does nothing differently, and notices nothing different.

The BitLocker key can also be stored on a USB drive. Here, the user has to insert the USB drive into the computer during boot. Then there’s a mode that uses a key stored in the TPM and a key stored on a USB drive. And finally, there’s a mode that uses a key stored in the TPM and a four-digit PIN that the user types into the computer. This happens early in the boot process, when there’s still ASCII text on the screen.

Note that if you configure BitLocker with a USB key or a PIN, password guessing doesn’t work. BitLocker doesn’t even let you get to a password screen to try.

For most people, basic mode is the best. People will keep their USB key in their computer bag with their laptop, so it won’t add much security. But if you can force users to attach it to their keychains—remember that you only need the key to boot the computer, not to operate the computer—and convince them to go through the trouble of sticking it in their computer every time they boot, then you’ll get a higher level of security.

There is a recovery key: optional but strongly encouraged. It is automatically generated by BitLocker, and it can be sent to some administrator or printed out and stored in some secure location. There are ways for an administrator to set group policy settings mandating this key.

There aren’t any back doors for the police, though.

You can get BitLocker to work in systems without a TPM, but it’s kludgy. You can only configure it for a USB key. And it only will work on some hardware: because BItLocker starts running before any device drivers are loaded, the BIOS must recognize USB drives in order for BitLocker to work.

Encryption particulars: The default data encryption algorithm is AES-128-CBC with an additional diffuser. The diffuser is designed to protect against ciphertext-manipulation attacks, and is independently keyed from AES-CBC so that it cannot damage the security you get from AES-CBC. Administrators can select the disk encryption algorithm through group policy. Choices are 128-bit AES-CBC plus the diffuser, 256-bit AES-CBC plus the diffuser, 128-bit AES-CBC, and 256-bit AES-CBC. (My advice: stick with the default.) The key management system uses 256-bit keys wherever possible. The only place where a 128-bit key limit is hard-coded is the recovery key, which is 48 digits (including checksums). It’s shorter because it has to be typed in manually; typing in 96 digits will piss off a lot of people—even if it is only for data recovery.

So, does this destroy dual-boot systems? Not really. If you have Vista running, then set up a dual boot system, Bitlocker will consider this sort of change to be an attack and refuse to run. But then you can use the recovery key to boot into Windows, then tell BitLocker to take the current configuration—with the dual boot code—as correct. After that, your dual boot system will work just fine, or so I’ve been told. You still won’t be able to share any files on your C drive between operating systems, but you will be able to share files on any other drive.

The problem is that it’s impossible to distinguish between a legitimate dual boot system and an attacker trying to use another OS—whether Linux or another instance of Vista—to get at the volume.

BitLocker is not a panacea. But it does mitigate a specific but significant risk: the risk of attackers getting at data on drives directly. It allows people to throw away or sell old drives without worry. It allows people to stop worrying about their drives getting lost or stolen. It stops a particular attack against data.

Right now BitLocker is only in the Ultimate and Enterprise editions of Vista. It’s a feature that is turned off by default. It is also Microsoft’s first TPM application. Presumably it will be enhanced in the future: allowing the encryption of other drives would be a good next step, for example.

EDITED TO ADD (5/3): BitLocker is not a DRM system. However, it is straightforward to turn it into a DRM system. Simply give programs the ability to require that files be stored only on BitLocker-enabled drives, and then only be transferrable to other BitLocker-enabled drives. How easy this would be to implement, and how hard it would be to subvert, depends on the details of the system.

Posted on May 2, 2006 at 6:54 AM • View Comments

Microsoft and Internet Explorer

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.

Posted on April 28, 2006 at 12:29 PM • View Comments

Microsoft Vista's Endless Security Warnings

Paul Thurrott has posted an excellent essay on the problems with Windows Vista. Most interesting to me is how they implement UAP (User Account Protection):

Modern operating systems like Linux and Mac OS X operate under a security model where even administrative users don’t get full access to certain features unless they provide an in-place logon before performing any task that might harm the system. This type of security model protects users from themselves, and it is something that Microsoft should have added to Windows years and years ago.

Here’s the good news. In Windows Vista, Microsoft is indeed moving to this kind of security model. The feature is called User Account Protection (UAP) and, as you might expect, it prevents even administrative users from performing potentially dangerous tasks without first providing security credentials, thus ensuring that the user understands what they’re doing before making a critical mistake. It sounds like a good system. But this is Microsoft, we’re talking about here. They completely botched UAP.

The bad news, then, is that UAP is a sad, sad joke. It’s the most annoying feature that Microsoft has ever added to any software product, and yes, that includes that ridiculous Clippy character from older Office versions. The problem with UAP is that it throws up an unbelievable number of warning dialogs for even the simplest of tasks. That these dialogs pop up repeatedly for the same action would be comical if it weren’t so amazingly frustrating. It would be hilarious if it weren’t going to affect hundreds of millions of people in a few short months. It is, in fact, almost criminal in its insidiousness.

Let’s look a typical example. One of the first things I do whenever I install a new Windows version is download and install Mozilla Firefox. If we forget, for a moment, the number of warning dialogs we get during the download and install process (including a brazen security warning from Windows Firewall for which Microsoft should be chastised), let’s just examine one crucial, often overlooked issue. Once Firefox is installed, there are two icons on my Desktop I’d like to remove: The Setup application itself and a shortcut to Firefox. So I select both icons and drag them to the Recycle Bin. Simple, right?

Wrong. Here’s what you have to go through to actually delete those files in Windows Vista. First, you get a File Access Denied dialog (Figure) explaining that you don’t, in fact, have permission to delete a … shortcut?? To an application you just installed??? Seriously?

OK, fine. You can click a Continue button to “complete this operation.” But that doesn’t complete anything. It just clears the desktop for the next dialog, which is a Windows Security window (Figure). Here, you need to give your permission to continue something opaquely called a “File Operation.” Click Allow, and you’re done. Hey, that’s not too bad, right? Just two dialogs to read, understand, and then respond correctly to. What’s the big deal?

What if you’re doing something a bit more complicated? Well, lucky you, the dialogs stack right up, one after the other, in a seemingly never-ending display of stupidity. Indeed, sometimes you’ll find yourself unable to do certain things for no good reason, and you click Allow buttons until you’re blue in the face. It will never stop bothering you, unless you agree to stop your silliness and leave that file on the desktop where it belongs. Mark my words, this will happen to you. And you will hate it.

The problem with lots of warning dialog boxes is that they don’t provide security. Users stop reading them. They think of them as annoyances, as an extra click required to get a feature to work. Clicking through gets embedded into muscle memory, and when it actually matters the user won’t even realize it.

Jeff Atwood says the same thing:

The problem with the Security Through Endless Warning Dialogs school of thought is that it doesn’t work. All those earnest warning dialogs eventually blend together into a giant “click here to get work done” button that nobody bothers to read any more. The operating system cries wolf so much that when a real wolf—in the form of a virus or malware—rolls around, you’ll mindlessly allow it access to whatever it wants, just out of habit.

So does Rick Strahl:

Then there are the security dialogs. Ah yes, now we’re making progress: Ask users on EVERY program you launch that isn’t signed whether they want to elevate permissions. Uh huh, this is going to work REAL WELL. We know how well that worked with unsigned ActiveX controls in Internet Explorer so well that even Microsoft isn’t signing most of its own ActiveX controls. Give too many warnings that are not quite reasonable and people will never read the dialogs and just click them anyway… I know I started doing that in the short use I’ve had on Vista.

These dialog boxes are not security for the user, they’re CYA security from the user. When some piece of malware trashes your system, Microsoft can say: “You gave the program permission to do that; it’s not our fault.”

Warning dialog boxes are only effective if the user has the ability to make intelligent decisions about the warnings. If the user cannot do that, they’re just annoyances. And they’re annoyances that don’t improve security.

EDITED TO ADD (5/8): Commentary.

Posted on April 24, 2006 at 1:43 PM • View Comments

Windows Access Control

I just found an interesting paper: “Windows Access Control Demystified,” by Sudhakar Govindavajhala and Andrew W. Appel. Basically, they show that companies like Adobe, Macromedia, etc., have mistakes in their Access Control Programming that open security holes in Windows XP.

Abstract

In the Secure Internet Programming laboratory at Princeton University, we have been investigating network security management by using logic programming. We developed a rule based framework—Multihost, Multistage, Vulnerability Analysis(MulVAL)—to perform end-to-end, automatic analysis of multi-host, multi-stage attacks on a large network where hosts run different operating systems. The tool finds attack paths where the adversary will have to use one or more than one weaknesses (buffer overflows) in multiple software to attack the network. The MulVAL framework has been demonstrated to be modular, flexible, scalable and efficient [20]. We applied these techniques to perform security analysis of a single host with commonly used software.

We have constructed a logical model of Windows XP access control, in a declarative but executable (Datalog) format. We have built a scanner that reads access-control conguration information from the Windows registry, file system, and service control manager database, and feeds raw conguration data to the model. Therefore we can reason about such things as the existence of privilege-escalation attacks, and indeed we have found several user-to-administrator vulnerabilities caused by misconfigurations of the access-control lists of commercial software from several major vendors. We propose tools such as ours as a vehicle for software developers and system administrators to model and debug the complex interactions of access control on installations under Windows.

EDITED TO ADD (2/13): Ed Felten has some good commentary about the paper on his blog.

Posted on February 13, 2006 at 12:11 PM • View Comments

The New Internet Explorer

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.

Posted on February 9, 2006 at 3:37 PM • View Comments

The NSA on How to Redact

Interesting paper.

Both the Microsoft Word document format (MS Word) and Adobe Portable Document (PDF) are complex, sophisticated computer data formats. They can contain many kinds of information such as text, graphics, tables, images, meta-data, and more all mixed together. The complexity makes them potential vehicles for exposing information unintentionally, especially when downgrading or sanitizing classified materials. Although the focus is on MS Word, the general guidance applies to other word processors and office tools, such as WordPerfect, PowerPoint, Excel, Star Office, etc.

This document does not address all the issues that can arise when distributing or downgrading original document formats such as MS Word or MS PowerPoint. Using original source formats, such as MS Word, for downgrading can entail exceptional risks; the lengthy and complicated procedures for mitigating such risks are outside the scope of this note.

EDITED TO ADD (2/1): The NSA page for the redaction document, and other “Security Configuration Guides,” is here.

Posted on February 1, 2006 at 1:09 PM • View Comments

DHS Funding Open Source Security

From eWeek:

The U.S. government’s Department of Homeland Security plans to spend $1.24 million over three years to fund an ambitious software auditing project aimed at beefing up the security and reliability of several widely deployed open-source products.

The grant, called the “Vulnerability Discovery and Remediation Open Source Hardening Project,” is part of a broad federal initiative to perform daily security audits of approximately 40 open-source software packages, including Linux, Apache, MySQL and Sendmail.

The plan is to use source code analysis technology from San Francisco-based Coverity Inc. to pinpoint and correct security vulnerabilities and other potentially dangerous defects in key open-source packages.

Software engineers at Stanford University will manage the project and maintain a publicly available database of bugs and defects.

Anti-virus vendor Symantec Corp. is providing guidance as to where security gaps might be in certain open-source projects.

I think this is a great use of public funds. One of the limitations of open-source development is that it’s hard to fund tools like Coverity. And this kind of thing improves security for a lot of different organizations against a wide variety of threats. And it increases competition with Microsoft, which will force them to improve their OS as well. Everybody wins.

What’s affected?

In addition to Linux, Apache, MySQL and Sendmail, the project will also pore over the code bases for FreeBSD, Mozilla, PostgreSQL and the GTK (GIMP Tool Kit) library.

And from ZDNet:

The list of open-source projects that Stanford and Coverity plan to check for security bugs includes Apache, BIND, Ethereal, KDE, Linux, Firefox, FreeBSD, OpenBSD, OpenSSL and MySQL, Coverity said.

Posted on January 17, 2006 at 1:04 PM • View Comments

Microsoft Windows Receives EAL 4+ Certification

Windows has a Common Criteria (CC) certification:

Microsoft announced that all the products earned the EAL 4 + (Evaluation Assurance Level), which is the highest level granted to a commercial product.

The products receiving CC certification include Windows XP Professional with Service Pack 2 and Windows XP Embedded with Service Pack 2. Four different versions of Windows Server 2003 also received certification.

Is this true?

…director of security engineering strategy at Microsoft Steve Lipner said the certifications are a significant proof point of Redmond’s commitment to creating secure software.

Or are the certifications proof that EAL 4+ isn’t worth much?

Posted on December 20, 2005 at 7:21 AM • View Comments

OpenDocument Format and the State of Massachusetts

OpenDocument format (ODF) is an alternative to the Microsoft document, spreadsheet, and etc. file formats. (Here’s the homepage for the ODF standard; it’ll put you to sleep, I promise you.)

So far, nothing here is relevant to this blog. Except that Microsoft, with its proprietary Office document format, is spreading rumors that ODF is somehow less secure.

This, from the company that allows Office documents to embed arbitrary Visual Basic programs?

Yes, there is a way to embed scripts in ODF; this seems to be what Microsoft is pointing to. But at least ODF has a clean and open XML format, which allows layered security and the ability to remove scripts as needed. This is much more difficult in the binary Microsoft formats that effectively hide embedded programs.

Microsoft’s claim that the the open ODF is inherently less secure than the proprietary Office format is essentially an argument for security through obscurity. ODF is no less secure than current .doc and other proprietary formats, and may be—marginally, at least—more secure.

This document document from the ODF people says it nicely:

There is no greater security risk, no greater ability to “manipulate code” or gain access to content using ODF than alternative document formats. Security should be addressed through policy decisions on information sharing, regardless of document format. Security exposures caused by programmatic extensions such as the visual basic macros that can be imbedded in Microsoft Office documents are well known and notorious, but there is nothing distinct about ODF that makes it any more or less vulnerable to security risks than any other format specification. The many engineers working to enhance the ODF specification are working to develop techniques to mitigate any exposure that may exist through these extensions.

This whole thing has heated up because Massachusetts recently required public records be held in OpenDocument format, which has put Microsoft into a bit of a tizzy. (Here are two commentaries on the security of that move.) I don’t know if it’s why Microsoft is submitting its Office Document Formats to ECMA for “open standardization,” but I’m sure it’s part of the reason.

Posted on December 7, 2005 at 2:21 PM • View Comments

Sony's DRM Rootkit: The Real Story

This is my sixth column for Wired.com:

It’s a David and Goliath story of the tech blogs defeating a mega-corporation.

On Oct. 31, Mark Russinovich broke the story in his blog: Sony BMG Music Entertainment distributed a copy-protection scheme with music CDs that secretly installed a rootkit on computers. This software tool is run without your knowledge or consent—if it’s loaded on your computer with a CD, a hacker can gain and maintain access to your system and you wouldn’t know it.

The Sony code modifies Windows so you can’t tell it’s there, a process called “cloaking” in the hacker world. It acts as spyware, surreptitiously sending information about you to Sony. And it can’t be removed; trying to get rid of it damages Windows.

This story was picked up by other blogs (including mine), followed by the computer press. Finally, the mainstream media took it up.

The outcry was so great that on Nov. 11, Sony announced it was temporarily halting production of that copy-protection scheme. That still wasn’t enough—on Nov. 14 the company announced it was pulling copy-protected CDs from store shelves and offered to replace customers’ infected CDs for free.

But that’s not the real story here.

It’s a tale of extreme hubris. Sony rolled out this incredibly invasive copy-protection scheme without ever publicly discussing its details, confident that its profits were worth modifying its customers’ computers. When its actions were first discovered, Sony offered a “fix” that didn’t remove the rootkit, just the cloaking.

Sony claimed the rootkit didn’t phone home when it did. On Nov. 4, Thomas Hesse, Sony BMG’s president of global digital business, demonstrated the company’s disdain for its customers when he said, “Most people don’t even know what a rootkit is, so why should they care about it?” in an NPR interview. Even Sony’s apology only admits that its rootkit “includes a feature that may make a user’s computer susceptible to a virus written specifically to target the software.”

However, imperious corporate behavior is not the real story either.

This drama is also about incompetence. Sony’s latest rootkit-removal tool actually leaves a gaping vulnerability. And Sony’s rootkit—designed to stop copyright infringement—itself may have infringed on copyright. As amazing as it might seem, the code seems to include an open-source MP3 encoder in violation of that library’s license agreement. But even that is not the real story.

It’s an epic of class-action lawsuits in California and elsewhere, and the focus of criminal investigations. The rootkit has even been found on computers run by the Department of Defense, to the Department of Homeland Security’s displeasure. While Sony could be prosecuted under U.S. cybercrime law, no one thinks it will be. And lawsuits are never the whole story.

This saga is full of weird twists. Some pointed out how this sort of software would degrade the reliability of Windows. Someone created malicious code that used the rootkit to hide itself. A hacker used the rootkit to avoid the spyware of a popular game. And there were even calls for a worldwide Sony boycott. After all, if you can’t trust Sony not to infect your computer when you buy its music CDs, can you trust it to sell you an uninfected computer in the first place? That’s a good question, but—again—not the real story.

It’s yet another situation where Macintosh users can watch, amused (well, mostly) from the sidelines, wondering why anyone still uses Microsoft Windows. But certainly, even that is not the real story.

The story to pay attention to here is the collusion between big media companies who try to control what we do on our computers and computer-security companies who are supposed to be protecting us.

Initial estimates are that more than half a million computers worldwide are infected with this Sony rootkit. Those are amazing infection numbers, making this one of the most serious internet epidemics of all time—on a par with worms like Blaster, Slammer, Code Red and Nimda.

What do you think of your antivirus company, the one that didn’t notice Sony’s rootkit as it infected half a million computers? And this isn’t one of those lightning-fast internet worms; this one has been spreading since mid-2004. Because it spread through infected CDs, not through internet connections, they didn’t notice? This is exactly the kind of thing we’re paying those companies to detect—especially because the rootkit was phoning home.

But much worse than not detecting it before Russinovich’s discovery was the deafening silence that followed. When a new piece of malware is found, security companies fall over themselves to clean our computers and inoculate our networks. Not in this case.

McAfee didn’t add detection code until Nov. 9, and as of Nov. 15 it doesn’t remove the rootkit, only the cloaking device. The company admits on its web page that this is a lousy compromise. “McAfee detects, removes and prevents reinstallation of XCP.” That’s the cloaking code. “Please note that removal will not impair the copyright-protection mechanisms installed from the CD. There have been reports of system crashes possibly resulting from uninstalling XCP.” Thanks for the warning.

Symantec’s response to the rootkit has, to put it kindly, evolved. At first the company didn’t consider XCP malware at all. It wasn’t until Nov. 11 that Symantec posted a tool to remove the cloaking. As of Nov. 15, it is still wishy-washy about it, explaining that “this rootkit was designed to hide a legitimate application, but it can be used to hide other objects, including malicious software.”

The only thing that makes this rootkit legitimate is that a multinational corporation put it on your computer, not a criminal organization.

You might expect Microsoft to be the first company to condemn this rootkit. After all, XCP corrupts Windows’ internals in a pretty nasty way. It’s the sort of behavior that could easily lead to system crashes—crashes that customers would blame on Microsoft. But it wasn’t until Nov. 13, when public pressure was just too great to ignore, that Microsoft announced it would update its security tools to detect and remove the cloaking portion of the rootkit.

Perhaps the only security company that deserves praise is F-Secure, the first and the loudest critic of Sony’s actions. And Sysinternals, of course, which hosts Russinovich’s blog and brought this to light.

Bad security happens. It always has and it always will. And companies do stupid things; always have and always will. But the reason we buy security products from Symantec, McAfee and others is to protect us from bad security.

I truly believed that even in the biggest and most-corporate security company there are people with hackerish instincts, people who will do the right thing and blow the whistle. That all the big security companies, with over a year’s lead time, would fail to notice or do anything about this Sony rootkit demonstrates incompetence at best, and lousy ethics at worst.

Microsoft I can understand. The company is a fan of invasive copy protection—it’s being built into the next version of Windows. Microsoft is trying to work with media companies like Sony, hoping Windows becomes the media-distribution channel of choice. And Microsoft is known for watching out for its business interests at the expense of those of its customers.

What happens when the creators of malware collude with the very companies we hire to protect us from that malware?

We users lose, that’s what happens. A dangerous and damaging rootkit gets introduced into the wild, and half a million computers get infected before anyone does anything.

Who are the security companies really working for? It’s unlikely that this Sony rootkit is the only example of a media company using this technology. Which security company has engineers looking for the others who might be doing it? And what will they do if they find one? What will they do the next time some multinational company decides that owning your computers is a good idea?

These questions are the real story, and we all deserve answers.