4 X Security Team

A security researcher wants Microsoft to follow the lead of other browser makers and start fixing Internet Explorer security problems outside of the Patch Tuesday cycle to help contain the Windows malware epidemic.

[ Microsoft: ‘Consistent exploit code likely’ for IE vulnerabilities ]

According to Wolfgang Kandek, chief technology officer at vulnerability management firm Qualys, IE’s dominant userbase and high risk profile exposes Windows users to a wide range of malicious hacker attacks but, despite years of warnings, business users are not rushing to install IE patches ahead of other critical updates (see chart below).

[ SEE: Hackers exploiting (unpatched) IE 7 flaw to launch drive-by attacks ]

The chart, powered by data collected by Qualys over the last six months, shows that critical IE patches are applied in very much the same speed as other high-priority updates.

I had a chat with Kandek about his findings and he was adamant that the risk presented by a critical IE vulnerability is higher than another critical flaw in another piece of software that doesn’t interact directly with the Internet.

• “Every month when Microsoft issues it security advisories we get asked what patch to apply first. Typically we are reluctant to elevate one vulnerability over the other, however looking at the 2008 data we agree that Internet Explorer vulnerabilities should be given the highest priority and patched first. The browser is the heaviest used software application that interacts with the Internet, the most likely source of malicious content. It is not only used for professional purposes but also in private interactions – e-commerce, social networking, private e-mail, etc. Browser patches are heavily tested by Microsoft and unlikely to break any existing functionality on the desktop.

Unfortunately, Kandek says the vulnerability data shows that companies treat browser patches just like all other patches — their deployment cycle correlates very closely with other critical patches.

The answer? Kandek argues that Microsoft should borrow from the Mozilla Firefox playbook and fit an automatic-update utility directly into IE to handle patching on the fly.

“Think about it. There’s a very big exposure area. Hackers are increasingly targeting the browser. Enterprises are on a tight patch schedule. If IE got moved out of Patch Tuesday, won’t it be better?” he added.

[ GALLERY: How to configure Internet Explorer to run securely ]

“Patches would be deployed faster and we would have a healthier IE population,” Kandek added, nothing that IE add-ons like Flash and other media players would benefit from an automatic update tool embedded in the browser.

The Qualys data was culled from 9.5 million IP scans per month.

* Hat tip to Gregg Keizer at ComputerWorld.

[Source: zdnet]

UPDATE: Google explains, blaming “human error.”

A major hiccup at Google this morning caused the entire Internet to be flagged as malware.

The problem appears to be centered around the Google Safe Browsing API — even that returned a “This site may harm your computer” warning (see screenshot below) — the security diagnostics service that powers Firefox’s malware blocking service.

There has been no official word from Google yet but the blogosphere and Twittersphere is abuzz with screenshots and complaints from unhappy Web surfers. (See Techmeme discussion).

For a short period during the hiccup, Firefox was blocking access to Web sites with the standard “This is an attack site!” warning.

With all the damaged reputations from this episode, how soon before we see a high-level warning about the dangers of the Google monoculture?

a high-priority Chrome browser patch with fixes for three security vulnerabilities that expose users to cross-site scripting and data theft attacks.

Google Chrome’s beta and stable channels have been updated to version 1.0.154.46 to mitigate an issue with the Adobe Reader plug-in (two separate vulnerabilities) and to fix a bug in the V8 JavaScript engine could allow bypassing same-origin checks.

The skinny:

• CVE-2007-0048 and CVE-2007-0045: Workaround for Adobe Reader Plugin Open Parameters Cross-Site Scripting Vulnerability
  • Google Chrome now refuses requests for javascript: URLs in Netscape Plugin API (NPAPI) requests from the Adobe Reader plugin. Adobe is aware of this issue and has helped us develop this mitigation while they work on a fix for all users.
  • Severity: Moderate. This could allow a PDF document to run scripts on arbitrary sites.

