Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

New Chrome Exploit Bypasses Sandbox, ASLR and DEP

Soulskill posted more than 3 years ago | from the is-it-time-for-the-disclosure-argument-again dept.

Chrome 150

Trailrunner7 writes "Researchers at the French security firm VUPEN say they have discovered several new vulnerabilities in Google Chrome that enable them to bypass the browser's sandbox, as well as ASLR and DEP, and run arbitrary code on a vulnerable machine. The company said they are not going to disclose the details of the bugs right now, but they have shared information with some of their government customers. The vulnerabilities are present in the latest version of Chrome running on Windows 7, VUPEN said."

Sorry! There are no comments related to the filter you selected.

happened to me last night :( (-1)

Anonymous Coward | more than 3 years ago | (#36076638)

I bypassed a condom and kathleen fent gave me herpes :(

Re:happened to me last night :( (-1)

Anonymous Coward | more than 3 years ago | (#36076748)

But I thought Chrome was OPEN. OOOOOOooooOOOOOhhhh. NO REASON Not to use sAFARI

Re:happened to me last night :( (-1)

Anonymous Coward | more than 3 years ago | (#36076850)

Kathleen's pussy is FREE. As in HERPES.

And.. (-1, Troll)

Anonymous Coward | more than 3 years ago | (#36076656)

10 bucks says Microsoft is responsible some how.

Putting the words "chrome" and "google" into the press release just nets them more eye balls.

Re:And.. (-1)

Anonymous Coward | more than 3 years ago | (#36076942)

Did you hear about the nigger in Alabama who was shot 14 times in the chest? The sheriff said it was the worst case of suicide he ever saw.

Re:And.. (2)

bonch (38532) | more than 3 years ago | (#36077112)

The stupidity of your post isn't the worst part. It's the fact that, as of this writing, you're modded Insightful.

Re:And.. (0)

ozmanjusri (601766) | more than 3 years ago | (#36078400)

Do you have evidence that this exploit will work on any platform other than Windows?

Re:And.. (2, Interesting)

icebraining (1313345) | more than 3 years ago | (#36077280)

Chrome's sandbox is Windows' sandbox [chromium.org] , so that's perfectly possible.

Re:And.. (2)

black3d (1648913) | more than 3 years ago | (#36077850)

I'm glad you put "possible" in italics to emphasise that this didn't necessarily mean it was the cause of the issue. Chrome implementing the sandbox, while overriding memory protection, kind of negates the purpose of the sandbox. (Although, it prevents "natively" bad stuff from affecting the system. However anything attacking the browser itself can still access system memory).

To be fair though, the demonstration of this vulnerability has exposed nothing other than the ability to load known programs in known locations, without any additional parameters. They may be able to, but that hasn't been demonstrated, and won't be if they aren't releasing any "details".

Interesting, why the government? (1)

elucido (870205) | more than 3 years ago | (#36078516)

Does this mean government contractors will get access to the exploit code?
I guess this will help them wiretap.

Re:And.. (1)

Anonymous Coward | more than 3 years ago | (#36078656)

You are confusing a Sandbox written by google for Windows with a Windows Sandbox written by Microsoft. Google WROTE the windows sandbox that chrome uses.

What about UAC? (0)

Anonymous Coward | more than 3 years ago | (#36076662)

Will your computer still ask if you want your porn website to compromise your computer?

Re:What about UAC? (1)

gcnaddict (841664) | more than 3 years ago | (#36077644)

Yes, but bear in mind that Microsoft classifies UAC as only being a security "feature" despite the fact that it's actually a user-imposed security boundary.

Disclosure policy (3, Insightful)

Anonymous Coward | more than 3 years ago | (#36076664)

"This code and the technical details of the underlying vulnerabilities will not be publicly disclosed. They are shared exclusively with our Government customers as part of our vulnerability research services."

Oh, I feel SO MUCH better now!

Re:Disclosure policy (-1)

The MAZZTer (911996) | more than 3 years ago | (#36076718)

I also like how there is no mention that 2/3 of the pwned security mechanisms are Microsoft's, not Google's.

And the last third is also uses Microsoft's integrity model when running on Vista/7.

It's most certainly a vulnerability in Chrome, but Microsoft should also be blamed here too.

Re:Disclosure policy (4, Insightful)

Anonymous Coward | more than 3 years ago | (#36076892)

Because ASLR and DEP aren't supposed to be the first line of defense, they are security in depth. The great thing about ASLR, DEP, and "stack canaries" is that you can start using them, and you get a huge amount of protection, -even if you screw up your own code-. The fact that the researchers have to go through the trouble of circumventing ASLR and DEP is a testament to their effectiveness.

ASLR and DEP just make existing vulnerabilities harder to exploit. Chrome's bug is still the culprit. Microsoft doesn't deserve -any- of the blame here.

Re:Disclosure policy (-1)

Anonymous Coward | more than 3 years ago | (#36077136)

Being able to bypass them is a testament to their bad implementation, and likely to C++ and its insecure and downright stupid control structures. Next time write your browser in C. So, -1 Google, Microsoft.

Re:Disclosure policy (3, Informative)

EvanED (569694) | more than 3 years ago | (#36077170)

Being able to bypass them is a testament to their bad implementation... ...my understanding is that ASLR's implementation isn't the best, but IMO it's more like "is a testament to the fact that needing ASLR at all is patching a gunshot with a bandaid".

And you say C++ is insecure and has stupid control structures, but then suggest writing it in C? Really?

Re:Disclosure policy (1)

DeadCatX2 (950953) | more than 3 years ago | (#36077234)

LOL I was hoping I wasn't the only person who noticed that...

Re:Disclosure policy (5, Interesting)

Rockoon (1252108) | more than 3 years ago | (#36077270)

Browsers such as Chrome contain memory allocations that avoid DEP by using VirtualProtectEx() [microsoft.com] as it is pretty much a requirement of JIT compilation.

Blaming Microsoft in this case is extremely premature, since we know that Chrome does in fact disable some protections intentionally.

Re:Disclosure policy (0)

icebraining (1313345) | more than 3 years ago | (#36077310)

Uh, the sandbox is also provided by the OS [chromium.org] , not just ASLR and DEP.

Re:Disclosure policy (1, Troll)

asdfghjklqwertyuiop (649296) | more than 3 years ago | (#36078472)

The fact that the researchers have to go through the trouble of circumventing ASLR and DEP is a testament to their effectiveness.

Testament to their effectiveness? If they broken through then they were not effective.

ASLR and DEP just make existing vulnerabilities harder to exploit.

It doesn't really matter how hard they made it if they aren't actually containing exploits, or at least some of them.

Re:Disclosure policy (0)

Anonymous Coward | more than 3 years ago | (#36076944)

You're likely right about ASLR/DEP but I doubt so about MIC - they're probably exploiting an implementation issue (like video codec parsing outside the sandbox or smth) and not a fundamental weakness wrt integrity levels.

I'm not concerned about this anyhow as the challenge posed is already so high it's eliminated most malware authors from the browser game.

Re:Disclosure policy (2)

bonch (38532) | more than 3 years ago | (#36077182)

The exploit is due to a bug in Chrome. ASLR and DEP aren't catch-all protection mechanisms; they're just a default layer of defense against bad code. I realize this is a vehemently pro-Google site that attempts to deflect any blame toward default scapegoats like Microsoft, but your position is just not accurate in this case.

Re:Disclosure policy (1)

blair1q (305137) | more than 3 years ago | (#36076894)

Are you hiding your name from everyone, or are you sharing that only with /.'s government?

Re:Disclosure policy (0)

Anonymous Coward | more than 3 years ago | (#36077402)

You're right. They should just post the exploits on every blog out there just to be transparent and trustworthy.

Re:Disclosure policy (1)

kangsterizer (1698322) | more than 3 years ago | (#36077492)

"This code and the technical details of the underlying vulnerabilities will not be publicly disclosed. They are shared exclusively with our Government customers as part of our vulnerability research services."

Oh, I feel SO MUCH better now!

They're always doing that and there's many companies like that. Basically, the bugs DO NOT GET FIXED until people (here, Google) pays up, and that's now the $5000 bounty we're talking about.
These guys literally asks thousand hundreds. If not, well, bug stay there, bad advertisement for the company, etc.

I know, people should get paid for their work, including the security researcH. But sometimes it feels like racket.

Re:Disclosure policy (1)

larry bagina (561269) | more than 3 years ago | (#36078054)

Google could pay one of their employees to track it down and fix it. If it would cost them $10,000 (opportunity cost, wages, extra time for code review or demonstrating correctness, whatever) to fix it or prevent it, then paying someone else $5,000 is a net win for them.

What about Google? (3, Informative)

d4fseeker (1896770) | more than 3 years ago | (#36076714)

Funny. I don't read anything about them disclosing it to Google (even tough they offer a bug bounty) So I'll just have to guess NSA and all the other good guys are protecting us (yeah right) until someone at Google stumbles across this issue.

Re:What about Google? (0)

Anonymous Coward | more than 3 years ago | (#36076930)

This just in, sources claim the NSA owns French security firm VUPEN! Spokespersons for the French firm categorically denied such reports but then suddenly surrendered.

Re:What about Google? (1)

AHuxley (892839) | more than 3 years ago | (#36078812)

The NSA would like to see the world use more MS. If the world ever splits into local hardened operating systems with real on duty admins, field work gets more difficult.
With MS in use/gifted at a state/federal level around the world, the US has their too kit in place. News like this shows what is been offered as finally 'safe' is really rather open.

Re:What about Google? (1)

MtViewGuy (197597) | more than 3 years ago | (#36078868)

I think the folks at the Google Chrome developer team would like to speak to the VUPEN folks and find out exactly what's going on. This is because Chrome does incremental upgrades "in the background" and Google will quietly slip in update to the browser code to close these vulnerabilities without user intervention.

Good thing... (0)

gman003 (1693318) | more than 3 years ago | (#36076734)

Good thing I already run Chrome inside another sandbox (Sandboxie). Sure, there's been exploits for that sandbox, too, but it's uncommon enough that it's extraordinarily unlikely someone would combine the exploits needed. And I have a virus-scanner and firewall running behind all that, just for good measure.

And even then I don't 100% trust it - any particularly suspicious sites are accessed by ssh-ing into my OpenBSD box (with it's own virus-scanner and custom PF rules), then running Firefox (with Javascript disabled, Java not installed, and Flash not even available on that OS) on that. I don't think any existing exploit could crack that.

Re:Good thing... (1)

Anonymous Coward | more than 3 years ago | (#36076820)

So long as you don't forget to properly affix your tinfoil hat, I'd say you're good to go!

Re:Good thing... (0)

Anonymous Coward | more than 3 years ago | (#36076846)

Stallman, is that you?

Re:Good thing... (1)

BlueScreenO'Life (1813666) | more than 3 years ago | (#36077600)

Me, running a BSD licensed OS?

I run GNU Hurd, you insensitive clod.

- rms

Re:Good thing... (1)

Anonymous Coward | more than 3 years ago | (#36076854)

You're a belt and suspenders kind of guy, aren't you?

Re:Good thing... (0)

Anonymous Coward | more than 3 years ago | (#36076858)

That's why I got this Trace Buster BUSTER!

Re:Good thing... (0)

Anonymous Coward | more than 3 years ago | (#36077070)

+1 Big Hit

Re:Good thing... (1)

ThunderBird89 (1293256) | more than 3 years ago | (#36076988)

I can crack that easily, and get at your data. You forgot rubber hose hacking...

Re:Good thing... (1)

Anonymous Coward | more than 3 years ago | (#36077076)

Last I checked Sandboxie was an IO-layer sandbox; a kernel or os/service exploit would skip right over your sandbox without even noticing its presence.

Re:Good thing... (0)

Anonymous Coward | more than 3 years ago | (#36077158)

Good thing I already run Chrome inside another sandbox (Sandboxie). Sure, there's been exploits for that sandbox, too, but it's uncommon enough that it's extraordinarily unlikely someone would combine the exploits needed. And I have a virus-scanner and firewall running behind all that, just for good measure.

And even then I don't 100% trust it - any particularly suspicious sites are accessed by ssh-ing into my OpenBSD box (with it's own virus-scanner and custom PF rules), then running Firefox (with Javascript disabled, Java not installed, and Flash not even available on that OS) on that. I don't think any existing exploit could crack that.

All you need now is a virus (or other fully automated, self-propagating malware) infecting OpenBSD machines in the wild and all the resources used by that virus scanner will be completely justified.

Really if you are running a virus scanner on any *nix machine, you're either doing it on behalf of Windows systems (i.e. on a *nix mailserver that has Windows clients) or you're doing something wrong. *nix has an effective security system and expects its administrators to know how to use it, therefore *nix doesn't have these bullshit problems.

Oh and if you were really so paranoid you'd be using Chromium, not Chrome.

Re:Good thing... (1)

gman003 (1693318) | more than 3 years ago | (#36077390)

I have the virus scanner on my BSD box so I can scan suspicious files before accessing them from my Windows boxes (the BSD box is my general-purpose "server", including running Samba). And to be fair, it's been months since I found a file suspicious enough to deserve the full treatment.

Re:Good thing... (0)

Anonymous Coward | more than 3 years ago | (#36077826)

I have the virus scanner on my BSD box so I can scan suspicious files before accessing them from my Windows boxes (the BSD box is my general-purpose "server", including running Samba). And to be fair, it's been months since I found a file suspicious enough to deserve the full treatment.

That would fit the "on behalf of Windows systems" criteria the GP already specified, making your post a completely redundant "me too!"

God damn, reading comprehension is on the decline.

Re:Good thing... (0)

Anonymous Coward | more than 3 years ago | (#36077404)

Oh and if you were really so paranoid you'd be using Chromium, not Chrome.

What makes you think he is paranoid?

Re:Good thing... (0)

Anonymous Coward | more than 3 years ago | (#36077294)

Sup dawg, I herd you liek sandboxes so I put a sandbox in your sandbox so you can sandbox while you're sandboxing!

Re:Good thing... (2)

EoN604 (909459) | more than 3 years ago | (#36077438)

I always chuckle when I hear of people disabling JavaScript in this day and age. Reminds me of a guy from an old job who used to disable images in his broswer, saying they were unnecessary bloat that weren't important and shouldn't be a part of the web.

Re:Good thing... (1)

RobbieThe1st (1977364) | more than 3 years ago | (#36077712)

Thing is, I wouldn't /like/ to have to disable JS, or run NoScript, but thanks to poor implementations of ad code, disabling it can /seriously/ speed up loading on a high(ish) latency connection.
And that's on top of all the potential attack vectors.

Speaking of which, /. runs /much/ faster on my phone when you disable JS - None of this slow ajax and hugely-long page to re-render when you add a comment.

Re:Good thing... (1)

gman003 (1693318) | more than 3 years ago | (#36077958)

Actually, I really disabled it because it's running on an Athlon 900 with 384MB of RAM. The security advantage is a side-benefit.

Re:Good thing... (2)

alostpacket (1972110) | more than 3 years ago | (#36077800)

Good luck, I'm behind 7 Sandboxies.

Re:Good thing... (2)

stimpleton (732392) | more than 3 years ago | (#36078270)

7 sand *BOXXYS* ...fixed

Re:Good thing... (1)

mlts (1038732) | more than 3 years ago | (#36077858)

Never say never. I recall reading some malware can detect the presence of vmware and/or sandboxie and get around it. Sandboxie helps, but it of limited protection on 64 bit systems.

Smug (1)

Anonymous Coward | more than 3 years ago | (#36076742)

I am so glad I run [insert smug zealous OS plug here] and not Windows!

Re:Smug (0)

Anonymous Coward | more than 3 years ago | (#36076806)

The real question is:
Does it run on Linux?

Re:Smug (1)

the linux geek (799780) | more than 3 years ago | (#36076970)

Bull GCOS 7 would never have these kinds of vulnerabilities.

Re:Smug (2)

clang_jangle (975789) | more than 3 years ago | (#36076986)

Still mistaking anyone who triggers your natural feeling of inferiority (that comes with making poor choices) for "smugness", I see. No, we're not smug -- we're just better than you.

Re:Smug (2)

flimflammer (956759) | more than 3 years ago | (#36077174)

That was pretty smug.

Pretentiousness (1)

Eponymous Hero (2090636) | more than 3 years ago | (#36077572)

"The problem with being better than everyone is that people tend to think you're pretentious."

Re:Pretentiousness (2)

clang_jangle (975789) | more than 3 years ago | (#36077764)

Actually, the problem is so many people have no self-respect, and easily dismiss anyone who does as "smug". In fact, "smug" is one of the top insults routinely hurled about by people who feel inferior. They hope to "cut them down to size", "put them in their place", etc. If they believe they achieve it, they feel slightly less inferior for a minute or two. The failure, of course, is that no-one who matters really cares about all that drama. The "smug" accusers are nearly always trolls with nothing to offer anyway. It's a branch of the "shame and blame" control drama.

Re:Pretentiousness (1)

bryan1945 (301828) | more than 3 years ago | (#36078144)

Reminds me of a certain South Park episode.

Keywords making all the difference (0)

bogaboga (793279) | more than 3 years ago | (#36076782)

that enable them to bypass the browser's sandbox, as well as ASLR and DEP, and run arbitrary code on a vulnerable machine.

"...on a vulnerable machine...". Those are the keywords. So how is it a Chrome problem when the machine itself is vulnerable?

By the way, it was about time for /. to embed video. Please allow the same for pictures especially for slashdotters here.

Re:Keywords making all the difference (0)

Anonymous Coward | more than 3 years ago | (#36076842)

One word why they will never allow for embedded pictures: goatse.

Re:Keywords making all the difference (1)

blair1q (305137) | more than 3 years ago | (#36076906)

embedded video of goatse website on grimy monitor in 3...2...

Re:Keywords making all the difference (2)

vajorie (1307049) | more than 3 years ago | (#36077038)

So how is it a Chrome problem when the machine itself is vulnerable?

The answer was in the few words before the ones you highlighted:

bypass the browser's sandbox ... and run arbitrary code

Re:Keywords making all the difference (0)

Anonymous Coward | more than 3 years ago | (#36077096)

FTFS:

The vulnerabilities are present in the latest version of Chrome

FTFA:

While Chrome has one of the most secure sandboxes and has always survived the Pwn2Own contest during the last three years, we have now uncovered a reliable way to execute arbitrary code on any installation of Chrome despite its sandbox, ASLR and DEP.

I guess I can understand not reading the article, please take the time to read the entire summary before shooting your mouth off. How did this get voted up?

Re:Keywords making all the difference (0)

Anonymous Coward | more than 3 years ago | (#36078620)

the machine is vulnerable BECAUSE it is running an exploitable version of chrome.

I don't care about theoretical/researched exploits (0)

Anonymous Coward | more than 3 years ago | (#36076848)

Tell me when an exploit of this magnitude (including the one which affected IE8) actually exists in the wild. Very few virus authors have the skill to discover and chain multiple independent exploits targeting different and non-outdated technology.

Re:I don't care about theoretical/researched explo (2)

Anonymous Coward | more than 3 years ago | (#36077020)

True, but security researchers are not fighting the scattered guy in the basement who manages to find a hole.

There are criminal organizations which are big enough to fund people in researching holes, as well as buying 0-days from the black market. Then using these either for a focused attack against a company, or cast it on the wind to gather up clients for a botnet. All is needed is a 0-day hole in a browser or browser add-on coupled with an exploit to get Administrator rights, paste this on the Web using ad rotation services, and it can easily bring in large numbers of compromised machines.

HBGary, anyone? (1)

Anonymous Coward | more than 3 years ago | (#36076870)

This "VUPEN security" company, how are they any different from HBGary? They sold 0days to governments too...

I just want the damn hole closed.

from vulpen site (2, Funny)

JonySuede (1908576) | more than 3 years ago | (#36076908)

As the world leader in vulnerability research, VUPEN provides offensive and highly sophisticated exploits specifically designed for Law Enforcement and Intelligence Agencies to help them achieve their offensive missions using tailored and unique codes created in-house by VUPEN.

God I hate those french researchers, liberty fraternity equality OR DEATH my ass

Re:from vulpen site (4, Insightful)

spongman (182339) | more than 3 years ago | (#36077046)

wait... in whose screwed up version of utopia do "law enforcement agencies" need "tailored and unique codes" in order to carry out their "offensive missions" ?

alternative choices:
1) get a bench warrant.
2) don't.

Re:from vulpen site (1)

JonySuede (1908576) | more than 3 years ago | (#36077172)

thanks, you got my point unlike the offended mod

Vulnerabilities (2)

magamiako1 (1026318) | more than 3 years ago | (#36076926)

Just throwing this out there:

These problems won't affect 95% of users. Running these sorts of attacks on end users is a bit of a waste, and something this complicated would be saved for more important targets.

A vast majority of infections out there are things that you're already guarded against if you keep your system updated.

So... (3)

CrazyDuke (529195) | more than 3 years ago | (#36077012)

You know, when I was demoing Chrome as a possible browser for my tablet, I went looking for a script blocking extension. To my consternation, I was met with the near worthless alternative of either running all scripts or none on a page, either through an extension designed like a high school side-project or using the built in white-listing feature. This is apparently because the API does not allow for functionality along the lines of blocking individual scripts from executing.

The forums and comments sections addressing user questions as to an alternative usually had self serving replies like "Chrome is so awesome that it doesn't need script blocking." and "It can't be owned due to sand-boxing. You know what sand-boxing is right?" (Because the only reason a person would ask is if they where an ignorant fool, right?)

So, *cough* tell me why Chrome doesn't need a NoScript-like extension again? @the marketing drones: Because, I'm so sure the cocksure poseur-charisma will scare the crime-ware away, really. The elephant in the room doesn't exist so long as the people that bring it up are shouted down, right?

Re:So... (4, Insightful)

VortexCortex (1117377) | more than 3 years ago | (#36077716)

You know, when I was demoing Chrome as a possible browser for my tablet, I went looking for a script blocking extension. To my consternation, I was met with the near worthless alternative of either running all scripts or none on a page, [...]

So, *cough* tell me why Chrome doesn't need a NoScript-like extension again? @the marketing drones: Because, I'm so sure the cocksure poseur-charisma will scare the crime-ware away, really. The elephant in the room doesn't exist so long as the people that bring it up are shouted down, right?

I'll tell you why: Because Google's JavaScript engine compiles any script it sees into machine code for your platform, then runs that... That's why you don't need a better option for security's sake than all or none... Machine code can't escape the sand box! (Realize the truth: There is no spoon^H^H^H^H^H sandbox.)

The problem is that modern JS engines from all the major browsers do it this way -- The design of the JS language makes it hard to make a fast interpretor for it. Even if you pre-compile to byte-code and run it in a VM it's too slow.

So instead, we take arbitrary data, compile that to machine code, then EXECUTE the compiled DATA (Data Execution Prevention, eh? Well, if it's flagging itself as executable, and it's accepting arbitrary code, I'd say that JS == Arbitrary remote code execution == one tiny step away from being an exploit anyway. I've always wondered why everyone disses ActiveX while enabling JS...

PS. I've written scripting languages. They can be slow as hell, that's the point, so long as stuff you do a lot of is formalized and written in native code, it's all good and can be run in a pretty safe interpretor or byte-code VM.

JS != general purpose compiled language.

Therefore, when you do DUMB things like complain that JS can't keep up when you try to use JS + HTML5 Canvas as your "rendering engine" for a "web application" (or even worse, games) then browser devs must meet the dumb demands by doing the dumbest thing they can against their better judgment -- Just in Time compile a virtual EXE, then run that.

The answer is to stop sacrificing security for speed, go back to software VM solutions with SIMPLE compiled languages like Lua, (I think, Lisp / Scheme too, not sure haven't checked how complex the sources are) and add standardized functions for commonly used features so we can get rid of the if(IE){...} cruft. Hint: Dynamic is the enemy of fast.

Re:So... (2)

lucian1900 (1698922) | more than 3 years ago | (#36077860)

That's bullshit. JIT compilers increase the attack surface somewhat, but not significantly.

Also, interpretation is always going to be slow. Lua is very slow without LuaJIT. So are most Scheme and Common Lisp implementations. Which is why no one in their right mind would turn of the JIT.

A JIT may be harder to write than a bytecode interpreter, but it's not much harder to make secure

Re:So... (2)

StayFrosty (1521445) | more than 3 years ago | (#36078424)

The extension you are looking for is called NotScripts. [google.com]

What makes this extra awesome: Native Client (2)

bl8n8r (649187) | more than 3 years ago | (#36077032)

This is the reason you don't want your browser able to access native OS code; when there's an exploit, the keys to the kingdom are in the browser.
http://www.theregister.co.uk/2010/12/08/google_on_native_client/

Re:What makes this extra awesome: Native Client (0)

Anonymous Coward | more than 3 years ago | (#36077356)

NaCl isn't ActiveX+LowIntegrity; if a NaCl library reached the outer sandbox, NaCl would be shown as inherently flawed. It's actually safer in some respects than the main browser is, probably most interpreters too.

Re:What makes this extra awesome: Native Client (1)

Anonymous Coward | more than 3 years ago | (#36077582)

This is the reason you don't want your browser able to access native OS code; when there's an exploit, the keys to the kingdom are in the browser.
http://www.theregister.co.uk/2010/12/08/google_on_native_client/

Native Client doesn't allow access to native OS code; it allows a restricted set of machine instructions to run in an environment that is not only heavily sandboxed, but verified pre-execution. Because it's meant to be cross-platform, it does not allow calls to the underlying OS at all. It enforces this limitation by doing a code scan to detect unauthorized instructions, unsafe branch targets, and such. It's really quite sophisticated, albeit practically unusable due to how locked down it is.

It'd be daft to say it will never be exploited, but it's hardly handing over the keys to the kingdom. Maybe you were thinking of NPAPI or ActiveX; both of those allow full access to the underlying OS APIs.

Video / Article mismatched (1)

Archangel Michael (180766) | more than 3 years ago | (#36077054)

Okay, I've watched the Video twice, and read both linked articles (yeah I did) and it said that it was ..

The video shows the exploit in action with Google Chrome v11.0.696.65 on Microsoft Windows 7 SP1 (x64). The user is tricked into visiting a specially crafted web page hosting the exploit which will execute various payloads to ultimately download the Calculator from a remote location and launch it outside the sandbox at Medium integrity level.

Well I did see the Calculator applet get started, and I do see that it is a Microsoft Version. I did not see it get "downloaded", which is acceptable if it was a background download. But I don't know if it did, or if it simply called the local version already installed as part of the OS.

Just saying the whole thing is very skimpy and light on details and specifics.

Re:Video / Article mismatched (0)

Anonymous Coward | more than 3 years ago | (#36077396)

Starting a new process is already evidence of having escaped low-IL isolation.

Re:Video / Article mismatched (0)

Anonymous Coward | more than 3 years ago | (#36078820)

Just launching Calculator implies that arbitrary code was downloaded and executed. You can't launch a process through Javascript.

They could very well be lying (0)

Anonymous Coward | more than 3 years ago | (#36077060)

The only evidence of the supposed vulnerabilities is a rather crappy video that could be easily faked.
And this is disclosed by a company that sells vulnerabilities to make a buck.
Maybe the vulnerabilities are there, in which case their behaviour is downright evil. Or maybe they aren't there, and they created the video precisely because they couldn't find a hole in Chrome and want users to switch to something less secure.

Why would the government care? (5, Funny)

dicobalt (1536225) | more than 3 years ago | (#36077064)

They run IE6.

Re:Why would the government care? (0)

Anonymous Coward | more than 3 years ago | (#36077288)

Skip this we are upgrading to IE4 on windows 98. No services in 98. We can overwrite the programs files and windows directories every few hours to 'fix' issues.

Intel vulnerable (0)

Anonymous Coward | more than 3 years ago | (#36077228)

If it bypasses the sandbox, ASLR, and DEP, wouldn't that mean that it probably exploits Intel's basic hardware flaw, a poorly implemented stack with addressable registers?

Really? (2)

petteyg359 (1847514) | more than 3 years ago | (#36077290)

1. Watching the video, I see nothing that couldn't be achieved with ExtJS.

2. Chrome often has multiple processes listed in task manager. In their video, they conveniently cover all those process names with another window so you can't see them.

3. Suspicious overuse of "pwn". No company worth respecting would use "pwn" in a press release.

Re:Really? (1)

Bitsy Boffin (110334) | more than 3 years ago | (#36078484)

Errr, perhaps you missed where they apparently had the browser start the windows calculator executable. That's a fairly fundamental ownage right there.

How the exploit will be used (5, Interesting)

Hmmm2000 (1146723) | more than 3 years ago | (#36077322)

To me the most troubling part of this issue is what VUPEN does ... from their web site -- "Exclusive and sophisticated exploits for Law Enforcement Agencies". So, the reason the exploit is not being made public is so that Government agencies can use these exploits to install keyloggers or whatever they choose on whatever computer they which to target and monitor.

Re:How the exploit will be used (1)

Anonymous Coward | more than 3 years ago | (#36077442)

What kind of professional research firm for Law Enforcement uses the "word" "Pwned" in a press release?

Re:How the exploit will be used (0)

Anonymous Coward | more than 3 years ago | (#36077496)

A French one.

Re:How the exploit will be used (1)

kangsterizer (1698322) | more than 3 years ago | (#36077514)

The French.

Re:How the exploit will be used (0)

Anonymous Coward | more than 3 years ago | (#36077566)

No, the reason it's only being made partially public is, I can only assume, to drum up business because they don't have any customers - if they did, we wouldn't hearing about the exploit at all.

Suspect (0)

Anonymous Coward | more than 3 years ago | (#36077760)

If the motivation in not disclosing the bug is preventing Google from patching it, then why did they even announce it? That doesn't make sense.

Something smells fishy. I haven't RTFA, has anyone been able to verify that these bugs are actually real?

Before everyone start yelling "fake" (2)

Anne Honime (828246) | more than 3 years ago | (#36078162)

A quick search turns out VUNET co-founder BEKRAR Chaouki was the winner of pwn2own 2011 : http://www.zdnet.com/blog/security/safarimacbook-first-to-fall-at-pwn2own-2011/8358 [zdnet.com]

Not to say it proves he did it again with chrome, but at least; the guy's got some credits for being able to pull this one.

http://www.happyshopping100.com (0)

irisvvv (2133468) | more than 3 years ago | (#36078534)

our website: http://www.happyshopping100.com/ [happyshopping100.com] watches price 75$ Air jordan(1-24)shoes $30 Nike shox(R4,NZ,OZ,TL1,TL2,TL3) $35 Hndbags(Coach lv fendi d&g) $35 Tshirts (Polo ,ed hardy,lacoste) $16 Jean(True Religion,ed hardy,coogi) $30 Sunglasses(Oakey,coach,gucci,Armaini) $15 New era cap $10 Bikini (Ed hardy,polo) $25 FREE SHIPPING,accept paypal free shipping accept paypal credit card lower price fast shippment with higher quality BEST QUALITY GUARANTEE!! SAFTY & HONESTY GUARANTEE!! FAST & PROMPT DELIVERY GUARANTEE!! **** http://www.happyshopping100.com/ [happyshopping100.com] ***

Stuff you can figure out from the video... (1)

ben.craig (2133680) | more than 3 years ago | (#36078748)

If you look closely, the first time the video shows process explorer, the PID of the parent chrome process is 1388 with integrity at "Medium", and a child chrome process's PID is 1928 with integrity set at "Low". After the hack, process explorer shows a child chrome process with PID 804 and integrity "Medium", all other processes except for the calculator are obscured. I can guess-timate that the original parent and child are still there though, as there is still a low integrity process somewhat near the bottom of the list.

After looking at the documentation for process explorer, the gray colored process line (most likely the parent chrome process) is suspended, which seems odd. I'm not entirely sure I'm seeing the correct part of the process explorer docs here.

Another thing to note is that the calc.exe process has no parent. That means that whatever spawned it has already died.

The video suggests that a fairly standard ASLR attack was made: guess and check. ASLR makes it difficult to reliably guess an address the first time. Most of the time, if a hack guesses wrong, the process dies and the attacker doesn't get another chance. It seems that the attacker found a place (or made a place) where they could "guess" repeatedly. Given the prior information, that suggests that the child process somehow caused the parent process to repeatedly spawn chrome subprocesses that had some attacker controlled information in it. Each time, that information is probably a little bit different until the attacker guessed "right", and successfully executed the right attack code.

Re:Stuff you can figure out from the video... (1)

ben.craig (2133680) | more than 3 years ago | (#36078814)

Or maybe the gray colored process line is just the last selected process, which makes way more sense.

Responsibility (1)

fred133 (449698) | more than 3 years ago | (#36078852)

Since they aren’t informing the Vendor so it can get patched,
Are they going to take responsibility when it does get into the wild?
Oh, we‘re big security company, we’re secure!
  Yeah right!
Show me a boat that doesn’t leak!

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?