back to article Google applies patch to nasty Chrome vulns

Google has pushed out a patch for two severe vulns found in its Chrome browser. Mountain View released Chrome yesterday that fixes an attack on Google's V8 JavaScript engine. Mozilla security wonks spotted the Chrome security flaw in V8. It could have allowed an attacker to gain access to sensitive information, by …


This topic is closed for new posts.
  1. Dave 145

    Up to Date

    Thats why real people use chrome 4.0.202. Google are slipping if the beta is 2 full versions infront of the release

  2. David Heffernan

    Security is safe in Google's hands

    I'm confused. When Google announced Chrome OS on their official blog they said:

    "And as we did for the Google Chrome browser, we are going back to the basics and completely redesigning the underlying security architecture of the OS so that users don't have to deal with viruses, malware and security updates. It should just work."

  3. Alan 6

    Up to Date 2

    Mine shows as up to date at v3.0.195.6 so why is my beta one version behind Dave 145 - or maybe he is posting from the future...

  4. Anonymous Coward

    Re: Security is safe in Google's hands

    The Javascript vulnerability is a memory reading vulnerability. It only allows the page to see things that are in your browser's memory. If the attacker is lucky, then you may have just logged onto your bank and there may be your bank's password there. This is unlikely though - in practise this is not a very good attack. They can't use this attack to install malware.

    The XML vulnerability is more serious, as it allows the attacker to run arbitrary code. In any other browser (IE, Firefox, Opera), then this would allow full access to your PC and the ability to install malware. However, Chrome has an additional layer of protection called a "sandbox", that restricts what the attacker can do. It's still a serious bug, but it can't easily be used to infect your PC with viruses or malware.

    So, these bugs are the kind of thing that happen to all browsers, and congratulations to Google for having designed their browser to limit the impact of these bugs.

  5. Sam Mason

    RE: Security is safe in Google's hands

    The disclosure does say "An attacker might be able to run arbitrary code within the Google Chrome sandbox." *Within the sandbox* is the important part, and means that the attacker's code is severely hampered and would have to exploit some sort of privilege escalation within windows to get out and touch the user's (or the system's) files or network connection. This is good because the attacker would have to have two working zero-day exploits (one in chrome and one in windows) to have a chance of attacking an uptodate system.

  6. Glen 9


    I would like to thank our new time travelling overlord Dave 145.

  7. Anonymous Coward


    Your versions so last week!

    I'm on 4.0.202 too.

  8. Tsvetomir Tsonev


    Maybe he means the Dev channel?

  9. dave lawless

    another layer is another layer

    User code gets tricked into executing user code, when hasn't this been the case?

    It's a symptom of "worse is better". Operating as though this is not the case is living in denial. That's why I boot from read only file systems and my data storage is append only.

    Processing enormous volumes of externally produced data some of which is garaunteed to have malicious intent in executables that are garaunteed to be defective by machines with convenient access to the LAN and WAN, what do you expect?

    That such machines are ubiquitous demonstrates our enormous capacity for denial.

    I've had people say to me that the security model of Lunix was better because "you'll only lose your home direcotory", you know the irreplacable files, where as the system files were totally protected, you know, the files you downloaded in 30 mins from one of 100 places

  10. Alan 6

    @dave lawless

    I think you may need a double layer of foil in your hat...

  11. TeeCee Gold badge

    @Sam Mason

    Yes, but given Google's strategy of "run everything in the browser" with the O/S kernel there merely to support the browser in question, that's not necessarily a comfort.

    Ok, yer botnet may become a rarity*, but when his bank account's just been raided, his gmail account's become a sewer of spam and his Google docs have all been replaced with farmasutra pics that's not exactly going to cheer up Joe Punter now, is it?

    I did have a sneaking suspicion that all this approach was going to do is move the most rewarding attack surface from the O/S itself to the browser sandbox.

    *Then again, maybe not. Think about ChromeOS. Under that model, does the fact that your botnet client is running in the browser sandbox rather than in the O/S kernel make it any less effective? I'll grant it'd be a sight easier to remove and probably more tricky to make persistant.

This topic is closed for new posts.

Other stories you might like