• CVE-2009-0276: Javascript Same-Origin Bypass
  • A bug in the V8 JavaScript engine could allow bypassing same-origin checks in certain situations.
  • Severity: High. A malicious script in a page could read the full URL of another frame, and possibly other attributes or data from another frame in a different origin. This could disclose sensitive information from one website to a third party.

The patch (see release notes) also fixes problems with Yahoo Mail and Windows Live Hotmail.

ALSO READ:

• Google adds HTTPS-only browsing to Chrome
• Google Chrome, the security tidbits
• Google Chrome vulnerable to carpet-bombing flaw
• Google hires browser hacking guru

Google has quietly released a pre-beta version of Google Chrome 2.0 with a new HTTPS-only browsing mode.

The new feature lets users add “force-https to your Google Chrome shortcut” to only load Web sites with valid security certificates. “Sites with SSL certificate errors will not load,” the company explained.

The newest Chrome release also updates the WebKit and V8 JavaScript engines, offers a better implementation for SafeBrowsing (malware/phishing protection), and new code for the HTTP network protocol.

Google’s release notes provide more detail on the changes.

ALSO SEE:

• Google Chrome, the security tidbits
• Google Chrome vulnerable to carpet-bombing flaw
• Google hires browser hacking guru

Third party plug-ins like Adobe Flash do a poor job of cleaning traces of your browser sessions, rendering private-browsing features somewhat useless, according to a new study by researcher Katherine McKinley.

McKinley, a researcher at iSec Partners, created a tool for testing the functionality of clearing private data after a browser session and browsing in private mode and found that some browsers — most notably Apple’s Safari for Windows — do a poor job of wiping traces of a browser session.

[ SEE: Microsoft confirms ‘InPrivate’ IE 8 ]

McKinley warns (.pdf):

Third party plug-ins like Adobe Flash, which is far more popular than any individual browser or platform, seem to undermine the data protection schemes offered by all common browsers, however. While browsers are introducing more features with privacy implications, such as persistent local storage, they have mostly integrated the management of this type of information into a single location. When users want to ensure their privacy with respect to information stored via the browser standard methods, they can go to a single location to clear the data, use a separate browser, or use a working private browsing mode, if available.

Plug-ins need to take extra steps to ensure the privacy of their users. The clear best practices in this area, as exemplified by Google’s Gears, prompts users before allowing a site to store data on their system, holds a per-browser data store, and integrates their management UI into the browser UI. Adobe Flash does none of these things, instead silently allowing web sites to store data, uses one global data store for all browsers, and uses a settings UI accessible only when the user is connected to the Internet.

[ SEE: Major Web browsers fail password protection tests ]

She called on browser vendors and plug-in vendors to cooperate to make their platforms more trustworthy:

A set of standard APIs to communicate the need for plug-ins to clear data for a particular origin, all sites, or even a date range needs to be developed, and its use required of all plugins. In the absence of these APIs, plugins which require use of any local system resources should prompt before allowing web sites to store data locally, and integrate the management of interface into the standard browser API.

In the study, McKinley tested the data storage on modern browsers, including HTTP cookies, HTML 5 session storage, Mozilla Firefox perisistent storage, HTML 5 database storage, IE userData, Adobe Flash and Google Gears.

[ SEE: Firefox scrambles to add ‘private mode’ browsing ]

Apple’s Safari on Windows, which offers a “Private Browsing” option, did not fare well:

The HTML 5 Database store on Safari is not cleared when resetting the private data, the user must go to their preferences and select Security, then click the “Show Databases” button on that tab to review or delete databases. For IE 8 Beta 2, the browser must be closed to actually clear the data for the running instance. In each of these cases, it is necessary to perform additional actions to effectively clear this data.

And more:

Safari on Windows fared the worst of all in [tests] with respect to private browsing, and did not clear any data at all, either before entering or after exiting the private mode. On OS X, Safari’s behavior was quirky; in no case was the HTML 5 database storage cleared before or after private browsing. Previously set cookies seem to continue to be available if the user entered a private browsing session, but if the user started the browser and went directly into private browsing, it seemed to behave as expected.

