9 ms·
Chromium Blog: A Tale Of Two Pwnies (Part 2)
- tptacek 14y agoOnce again, there's two ways of reading this story. One way is from the attacker's perspective, baffling yourself as to how Glazunov could have found all these bugs and assembled them in the right order. The other is from the defender's perspective, gaining an appreciation for how well the security model is working that it takes an exploit this intricate to break it. Either way, you're doing something right when your documentation of a security vulnerability in your product actually serves to market the security of that product. The Chrome security team is doing a lot of stuff right.
- Splines 14y agoIt'd be interesting to read about how Glazunov & Pinkie Pie figured all this out. What did they try that worked, what didn't work, how long did they spend on this, what tools did they use?
- tedunangst 14y agoFor this exploit, the security defenses didn't impress me as much. The immediate question I have is why are there chrome:// URLs at all? It seems you could achieve a much stronger sandbox by using native UI controls that are simply not attached to the webview. Then it would not be possible to trick it into making a same origin mistake. I mean, this is standard advice for web apps and services, right? You build the control interface completely outside the main user app.
- ajross 14y agoA lot of it is just "The Way It's Done", I'm sure. The "about://" and "about://plugins" urls have worked since the very early days of Netscape (and still do in chrome, which redirects them appropriately). It's an interface that Chrome inherited. They didn't design it, so it didn't receive the same security attention.
- tedunangst 14y agoThey didn't invent it, but they've sure run with it. There's no about://downloads in firefox afaik, to pick one example from the exploit. It just feels like the obvious solution to "superuser" web pages is not some high tech intrusion system, but to not have superuser web pages. It's like every heist movie ever made where the thief dodges through the dancing laser beams. I think the ideological pressure to make literally everything be the "web" is costing them real security here. And just like the movies, it does look cool.
- dchest 14y agohttp://kb.mozillazine.org/Dev_:_Firefox_Chrome_URLs http://kb.mozillazine.org/Dev_:_Firefox_Chrome_URLs
- tedunangst 14y agoThanks. That's kinda terrifying. I knew a little about xul, but underestimated its usage because the little windows don't look quite as much like web pages. More blame for mozilla I guess...
- deleted 14y ago[deleted]
- aboodman 14y agoThere are a lot of answers to this question: 1) From a UX perspective, we prefer to have the majority of the UI within a tab. We don't want to build up an entirely separate UI hierarchy outside tabs. 2) We tried putting native UI within a tab in early versions of Chrome, and it did not feel right. There was an uncanny valley effect. If the content of a tab doesn't feel like HTML, it feels wrong. And it isn't practical to emulate the feel of HTML perfectly with native code. 3) The Chrome team puts a lot of engineering effort into making the web platform as strong as it can be. We would like to eat our own dogfood when possible.
- DanBC 14y agoOff topic but: I don't understand why on (chrome://chrome/settings/) I have blue links, blue underlined links, and buttons. I guess I could figure it out, but the meaning is opaque to me at the moment.
- BoldAsAnEagle 14y ago1) Doesnt answer the mans questions. Why do you want or need it in tabs? The users get confused, they think the browser control is a foreign webpage. 2) Native look and feel, which is not a web page as it is not.
- emmelaich 14y agoI agree that these urls would be a target for exploits; an obvious place to target. I even guessed that this change to 'unreachables' was part of closing the security hole: http://news.ycombinator.com/item?id=3686730 http://news.ycombinator.com/item?id=3686730
- petegrif 14y agoMind blowing. And so great you publish it all to improve the product.
- datr 14y agoIn Part 1 it's mentioned that they held up publishing this issue as it affects many other products: "While these issues are already fixed in Chrome, some of them impact a much broader array of products from a range of companies. So, we won’t be posting that part until we’re comfortable that all affected products have had an adequate time to push fixes to their users." Presumably this is referring to other webkit browsers and the wordpad.exe exploit. Does anyone know if these problems have been fixed yet?
- tedunangst 14y agoThe wordpad exploit, unless I'm mistaken, is basically just the equivalent of LD_PRELOAD. As such, there's nothing to fix. This may be of some interest, as it there's some discussion of when it's an exploit and when it's just the way things are supposed to be. http://news.ycombinator.com/item?id=3005832 http://news.ycombinator.com/item?id=3005832
- kvnn 14y agoGoogle has changed the relationship between exploiters and themselves into something symbiotic and fun. How refreshing it is to hear excitement and admiration when a large tech company speaks about an exploit made in one of its products. Super awesome. [ See http://blog.chromium.org/2012/02/expanding-chromium-security-rewards.html http://blog.chromium.org/2012/02/expanding-chromium-security... ]
- vibrunazo 14y ago$60k seems kind of cheap after reading all that.
- deleted 14y ago[deleted]
- rosstafarian 14y agoyeah it's a pretty amazing hack. I believe the guy who wrote it is a university student from russia(who also found other holes in chrome) so for him the $60k will go quite a bit further then for some one else and the prestige/job offers associated with it will go even further then that. When the event was going on, another group called vupen(french company that deals in selling 0day exploits to govts) that found a hole in chrome during that contest refused to give up their method, when offered $120k instead of $60 and their ceo half jokingly said he might give it up for the entire million dollars worth of prizes google was offering
- deleted 14y ago[deleted]
- jmillikin 14y agoIs anyone else dismayed by the implicit view of these sorts of articles, that browsers should be complicated and full of all these insecure features? It reminds me strongly of PDF and Acrobat. PDF is great for mailing around print-ready documents, which are more-or-less guaranteed to look the same for every viewer. Writing a PDF renderer is not easy, but it is straightforward, and there are multiple stable implementations without significant security problems. Then Adobe comes along and they add forms, and 3D charts, or Javascript, or multimedia, and Acrobat grows from a document viewer into what is essentially a backdoor on every Windows computer. A similar thing is happening with browsers. The core purpose of a web browser is the ability to render HTML+CSS into a human-readable document. Then browser vendors added forms and Javascript, so XSS was invented. They added persistent data storage, so looking at cat pictures can compromise my bank account. And now, Chrome+Firefox are /competing/ to see who can add more features, security be damned. WebGL exposes your graphics drivers (never security-audited before) to the internet. <audio> and <video> expose multimedia codecs, which in the past have caused numerous security problems. Flash is, essentially, a cross-platform way to let arbitrary people run exploits on your machine. When will it stop? When will browser vendors take a collective breath, look around, and realize the insanity they've been perpetrating?
- ajross 14y agoIf browsers didn't do it then some other software would fill the niche. Having general purpose computers to run code written by other people is something everyone wants. Your attitude above seems to be that Javascript is a bad thing, which IMHO is just insane. And the bit about "security be damned" is just flat wrong, as evidenced by the linked article. They're working very hard at getting the sandbox architecture right, and have been so successful that it takes a hack of this magnitude to actually break it.
- jmillikin 14y ago> If browsers didn't do it then some other software would > fill the niche. Having general purpose computers to run > code written by other people is something everyone wants. It's fine to run code written by other people, but that code should be run in a safe, completely sandboxed environment. Modern smartphones have it right -- the user downloads an application, typically written in native code (or pseudo-native, for Android), and that application has only very limited access to the system. The $0.99 game I downloaded does not have the ability to inject keylogging code into my bank management application, and this is enforced by the OS itself. > Your attitude above seems to be that Javascript is a bad > thing, which IMHO is just insane. I don't think it's insane at all. Implementing applications as the moral equivalent of a highly-dynamic text document is what's insane. The concept of a "web app" is fundamentally broken, but despite users largely rejecting it (see: popularity of native apps vs safari apps on iPhone), nerds keep pushing it because it seems like a cool plot to a sci-fi novel. > And the bit about "security be damned" is just flat > wrong, as evidenced by the linked article. They're > working very hard at getting the sandbox architecture > right, and have been so successful that it takes a hack > of this magnitude to actually break it. This is security after the fact. If they actually cared about security, they'd disable Javascript, disable Flash, disable WebGL, and turn Chrome back into a web browser. When a boat is sinking because the hull was made of cardboard, don't point to the conveniently-placed bailing buckets as evidence of good engineering.
- mcot2 14y agoThe idea of "perfect security" is a myth. The best approach to security is doing exactly what google is doing: Off the top of my head: 1.) Spend a lot of time and money on security engineering. 2.) Constantly update, make sure it is not a hassle for users to update. Preferably force them to update, design with patching and updates built in and with minimal impact. 3.) Hire/pay a lot of people to try to break your shit. 4.) Keep a keen eye out for undisclosed vulnerabilities/exploits on the black market and have an easily accessible reporting mechanism for white hats which you do not pay. 5.) Notify the crap out of your uses when something goes wrong. You can easily see why programs such as old versions of Adobe Flash and Reader were terrible from a security perspective if you try to compare them to the above criteria. Talking about complexity and operating system design opens up a new can of worms. With iOS I think Apple is taking the extreme approach which works for like 99% of people who are not power users... 1.) Isolate everything. 2.) No third party apps that Apple does not approve. 3.) Everything is digitally signed. 4.) Limit apps from running other code. 5.) Be able to kill switch apps or wipe the device remotely.