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
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 2.0.172.43 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 …
-
Wednesday 26th August 2009 15:30 GMT 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."
-
-
Thursday 27th August 2009 00:13 GMT 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.
-
Thursday 27th August 2009 00:13 GMT 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.
-
-
Thursday 27th August 2009 00:13 GMT 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
-
Thursday 27th August 2009 10:18 GMT TeeCee
@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.
