Security Bytes

December 30, 2008  1:05 PM

Behind the MD5 attack

David Schneier David Schneier Profile: David Schneier

When the researchers who produced the elegant MD5 attack I wrote about this morning realized the severity of what they had found, they took two highly unusual steps. First, they consulted with lawyers from the Electronic Frontier Foundation, describing their findings and voicing their concerns about the potential legal ramifications. The researchers were afraid that if the certificate authorities found out about their work and its implications for the security of their digital certificates, the CAs would move to stop the their talk at the 25C3 conference today in Berlin, at the very least, and perhaps sue them for good measure.

Second, the group approached Microsoft and Mozilla, the two dominant browser vendors, and  explained that they had a serious browser security issue they’d like to share. But first, they needed some assurances from the two vendors that they wouldn’t share what they heard with the CAs before the researchers were ready to announce their findings. So they asked Microsoft and Mozilla officials to sign non-disclosure agreements. It was a 180-degree reversal from the way that these things normally work.

In most cases, researchers who approach a vendor with a security problem are asked by the vendor to keep quiet about the vulnerability until a patch is ready. But in this instance, the researchers held the upper hand and chose not to even tell the vendors what the issue was until they had the signed NDAs in hand. Alex Sotirov, one of the researchers involved in the project, said that it took some negotiations to get Microsoft officials to agree to the NDA, but they eventually signed on. As did Mozilla.

During their presentation on Tuesday, the researchers said they were hopeful that other researchers would follow their lead. And Dino Dai Zovi, a researcher who was not part of the project but who was briefed on the team’s work, agreed. “A letter from a lawyer is usually enough to stop any researcher,” he said. “But showing up with your own lawyer changes the balance of power.”

December 22, 2008  2:28 PM

Nokia to sell security business to Check Point

David Schneier David Schneier Profile: David Schneier

In a move that has been anticipated for some time, Nokia on Monday said it has an agreement in place to sell its security business. What did come as a surprise was the identity of the buyer: Check Point. The two companies have been working together for years, with Nokia deploying Check Point’s software on its own security appliances. The terms of the agreement were not disclosed, though Nokia said it expects the deal to be finalized by the end of March.

“As a pioneer in security appliances, the Nokia security appliance business has been an important strategic partner for Check Point and has helped us achieve early leadership in the security appliance market,” said Gil Shwed, Chairman and CEO at Check Point. “Adding Nokia’s security appliance portfolio into Check Point’s broad range of security solutions is the natural conclusion of our long collaboration, and will assure a smooth path forward for our mutual customers.”

Check Point and Nokia have long provided customers with a range of best-of-breed security solutions, proven in high-performance, mission critical environments.  Nokia’s security appliance business provides purpose-built security platforms optimized for Check Point Firewall, virtual private network (VPN) and unified threat management (UTM) software.

Nokia’s main focus for years has been its mobile handset business, and its security unit has always been something of an odd fit. It’s an enterprise business in the midst of a company that does most of its work selling consumer handsets. Now, with Check Point taking the reins, Nokia will be free to focus on that business, while Check Point can bring the appliances in-house and have an extra revenue stream.

December 19, 2008  3:59 PM

Cable cuts in Mediterranean kill Internet service in Egypt, other countries

David Schneier David Schneier Profile: David Schneier

Several undersea cables in the Mediterranean Sea that carry the bulk of Internet traffic between Asia and Europe have been cut, resulting in a massive Internet outage in Egypt and problems in other countries. Early reports are speculating that the cut, which happened Friday morning, may have been the result of an anchor drop. A report on said the three cable cuts happened separately, but within a few minutes of one another. The cuts seem to be in the link between Sicily and Tunisia in the Mediterranean.

France Telecom observed today that 3 major underwater cables were cut: “Sea Me We 4” at 7:28am, “Sea Me We3” at 7:33am and FLAG at 8:06am. The causes of the cut, which is located in the Mediterranean between Sicily and Tunisia, on sections linking Sicily to Egypt, remain unclear.

Most of the B to B traffic between Europe and Asia is rerouted through the USA. Traffic from Europe to Algeria and Tunisia is not affected, but traffic from Europe to the Near East and Asia is interrupted to a greater or lesser extent.

