Memory exhaustion DoS vulnerability hits Google’s Chrome
“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]
Post a Comment