* Image source: 253C. Hat tip to NYT’s Brad Stone.

[Source: zdnet]

The first security patch for Google’s new Chrome browser is out, fixing at least two “critical” vulnerabilities that put Windows users at risk of code execution attacks.

[ SEE: Google Chrome vulnerable to carpet-bombing flaw ]

The patch, which is rolled out automatically via Chrome’s auto-update feature, also addresses two additional security vulnerabilities — the carpet-bombing issue and a denial-of-service flaw that could lead to browser crashes and data loss.

From the release notes:

• Fixes a buffer overflow vulnerability in handling long filenames that display in the “Save As” dialog. This is a critical risk that could lead to execution of arbitrary code. See here for fix details.
• Fixes a buffer overflow vulnerability in handling link targets displayed in the status area when the user hovers over a link. This is a critical risk that could lead to execution of arbitrary code. The issue was reported privately to Google. Fix details here.
• Fixes an out of bounds memory read when parsing URLs ending with :%. This is a low risk that can be used to crash the entire browser, possibly causing loss of data in the current session. Fix information here.
• The update also changes the default Downloads directory if it is set to Desktop to ensure that Desktop cannot be the default. This mitigates the risk of malicious cluttering of the desktop (aka carpet bombing) with unwanted downloads, which can lead to executing unwanted files.

[ SEE: Google Chrome vulnerabilities starting to pile up ]

Curiously, user agent for the fully patched version of Chrome (version 0.2.149.29) is still showing WebKit 525.13 (Safari 3.1) , meaning that Aviv Raff’s two-click PC takeover vulnerability is still unpatched.

I just tested Raff’s proof-of-concept that combines two flaws — one in Safari and one in Java — and was still able to execute code without warning. Strange.