There is apparently a work crew on the way to fix the cuts, but it likely will be several days before the repairs are complete.

December 17, 2008  2:03 PM

Word documents being used in new attacks on IE XML flaw

David Schneier David Schneier Profile: David Schneier

The list of things to worry about with the soon-to-be-patched MS08-078 XML data binding vulnerability is getting longer by the minute.  The researchers at McAfee’s AVERT Labs report that they have been seeing exploits using Word documents to download and install malicious ActiveX controls on user machines.

Upon opening the word document, the embedded ActiveX control with the following classid  is instantiated and executed.

  • {AE24FDAE-03C6-11D1-8B76-0080C744F389}

This control stores configuration data for the policy setting Microsoft Scriptlet Component.


The control then makes a request to the Web page hosting the IE 7 exploit. The charm with this approach is that the exploit is downloaded and run without the knowledge or permission of the user. To the unsuspecting user, it will just appear as yet another normal .doc file.

Not good news. Most of the other attacks that have been seen against the vulnerability have been of the drive-by download variety. But this puts things in a different light. The emergency patch for the MS08-078 vulnerability is due later today, and this new attack vector makes applying the fix an even higher priority.

December 16, 2008  4:00 PM

Microsoft to release emergency patch for IE XML flaw

David Schneier David Schneier Profile: David Schneier

Microsoft on Wednesday will release an emergency out-of-band patch for the XML handling flaw in Internet Explorer that has been the target of malware attacks for the last week or more. This is the second time in the last few months that the company has released a patch outside of its monthly scheduled update cycle. Microsoft issued a security bulletin about the vulnerability last week and later updated it to inform customers that all supported versions of IE are vulnerable to the attack, not just IE 7.

The patch will be rated critical, as you’d expect from an emergency fix, and Microsoft is planning to hold a webcast tomorrow at 1 p.m. PST to explain the vulnerability, the attacks and the fix. Microsoft also released an emergency patch for the MS08-067 RPC vulnerability in October. In that case, just as in the case of the IE XML flaw, Microsoft and other security companies had warned that there were targeted attacks being used against the vulnerability.

December 15, 2008  12:55 PM

Steve Bellovin’s unsparing analysis of the CSIS cyber security report

David Schneier David Schneier Profile: David Schneier

The recent release of the “Securing Cyberspace for the 44th President” report spawned a flood of analysis and criticism, and much of it was positive and complimentary. I’ve written before about the idea behind this report and the fact that many, if not most, of the recommendations in it can also be found in the National Strategy to Secure Cyber Space, which was released nearly six years ago. That document has been largely ignored and we have all been paying the price in the interim. The federal government’s virtual abandonment of cybersecurity policy in the last eight years has left all of us more vulnerable, and will end up costing the government, and taxpayers, far more money in the long term.

In reading the various analyses of the report, I found that many people were commending the commission for suggestions that either have failed in the past, or have little chance of working now. I ran across Steve Bellovin’s blog post on the report and it came as no surprise that his analysis was right on the money. Bellovin’s as smart as they come, and it’s worth the time to read through his entire post on the report, but in the meanwhile, here are a few key points:

The analysis of the threat environment is, in my opinion, superb; I don’t think I’ve seen it explicated better. Briefly, the U.S. is facing threats at all levels, from individual cybercriminals to actions perpetrated by nation-states. The report pulls no punches (p. 11):

America’s failure to protect cyberspace is one of the most urgent national security problems facing the new administration that will take office in January 2009. It is, like Ultra and Engima, a battle fought mainly in the shadows. It is a battle we are losing.

That’s it exactly. In fact, it’s a battle we’re not even fighting right now.

The most important technical point in this report, in my opinion, is its realization that one cannot achieve cybersecurity solely by protecting individual components: “There is no way to determine what happens when NIAP-reviewed products are all combined into a composite IT system” (p. 58). Quite right, and too little appreciated; security is a systems property. The report also notes that “security is, in fact, part of the entire design-and-build process”.

It should be, but that hasn’t been the case in many systems for far too long. Bellovin then skewers what has been the dominant federal strategy for remedying this problem:

