Defense in Depth

On Wednesday, Microsoft announced new security features within the upcoming release of Internet Explorer 8 Beta 2. The features are designed to combat the rising tide of drive-by downloads and malicious scripts contained within carefully crafted links embedded in e-mail and Web pages. Most of the new features require systems to be running Windows Vista SP1 or Windows XP SP3.

Perhaps the most anticipated addition is Internet Explorer's new antimalware protection. Opera 9.5 and Firefox 3 both recently added antimalware protection. Safari has so far not announced plans for similar protection. Using mostly its own antimalware technology, Microsoft will block emerging threats by masking the entire IE 8 browser screen with a warning to users. The addition of malware protection to the existing antiphishing protection will be re-branded as the Microsoft SmartScreen filter.

IE 8 Beta 2 will have a Cross Site Scripting (XSS) filter, preventing scripts within a link from executing on the browser.

Previously announced features include highlighting domain names from the rest of the URL (so you can visually see that you are on eBay.com, not some other site), and extended verification SSL.

Using Data Execution Protection (DEP) within Windows XP SP3 and Windows Vista SP1, IE 8 will scan downloads and block any that it deems dangerous.

(Credit: Microsoft)

IE 8 Beta 1 has already introduced several changes when handling ActiveX components. Components will be installed per user, which eliminates the need for everyone to have administrator privileges. In addition, you must acknowledge or opt-in for the component to run, eliminating drive-by downloads. Components will be per site and will only be available from site of origin. Finally, site developers can request killbits from Microsoft which can be sent via Windows Update to terminate risky or outdated components.

For developers, Microsoft is including improvements for better communication between the client browser and Web server. Cross Domain Requests (CDR) is a more secure way for the browser to pull data from other domains; and Cross Domain Messaging (XDM) is a more secure means for a browser to send a message across a domain. Microsoft says it is working with other browser vendors to standardize these.

The public Beta 2 for Internet Explorer is expected sometime in August 2008.

On Monday, Adobe Systems rolled out its new Web 2.0 development tool, Adobe Integrated Runtime, or AIR. Following its release were some concerns from the security community.

Adobe CEO Shantanu Narayen talks up AIR at a San Francisco event.

(Credit: Charles Cooper/CNET News.com)

AIR, formerly Adobe Apollo, is a runtime environment that allows developers use HTML, Flash, AJAX, Flex, and other Web 2.0 tools to create desktop applications. One such application built using Adobe AIR comes from Nickelodeon Online.

But some security experts are concerned about local file access by AIR applications. Recently, Firefox experienced a vulnerability that could have allowed remote attackers to access a targeted file system. To mitigate this, Adobe says it implemented a sandboxing environment, however, Adobe's documentation suggests that the sandboxes are less secure than a Web browser's sandbox.

Additionally, Adobe says that AIR applications need to be digitally signed, however, these certificates can be self-signed. And many users will ignore the warnings and run untrusted applications.

Finally, there is the potential for Cross-Site Scripting (XSS), SQL injection, and local link injection. While these threats are not limited to Adobe AIR, developers could gain a false sense of security by relying only on AIR's weaker sandbox protection.

Adobe has also provided the following: an informative article titled "Introduction to AIR security" and a white paper, "AIR Security" (PDF). But Lenny Zeltser, writing on the Sans Internet Storm Center site, notes that "many developers will be unaware of Adobe AIR security best practices or will knowingly take shortcuts that expose end users to attacks."

Security researcher Aaron Weaver claims visiting a random Web site could send unwanted print requests to your nearest office printer.

In a paper published in November (PDF), and cited on Wednesday in a blog by Jeremiah Grossman of White Hat Security, Weaver demonstrates the code necessary for sending a formatted page to a remote network printer, and, in an another example, to an intranet addressable fax machine. Since most network printers are behind the corporate firewall and therefore don't have security enabled, Weaver says that a simple iframe added to an Internet Web site could cause an internal network printer to start printing remotely.

The attack is derived from techniques employed within a project called hacking network printers by Adrian "Irongeek" Crenshaw. Weaver notes that most network printers listen on port 9100 and that you can telnet to port 9100, type text, and, once you disconnect, the text will print remotely. That's fine, but he ventures further that network printers also accept PostScript and Printer Control language (PCL) code as well, which creates more interesting printouts.

Weaver writes "within the last year there have been new discoveries on attacking the intranet from the Internet. This involves setting an image tag or script tag to an internally addressable IP address and then the browser will request the 'image' resource. Several attacks can be accomplished; port scanning, fingerprinting devices, and changing internal router settings."

Add to that list, printer spam. "The attack could be initiated by creating a hidden iframe, and then creating a form and submitting the contents to the printer. Since the connection will not close, a setTimeout could be used to cancel the request so that the printer would print the request."

As a demonstration, Weaver shows how to send an ASCII-drawn advertisement for frogs, and later, using PCL, a message in 20-point Courier: "Your printer is mine!"

One positive use for this would be for the IT or HR department to send a persistent banner reminding employees about the company's printer use policies. A negative use would be to remotely spam all the printers on the local intranet.

At the end of the short paper, Weaver offers some remediation. "First always have an administrator password set on your printer. Secondly look at restricting access to the printer so that it only accepts print jobs from a centralized print server."