Just hours after the release of the Google Chrome browser last month, researcher Aviv Raff discovered that he could combine two vulnerabilities — a flaw in Apple Safari (WebKit) and a Java bug — to trick users into launching executables direct from the new browser. (Here’s a demo showing how a Google Chrome users can be lured into downloading and launching a JAR (Java Archive) file that gets executed without warning.

Now, it looks like Google is finally taking the threat seriously with the release of a new Chrome version to developers that changes the download behavior for files that could execute code.

From the changelog:

• This [version] adds prompting for dangerous types of files (executable) when they are automatically downloaded.
• The file is saved with a temporary name (dangerous_download_xxxx.download) in the download directory and the user is presented (in the download shelf and the download tab if opened) with a warning message and buttons to save/discard the download.
• If discarded the download is removed (and its file deleted). If saved, download goes as usual.
• Dangerous downloads not confirmed by the user are deleted on shutdown.

ALSO SEE:
Google Chrome vulnerable to carpet-bombing flaw
Google Chrome, the security tidbits

[Source: zdnet]

en testing, Google, Denial of Service (DoS), Google Chrome

Aditya K Sood from the EvilFingers community, which disclosed the first Chrome DoS vulnerability at the beginning of the month, has released a proof of concept demonstrating a memory exhaustion DoS vulnerability affecting Google’s Chrome versions Chrome/0.2.149.30 and Chrome/0.2.149.29 :

“The Google chrome browser is vulnerable to memory exhaustion based denial of service which can be triggered remotely.The vulnerability triggers when Carriage Return(\r\n\r\n) is passed as an argument to window.open() function. It makes the Google Chrome to generate number of windows at the same time thereby leading to memory exhaustion. The behavior can be easily checked by looking at the task manager as with no time the memory usage rises high. The problem lies in the handling of object and its value returned by the javascript function. Once it is triggered the pop ups are started generating. The Google Chrome browser generate object windows continuously there by affecting memory of the resultant system. Probably it can be crashed within no time. User interaction is required in this.”

What’s Google’s take on this flaw, and have they acknowledged it already? Zero Day asked the researchers.

Q: This is the second DoS vulnerability that members from EvilFingers disclose. How is the second one different than the first one, and how would a remote attacker take advantage of it?

A: Ideally, both are Denial of Service attacks. But second one is different for the matter that it does a memory exhaustion, or I would say “performance” peaks with the pop-ups. By default, all the pops are blocked by Chrome, but still the CPU usage jumps up to 98% and so does the memory consumption, therefore other processes will surely be affected. And then the PoC for the first one crashes the chrome right away without any reaction time to the user or any user way to prevent the loss of work. But with the second one, an experienced user can prevent the same and can save work of other tabs before resulting in a browser restart. Or put in another way, first one is a crash of all tabs, second one is a hang of tabs.

Q: Since you’re responsibly disclosing the vulnerabilities that you find to Google, what is your opinion on their current response time and overall attitude towards the vulnerabilities that you’ve reported?

A: Response time with the first one was well appreciable, as it was fixed within 24hrs though it took some days to roll out next 0.2.149.29 ‘patched’ version. For this newer DoS, the patch is yet to roll out and they have acknowledged the bug for now.

Has Google’s Chrome level of exploitability changed since the first DoS vulnerability? It may well be declining considering some recently published browser market-share statistics, clearly indicating that a lot of users seems to have given Chrome a try, and are back to their default browsers. According to published Chrome stats by Net Application :

“At the end of its third week of availability, Google Inc.’s Chrome accounted for 0.77% of the browsers that visited the 40,000 sites tracked by Net Applications, down from a 0.85% share the week before. “The trend line on Chrome still has a slight downward angle, and these weekly numbers reflect that,” said Vince Vizzaccaro, Net Applications’ executive vice president of marketing. Although Chrome popped above 1% within hours of its release, the new browser now reaches that mark only in the middle of the night, U.S. time, Vizzaccaro added.”

StatCounter’s latest Chrome stats of over 450M page views globally, also indicate the introduction period and the slight decline afterwards. Chrome’s popularity is proportional with its level of exploitability, so keeping an eye on how many users stick with the (BETA) browser, will either increase or decrease it.

[Source: zdnet]

Google has seeded a new version of its Chrome browser to developers with fixes for a pair of security issues that could expose users to data theft.

The issue, rated as a “moderate” risk could allow hackers to use HTML files to steal arbitrary files from a victim’s machine.

Details below:

• r4188 and r4827 Address an issue with downloaded HTML files being able to read other files on your computer and send them to sites on the Internet. We now prevent local files from connecting to the network using XMLHttpRequest() and also prompt you to confirm a download if it is an HTML file.
  • Severity: Moderate. If a user could be enticed to open a downloaded HTML file, this flaw could be exploited to send arbitrary files to an attacker.

The patch, which will eventually be rolled out via Chrome’s automatic update feature, also adds new features around bookmarking and pop-up blocking.

[Source: zdnet]

That nifty password management feature in your favorite Web browser could be helping identity thieves pilfer your personal data.

That’s the biggest takeaway from the results of this test which shows that all the major Web browsers — including IE, Firefox, Opera, Safari and Chrome — are vulnerable to a total of 20 vulnerabilities that could expose password-related information. Among the problems are three in particular that, when combined, allow password thieves to take passwords without the user’s knowledge. They are:

1. The destination where passwords are sent is not checked.
2. The location where passwords are requested is not checked.
3. Invisible form elements can trigger password management.

Google’s shiny new Chrome browser was among the worst offenders. According to the study, Chrome’s password manager contains multiple unpatched issues that “form a toxic soup of potential vulnerabilities that can coalesce into broad insecurity.”

Apple’s Safari for Windows browser was also failed a majority of the tests (click image for full version):

Technical details of the test, which was conducted by Chapin Information Services, can be found here.