The discussion of using Federal market powers to “remedy the lack of demand for secure protocols” is too terse, perhaps by intent. As I read that section (p. 58), it is calling for BGP and DNS security. These are indeed important, and were called out by name in the 2002 National Strategy to Secure Cyberspace. However, I fear that simply saying that the Federal government should only buy Internet services from ISPs that support these will do too little. DNSSEC to protect .gov and .mil does not require ISP involvement; in fact, the process is already underway within the government itself. Secured BGP is another matter; that can only be done by ISPs. However, another recent Federal cybersecurity initiative — the Trusted Internet Connection program — has ironically reduced the potential for impact by limiting the government to a very small number of links to ISPs. Furthermore, given how many vital government dealings are with the consumer and private sectors, and given that secured BGP doesn’t work very well without widespread adoption, U.S. cybersecurity really needs mass adoption. This is a clear case where regulation is necessary; furthermore, it must be done in conjunction with other governments.

Bellovin also criticizes the report for calling on the Obama administration to protect online privacy without providing any guidance as to what that means or how to do it. But he leaves the best for last: the omission of any mention of software security and its cascading effect on system and network security.

The buggy software issue is also the problem with the discussion of acquisitions and regulation (p. 55). There are certainly some things that regulations can mandate, such as default secure configurations. Given how long the technical security community has called for such things, it is shameful that vendors still haven’t listened. But what else should be done to ensure that “providers of IT products and systems are accountable and … certify that they have adhered to security and configuration guidelines?” Will we end up with more meaningless checklists demanding antivirus software on machines that shouldn’t need it? Of course, I can’t propose better wording. Quite simply, we don’t know what makes a system secure unless it’s been designed for security from the start. It is quite clear to me that today’s systems are not secure and cannot be made secure.

Well said.

December 12, 2008  11:07 AM

Microsoft says all versions of Internet Explorer vulnerable to XML attack

David Schneier David Schneier Profile: David Schneier

The Internet Explorer vulnerability saga continues to unfold. Microsoft late Thursday released more information about the unpatched XML flaw in IE, and confirmed that the vulnerability in fact affects all supported versions of IE, not just IE 7 as previously thought. Microsoft Malware Protection Center officials said the company has seen exploits against the vulnerability in the wild, including attacks against both home and enterprise users.

The exploit sites we’ve seen so far drop a wide variety of malware — most commonly password stealers like new variants of game password stealers like Win32/OnLineGames and Win32/Lolyda, keyloggers like Win32/Lmir, Trojan horse applications like Win32/Helpud along with some previously unseen malware which we generically detect as Win32/SystemHijack. We fully expect the variety of malware being dropped by this exploit to broaden as the exploit code starts to circulate around the Internet underground.

This issue could impact you even if you avoid surfing questionable sites. Over the past few months, we’ve seen a surge in SQL injection attacks which enable miscreants to inject content onto trusted sites (we even blogged about the technique a few months ago). This class of attack, along with other more classical forms of website intrusion, mean that even trusted sites can end up serving malicious content causing you to get infected.

Microsoft’s Security Response Center has added more information about the attacks and workarounds to its advisory, as well.

We’ve also added additional workarounds to the advisory and updated our guidance to recommend that you evaluate implementing two of the workarounds together for the most effective protection. Specifically, we’re recommending both setting the Internet zone security setting to High and using ACLs to disable Ole32db.dll. Our research so far has shown that these two steps together provide the most effective protections for this issue.

December 11, 2008  10:51 AM

Microsoft releases advisory and workarounds for IE 7 XML flaw

David Schneier David Schneier Profile: David Schneier

Microsoft has released a security advisory with a suggested workaround for protecting vulnerable machines against attacks on the unpatched XML vulnerability in Internet Explorer 7 that came to light earlier this week. The advisory suggests that customers at risk from the attacks do several things: enable DEP, set the Internet and intranet security settings to high, and configure IE to prompt the user before running active scripting, or disable active scripting altogether in the Internet and local intranet security zones.

Microsoft said it’s seen limited attacks against the vulnerability, and there are numerous reports or working exploits being seen in use. In its advisory, Microsoft confirmed that IE 7 on Vista and Windows Server 2008 is vulnerable to this attack, as are machines running XP SP2 and SP3 and Windows Server 2003. However, the company also said that running IE in protected mode mitigates the vulnerability. Microsoft did not rule out the possibility of issuing an out-of-band patch for the flaw.

We are actively investigating the vulnerability these attacks attempt to exploit. We will continue to monitor the threat environment and update this advisory if this situation changes. On completion of this investigation, Microsoft will take the appropriate action to protect our customers, which may include providing a solution through a service pack, our monthly security update release process, or an out-of-cycle security update, depending on customer needs.

If the attacks continue to build, Microsoft may issue an emergency fix, given they just released their patches for December and it will be nearly a month before the next set of regular fixes are released.

December 10, 2008  3:54 PM

Security chief Window Snyder leaving Mozilla

David Schneier David Schneier Profile: David Schneier

Window Snyder, the head of security at Mozilla, is leaving the company to help found a start-up venture unrelated to security. Snyder has been at Mozilla for more than two years and has been the driving force behind the company’s effort to make security a top priority in its popular Firefox browser.

 Snyder’s departure is a blow to Mozilla, a small organization that counts on participation from the open-source community for much of its work. Snyder has helped raise the company’s profile in the security community and made transparency about security issues a key initiative. The company currently is working on a  security metrics project with security analyst Rich Mogull of Securosis that is designed to measure the relative security of Firefox in a number of different ways.

It’s unclear who will be replacing Snyder, whose official title never evolved beyond the “chief security something-or-other” she came up with when she was hired. Snyder said she is not yet ready to talk about her new venture, but said it is something she is passionate about. When she joined Mozilla in 2006, Snyder was already one of the more visible personalities in the security community, having spent several years at Microsoft and at @stake before that. During her time at Microsoft, she was one of the key players in the development of Service Pack 2 for Windows XP, a massive security upgrade that was one of the first results of the vendor’s Trustworthy Computing program. After leaving Microsoft, Snyder did a short stint at Matasano Security, a consultancy.

Mogull, who has been working on the metrics program with Mozilla for several months, said he’d been impressed with the way Snyder had worked to make security a priority within the Mozilla community. “I think she’s done a great job. I mean, think about the challenge she faced going into that,” he said. “It’s an open-source project and she’s trying to put in a structured security program in an open-source environment. It’s not the same as a commercial software company where you have very rigid processes. It’s a very engaged community and that’s one of the reasons I was so excited to work with her. She broke new ground in combining the technology for developing secure software with a project like this.”

December 10, 2008  11:37 AM

Unpatched Internet Explorer 7 flaw under attack

David Schneier David Schneier Profile: David Schneier

On the same day that Microsoft patched a slew of vulnerabilities in Office and other products, including Internet Explorer, the tubes were abuzz yesterday with news of a new exploit for IE 7 that was being used against fully patched Windows XP and Windows 2003 systems. Early reports of the attack said that it was affecting mainly users in China and other Asian countries. But there are now reports of it moving into other areas as well, and it’s likely to spread quickly.

The attack is related to the way in which IE handles XML. Microsoft is investigating the issue right now. From the excellent analysis of the attack and exploit by H.D. Moore:

The exploit can be broken down into three parts. The first part is a set of three functions used by the exploit. The first function provides the equivalent of a sleep() call, the second sprays a string into the process heap using a common technique, the third returns a string of a specific size and is used by the heap spray code. The second part of this exploit is the shellcode. Without getting into too much detail, this shellcode downloads the real payload – a Windows executable. The third part is the actual vulnerability trigger.
Exploiting this flaw relies on two core requirements; being able to force the instruction pointer to the location of the shellcode and being able to execute the shellcode once the instruction pointer has been set. The first requirement boils down to being able to allocate memory at a known location with arbitrary contents. If it is possible to control the exact location where memory is allocated, a large buffer that doubles as a nop sled is no longer necessary. The second requirement depends on the operating system, configuration, and hardware of the target system. Many of the articles that discuss browser exploits recommend that users enable Data Execution Prevention (DEP). This setting essentially breaks common heap overflow techniques by preventing shellcode from executing in memory regions that are considered “data,” such as the Internet Explorer heap. Unfortunately, DEP is not enabled in Internet Explorer 6 or 7, so unless DEP is manually enabled, it does the target little good.

Microsoft has shown a willingness recently to issue emergency out-of-band patches for critical vulnerabilities, but it likely will be several days at least before we know whether that’s going to happen.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: