Chromium Blog: A Tale Of Two Pwnies (Part 2)(blog.chromium.org)
blog.chromium.org
Chromium Blog: A Tale Of Two Pwnies (Part 2)
http://blog.chromium.org/2012/06/tale-of-two-pwnies-part-2.html
68 comments
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. 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.
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.
> 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.
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.
> 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.
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.
> 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.
But those access limits are enforced in similar ways to the access limits imposed by browsers on web content, and they are regularly broken in similar ways too. Just like a browser, the attack surface of a smartphone OS includes image rendering libraries, font rendering libraries, 2D and 3D graphics engines, media codecs, and, umm, JavaScript and HTML rendering engines.
Systems like iOS and Android have copied (and improved, I will freely admit) one of the web's most important features -- what the brower calls the same-origin policy. It's the idea that one developer's code doesn't automatically have access to the data from all your other apps/sites. But modern desktop operating systems still don't have this feature, which is one reason desktop users are still way more willing to use your web site than they are to download and run your native application.
But those access limits are enforced in similar ways to the access limits imposed by browsers on web content, and they are regularly broken in similar ways too. Just like a browser, the attack surface of a smartphone OS includes image rendering libraries, font rendering libraries, 2D and 3D graphics engines, media codecs, and, umm, JavaScript and HTML rendering engines.
Systems like iOS and Android have copied (and improved, I will freely admit) one of the web's most important features -- what the brower calls the same-origin policy. It's the idea that one developer's code doesn't automatically have access to the data from all your other apps/sites. But modern desktop operating systems still don't have this feature, which is one reason desktop users are still way more willing to use your web site than they are to download and run your native application.
When was the last time there was an outbreak of malware on Apple iTunes or Google Play? How many users were affected?
Compare that to the near-monthly announcement of new browser security vulnerabilities, either in the browser itself or a bundled component (e.g. Flash).
If a smartphone application exploits an image rendering or font library, it doesn't gain any additional permissions. It can't do anything with a vulnerable library that it couldn't do otherwise.
The important attack surface on smartphones is local kernel exploits, which are rare.
If every web page had its own full chroot/jail (or equivalent), then they would be as secure as native applications. But in the current model of web pages as accessed through a browser, this is impractical to implement.
Compare that to the near-monthly announcement of new browser security vulnerabilities, either in the browser itself or a bundled component (e.g. Flash).
If a smartphone application exploits an image rendering or font library, it doesn't gain any additional permissions. It can't do anything with a vulnerable library that it couldn't do otherwise.
The important attack surface on smartphones is local kernel exploits, which are rare.
If every web page had its own full chroot/jail (or equivalent), then they would be as secure as native applications. But in the current model of web pages as accessed through a browser, this is impractical to implement.
iTunes apps are manually approved by apple. I don't think that's a reasonable security measure for the web.
Yes, those are all valid and important points -- as I said above, mobile operating systems have taken the browser's conceptual model and improved it. They've made technical improvements (using the kernel's security policies and mechanisms) and non-technical ones (providing a trusted distribution channel with the ability to ban malware apps). I agree that browsers are behind in important ways.
But I'm not so sure that local kernel exploits are that much rarer than, say, Chromium sandbox exploits, which play a similar role in mitigating vulnerabilities exposed to untrusted code. (Not all of those monthly vulnerability announcements actually allow code execution.)
I think in practice the curated App Store model helps much more to prevent outbreaks of attacks in the wild. Google Play, which does not review apps before publishing them, has had malware problems. And since users and usability are still a weak link in the permission system, not all mobile malware even needs to circumvent technical measures to gain the privileges it wants.
And browsers still offer safety advantages over native apps on the desktop systems that currently account for the majority of browser usage.
But I'm not so sure that local kernel exploits are that much rarer than, say, Chromium sandbox exploits, which play a similar role in mitigating vulnerabilities exposed to untrusted code. (Not all of those monthly vulnerability announcements actually allow code execution.)
I think in practice the curated App Store model helps much more to prevent outbreaks of attacks in the wild. Google Play, which does not review apps before publishing them, has had malware problems. And since users and usability are still a weak link in the permission system, not all mobile malware even needs to circumvent technical measures to gain the privileges it wants.
And browsers still offer safety advantages over native apps on the desktop systems that currently account for the majority of browser usage.
Breaking out of the iOS jail is fairly easy. For a long time, you could jailbreak from a web page!
Breaking from an app, to other apps, is easy but pointless, as your app and developer licence will get revoked fairly quickly.
Breaking from an app, to other apps, is easy but pointless, as your app and developer licence will get revoked fairly quickly.
>When was the last time there was an outbreak of malware on Apple iTunes or Google Play?
Almost every day for Android?
https://www.google.com/search?client=opera&rls=en&q=...
>How many users were affected?
Not as few as you think.
One example http://www.crn.com/news/security/240000735/report-android-ma...
You can find many more if you look.
http://www.techwireasia.com/3306/mobile-malware-on-the-rise-...
Almost every day for Android?
https://www.google.com/search?client=opera&rls=en&q=...
>How many users were affected?
Not as few as you think.
One example http://www.crn.com/news/security/240000735/report-android-ma...
You can find many more if you look.
http://www.techwireasia.com/3306/mobile-malware-on-the-rise-...
> If every web page had its own full chroot/jail (or equivalent), then they would be as secure as native applications.
This is exactly what Chrome has always done and other browsers are adopting: plugins have long had to have elevated privileges (I'm no expert on why), but if you exploit an image rendering or font library, you get nothing, because the browser and each tab's renderer are separate processes, and the latter are heavily sandboxed through the OS. This bug is impressive and the first of its kind because it doesn't attack a plugin, but the sandbox itself, (indirectly) through the IPC mechanism. In that sense it's not much different from attacking the iOS sandbox: web pages have more access to cross-origin communications (and other functionality that must pass through the sandbox, such as downloads), and there seem to generally be more situations where the renderer has to synchronize with the browser, but that's mostly a matter of degree.
This is exactly what Chrome has always done and other browsers are adopting: plugins have long had to have elevated privileges (I'm no expert on why), but if you exploit an image rendering or font library, you get nothing, because the browser and each tab's renderer are separate processes, and the latter are heavily sandboxed through the OS. This bug is impressive and the first of its kind because it doesn't attack a plugin, but the sandbox itself, (indirectly) through the IPC mechanism. In that sense it's not much different from attacking the iOS sandbox: web pages have more access to cross-origin communications (and other functionality that must pass through the sandbox, such as downloads), and there seem to generally be more situations where the renderer has to synchronize with the browser, but that's mostly a matter of degree.
Chrome's sandbox is not equivalent to having a separate jail for every web site. It is designed to prevent web content from attacking non-browser apps and data, not to prevent one web page from attacking another (though Chrome, like all browsers, has other mechanisms to do this).
Chrome does not guarantee one process per tab, or even per origin. If you reach its internal process limit -- or if a page does something like window.open() that gives it a reference to another tab -- then it will render multiple sites in the same processes, not sandboxed from each other: http://code.google.com/p/chromium/issues/detail?id=81877
Chrome does not guarantee one process per tab, or even per origin. If you reach its internal process limit -- or if a page does something like window.open() that gives it a reference to another tab -- then it will render multiple sites in the same processes, not sandboxed from each other: http://code.google.com/p/chromium/issues/detail?id=81877
Chrome is designed to guarantee that web content never cohabitates in a process with chrome:// URLs. Unfortunately, in this case that code was buggy.
There's nothing fundamentally different about Chrome's approach here than what you are advocating.
At some level, these policies have to be implemented with code, and that code can have bugs.
There's nothing fundamentally different about Chrome's approach here than what you are advocating.
At some level, these policies have to be implemented with code, and that code can have bugs.
> When was the last time there was an outbreak of malware on Apple iTunes or Google Play? How many users were affected?
Daily, based on the number of apps I see where the updates include security fixes.
> If every web page had its own full chroot/jail (or equivalent), then they would be as secure as native applications.
You should read up on the Chrome security model - they're trying hard to produce this.
Daily, based on the number of apps I see where the updates include security fixes.
> If every web page had its own full chroot/jail (or equivalent), then they would be as secure as native applications.
You should read up on the Chrome security model - they're trying hard to produce this.
> If a smartphone application exploits an image rendering or
> font library, it doesn't gain any additional permissions.
> It can't do anything with a vulnerable library that it
> couldn't do otherwise.
Haven't phones on both platforms been rooted via local exploits, just like the ones you describe?
> The important attack surface on smartphones is local kernel exploits, which are rare.
The important attack surface on Chrome is sandbox model exploits, which are rare.
Haven't phones on both platforms been rooted via local exploits, just like the ones you describe?
> The important attack surface on smartphones is local kernel exploits, which are rare.
The important attack surface on Chrome is sandbox model exploits, which are rare.
> It's fine to run code written by other people, but that code should be run in a safe, completely sandboxed environment.
… which is what browsers do with JavaScript and have done since Netscape shipped the first Navigator beta with LiveScript. The problem is that no containment system is perfect because people want rich functionality which can be abused without significant care - your $.99 game certainly isn't supposed to be able to install a keylogger but in practice it's almost always been possible to do so because that operating system doesn't have magic security pixie dust, either, and mistakes are made.
The only reason browsers have a bad reputation for security is because Microsoft exposed a ton of native code, ignoring advice from security experts, and completely neglected their responsibility as a platform maintainer for almost a decade.
Firefox and Chrome are a different story, both having a better security track record than, say, a Microsoft operating system despite having a full rich experience. Chrome's better than your mobile operating system because it actually gets updated quickly whereas your mobile OS gets updated on a timescale of months (iOS, Android developer phones) to never (most Android phones and almost all others).
> 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.
You have an uncommon and counter-factual understanding of the web and users. Please back up your claim that users don't actually want Gmail, Facebook, Flickr, Google Maps, etc. or that mobile users only want native applications despite mobile users showing heavy web activity.
> 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.
Back into a 1995 web browser which wouldn't do anything which users expect. If you're so uncomfortable trusting a browser with a better security track record than most operating systems, you can easily disable all of those features but since the Chrome team both cares about and actually understands security they've focused on defense in depth and and rapid response rather than trying to convince users they don't actually want the things they ask for.
… which is what browsers do with JavaScript and have done since Netscape shipped the first Navigator beta with LiveScript. The problem is that no containment system is perfect because people want rich functionality which can be abused without significant care - your $.99 game certainly isn't supposed to be able to install a keylogger but in practice it's almost always been possible to do so because that operating system doesn't have magic security pixie dust, either, and mistakes are made.
The only reason browsers have a bad reputation for security is because Microsoft exposed a ton of native code, ignoring advice from security experts, and completely neglected their responsibility as a platform maintainer for almost a decade.
Firefox and Chrome are a different story, both having a better security track record than, say, a Microsoft operating system despite having a full rich experience. Chrome's better than your mobile operating system because it actually gets updated quickly whereas your mobile OS gets updated on a timescale of months (iOS, Android developer phones) to never (most Android phones and almost all others).
> 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.
You have an uncommon and counter-factual understanding of the web and users. Please back up your claim that users don't actually want Gmail, Facebook, Flickr, Google Maps, etc. or that mobile users only want native applications despite mobile users showing heavy web activity.
> 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.
Back into a 1995 web browser which wouldn't do anything which users expect. If you're so uncomfortable trusting a browser with a better security track record than most operating systems, you can easily disable all of those features but since the Chrome team both cares about and actually understands security they've focused on defense in depth and and rapid response rather than trying to convince users they don't actually want the things they ask for.
It's fine to run code written by other people, but that code should be run in a safe, completely sandboxed environment.
There are no verifiably sandboxed environments on any consumer IT equipment.
The $0.99 game I downloaded does not have the ability to inject keylogging code into my bank management application
It might do.
Implementing applications as the moral equivalent of a highly-dynamic text document
I wasn't aware that moral equivalence was such an issue in dynamic text. Oh, that kind of dynamic text, you should have said. There's some tissues in the cupboard.
nerds keep pushing it because it seems like a cool plot to a sci-fi novel
Nope. Not enough spaceships, lasers or robots.
If they actually cared about security, they'd disable Javascript, disable Flash, disable WebGL, and turn Chrome back into a web browser
All of those bar webGL precede chrome by lots. And on that model of security, you might as well just not bother plugging in the computer in the first place.
I do want a cardboard boat though. I wonder if Shigeru Ban will make one if everyone asks him really nicely.
There are no verifiably sandboxed environments on any consumer IT equipment.
The $0.99 game I downloaded does not have the ability to inject keylogging code into my bank management application
It might do.
Implementing applications as the moral equivalent of a highly-dynamic text document
I wasn't aware that moral equivalence was such an issue in dynamic text. Oh, that kind of dynamic text, you should have said. There's some tissues in the cupboard.
nerds keep pushing it because it seems like a cool plot to a sci-fi novel
Nope. Not enough spaceships, lasers or robots.
If they actually cared about security, they'd disable Javascript, disable Flash, disable WebGL, and turn Chrome back into a web browser
All of those bar webGL precede chrome by lots. And on that model of security, you might as well just not bother plugging in the computer in the first place.
I do want a cardboard boat though. I wonder if Shigeru Ban will make one if everyone asks him really nicely.
I'd just like to point out that Google significantly raised the state of the art with respect to browser security, specifically because they made it central to their effort. They had a more secure browser within a year than the other vendors had created since the birth of the web.
This is a minor setback and I have no doubt that they've learned not only just how to fix this set of bugs, but the bug classes they represent.
Netscape won (at the time) partly on "features", so browser competitors have to release features, balanced with their other priorities. Can't go back, can only go forward as responsibly as possible. Chrome has done this admirably.
I suggest looking at these tests through a half-full glass. There's a huge benefit in discovering multi-bug exploits, for Chrome, Google, other browser vendors and all users. When an attacker is looking to break into a computer, Chrome is not their most obvious starting point. In fact, IIRC Kevin Mitnick said this:
"KH: What’s the most secure OS? Is there one that you can recommend?
KM: I don’t know of any secure OS. In the past eight years, I’ve had 100% success at penetration testing on all of them. Wait, ChromeOS, ChromeOS is the most secure because of its very limited attack vector–there’s just nothing to exploit."
http://www.zdnet.com/blog/security/ghost-in-the-wires-the-ke...
That's progress, surely.
This is a minor setback and I have no doubt that they've learned not only just how to fix this set of bugs, but the bug classes they represent.
Netscape won (at the time) partly on "features", so browser competitors have to release features, balanced with their other priorities. Can't go back, can only go forward as responsibly as possible. Chrome has done this admirably.
I suggest looking at these tests through a half-full glass. There's a huge benefit in discovering multi-bug exploits, for Chrome, Google, other browser vendors and all users. When an attacker is looking to break into a computer, Chrome is not their most obvious starting point. In fact, IIRC Kevin Mitnick said this:
"KH: What’s the most secure OS? Is there one that you can recommend?
KM: I don’t know of any secure OS. In the past eight years, I’ve had 100% success at penetration testing on all of them. Wait, ChromeOS, ChromeOS is the most secure because of its very limited attack vector–there’s just nothing to exploit."
http://www.zdnet.com/blog/security/ghost-in-the-wires-the-ke...
That's progress, surely.
This comment is wrong on just so many levels.
You seem to think that browser are less secure than running native software. This is totally absurd. And this blog entry shows exactly that. In order to bypass the advanced sandboxing techniques employed by modern browsers you have to build up complex chains of dozens of bugs.
This is very different with desktop software. Desktop software is protected far less than code running in the browser.
So the idea that running apps in the browser makes you more vulnerable than running native applications seems very unrealistic.
Also you seem to have the very nostalgic view that the web should be just static websites with a few links in between. This concept again seems completely absurd. From my point of view as a PHP programmer the dynamic web is pretty much the best thing that happened to mankind. It allows you to run software without having to install it. From everywhere. From the the point of view of the end user this is still true. Just look around. Look at Facebook, Twitter and stuff.
You seem to think that browser are less secure than running native software. This is totally absurd. And this blog entry shows exactly that. In order to bypass the advanced sandboxing techniques employed by modern browsers you have to build up complex chains of dozens of bugs.
This is very different with desktop software. Desktop software is protected far less than code running in the browser.
So the idea that running apps in the browser makes you more vulnerable than running native applications seems very unrealistic.
Also you seem to have the very nostalgic view that the web should be just static websites with a few links in between. This concept again seems completely absurd. From my point of view as a PHP programmer the dynamic web is pretty much the best thing that happened to mankind. It allows you to run software without having to install it. From everywhere. From the the point of view of the end user this is still true. Just look around. Look at Facebook, Twitter and stuff.
> Is anyone else dismayed by the implicit view of these sorts of articles, that browsers should be complicated and full of all these insecure features?
You're taking a position 100% against all additions to web browsers, it seems. And some people responding to you are taking the 100% opposite position. But there is a middle ground.
Browsers should include the minimal amount of technology possible, and strike a compromise between number of features and security (because more features always means less security). What the right compromise is, is of course debatable.
But I don't want to just say "extremes are wrong, the right middle way is best" in a generic manner because that's always true. More specifically, Google is the browser vendor including the most nonstandard technologies these days, and therefore incurring the most risk. For example, NaCl, WebSQL, a large extension API (even including things like text to speech), a closed-source PDF reader, Adobe Flash, Chrome Web Store frontend, and apparently soon Dart. All those things add to the attack surface of Chrome, I would argue needlessly.
Of course other browsers are guilty of similar things, just to a lesser extent. At least Microsoft does not bundle Silverlight with IE (but it will apparently bundle Flash..).
You're taking a position 100% against all additions to web browsers, it seems. And some people responding to you are taking the 100% opposite position. But there is a middle ground.
Browsers should include the minimal amount of technology possible, and strike a compromise between number of features and security (because more features always means less security). What the right compromise is, is of course debatable.
But I don't want to just say "extremes are wrong, the right middle way is best" in a generic manner because that's always true. More specifically, Google is the browser vendor including the most nonstandard technologies these days, and therefore incurring the most risk. For example, NaCl, WebSQL, a large extension API (even including things like text to speech), a closed-source PDF reader, Adobe Flash, Chrome Web Store frontend, and apparently soon Dart. All those things add to the attack surface of Chrome, I would argue needlessly.
Of course other browsers are guilty of similar things, just to a lesser extent. At least Microsoft does not bundle Silverlight with IE (but it will apparently bundle Flash..).
I don't think my position is extreme. I'm not advocating for a removal of all browser features, merely removal of those which are unrelated to the browser's core purpose of document navigation and rendering.
If browser vendors spent less money on implementing audio synthesis or OpenGL, they could spend more on font rendering, SPDY, and standards compliance.
If browser vendors spent less money on implementing audio synthesis or OpenGL, they could spend more on font rendering, SPDY, and standards compliance.
>I don't think my position is extreme. I'm not advocating for a removal of all browser features, merely removal of those which are unrelated to the browser's core purpose of document navigation and rendering.
The view that a browser's core purpose is document rendering and navigation was laughably out of date in 2000. It is simply an invalid opinion today. Users and developers can and do expect browsers to be fully-functional sandboxed runtimes that can host everything from mail clients, to mapping applications to games.
But if you want your browser to be nothing more than a document rendering engine, no one is forcing you to use Firefox. w3m and xxxterm, for example, both fulfill this role quite admirably.
The view that a browser's core purpose is document rendering and navigation was laughably out of date in 2000. It is simply an invalid opinion today. Users and developers can and do expect browsers to be fully-functional sandboxed runtimes that can host everything from mail clients, to mapping applications to games.
But if you want your browser to be nothing more than a document rendering engine, no one is forcing you to use Firefox. w3m and xxxterm, for example, both fulfill this role quite admirably.
> But if you want your browser to be nothing more than a
> document rendering engine, no one is forcing you to use
> Firefox. w3m and xxxterm, for example, both fulfill this
> role quite admirably.
w3m, yes. But xxxterm is basically webkit with vi keybindings, so I don't think Chrome can be all that many years ahead.
> I'm not advocating for a removal of all browser features, merely removal of those which are unrelated to the browser's core purpose of document navigation and rendering.
Fair enough, but what people consider to be documents has changed. Some documents have 3D elements in them, for example architectural content. And some documents benefit from embedding sounds, like Wikipedia pages that contain small relevant snippets of audio. So I think it's hard to know where to draw the line.
But again, I do agree a line needs to be drawn. The browser industry as a whole should work together to define that, in a standards-based way.
Fair enough, but what people consider to be documents has changed. Some documents have 3D elements in them, for example architectural content. And some documents benefit from embedding sounds, like Wikipedia pages that contain small relevant snippets of audio. So I think it's hard to know where to draw the line.
But again, I do agree a line needs to be drawn. The browser industry as a whole should work together to define that, in a standards-based way.
You may be minimizing the attack surface, but just because a web browser only supports HTML and CSS doesn't mean it couldn't contain exploits.
It's possible that the HTML parser or image rendering library has a bug and that malformed HTML could cause a vulnerability in the browser. Granted, I believe it would be significantly easier to harden parsers and graphic rendering, but it's already been shown that certain image rendering libraries have been exploited[1].
[1] Example: http://technet.microsoft.com/en-us/security/bulletin/ms08-02...
It's possible that the HTML parser or image rendering library has a bug and that malformed HTML could cause a vulnerability in the browser. Granted, I believe it would be significantly easier to harden parsers and graphic rendering, but it's already been shown that certain image rendering libraries have been exploited[1].
[1] Example: http://technet.microsoft.com/en-us/security/bulletin/ms08-02...
>At least Microsoft does not bundle Silverlight with IE (but it will apparently bundle Flash..).
If I remember correctly, Flash is only enabled for a set of whitelisted sites. But, as we see, someone will probably chain that to some other vulnerability.
If I remember correctly, Flash is only enabled for a set of whitelisted sites. But, as we see, someone will probably chain that to some other vulnerability.
It's definitely safer with a whitelist, however it is still riskier than not shipping Flash at all. A limited exploit might get around the whitelist, and then use any second exploit of Flash to break completely through.
Yes. I too am dismayed.
There used to be something called MIME. There used to be separate specialised applications for different tasks.
Guess what? There still are.
Browsers have long had the ability to decode image formats. That much we expect from the browser.
But audio? Video? "Web sockets"?
There are better applications to handle these formats and tasks than a web browser.
When I want to listen to audio, I use an application that is designed for that.
When I want to watch video, I use an application that is designed for that.
When I want to open sockets for peer-to-peer communication, I use an application that is designed for that.
Everyone knows browsers suck for downloading. So why are we using them to download content (whether to a file or to a buffered cache)?
Download the content using a program that is designed for downloading.
View/play the content with applications designed for those tasks.
Anyone who would criticise this approach is criticising the "UNIX way". Do one thing well. But watch how people will criticise it.
Yes, it is insanity.
These browsers are always going to have performance issues. If you want the best audio, video, peer-to-peer, etc., use applications that were designed for those purposes. As simple as possible. Simple applications. That is how you achieve performance, reliability and security.
"Do-everything" browsers and Javascript are not not worth the risks they present.
There used to be something called MIME. There used to be separate specialised applications for different tasks.
Guess what? There still are.
Browsers have long had the ability to decode image formats. That much we expect from the browser.
But audio? Video? "Web sockets"?
There are better applications to handle these formats and tasks than a web browser.
When I want to listen to audio, I use an application that is designed for that.
When I want to watch video, I use an application that is designed for that.
When I want to open sockets for peer-to-peer communication, I use an application that is designed for that.
Everyone knows browsers suck for downloading. So why are we using them to download content (whether to a file or to a buffered cache)?
Download the content using a program that is designed for downloading.
View/play the content with applications designed for those tasks.
Anyone who would criticise this approach is criticising the "UNIX way". Do one thing well. But watch how people will criticise it.
Yes, it is insanity.
These browsers are always going to have performance issues. If you want the best audio, video, peer-to-peer, etc., use applications that were designed for those purposes. As simple as possible. Simple applications. That is how you achieve performance, reliability and security.
"Do-everything" browsers and Javascript are not not worth the risks they present.
Web sockets are not for P2P. They're just raw TCP sockets to servers with an initial HTTP-like handshake.
Personally, I can fully understand your points, and I actually take exactly that approach (using youtube-dl + mplayer for Youtube, extracting the streaming URLs from online radios and plugging them in MPD, etc).
But, as a Linux user, I'm all too accustomed to be left out from many applications because this platform isn't profitable enough to develop to.
Browser applications break with the monoculture of Windows (or, on mobile, iOS+Android) because they're portable and open by default. And I think that has some value.
Personally, I can fully understand your points, and I actually take exactly that approach (using youtube-dl + mplayer for Youtube, extracting the streaming URLs from online radios and plugging them in MPD, etc).
But, as a Linux user, I'm all too accustomed to be left out from many applications because this platform isn't profitable enough to develop to.
Browser applications break with the monoculture of Windows (or, on mobile, iOS+Android) because they're portable and open by default. And I think that has some value.
The problem with such an approach is that it makes computers hard to use - hard enough that 99% will not want to use it.
So… what are you proposing? We go back to the web as it was in 1995?
I propose we give up on the flawed idea of "web apps", and go back to native applications. Mac OS, iOS, and Android show us that this is both possible and practical.
The web can continue to be what it was and should be, a set of interlinked documents to be interpreted by applications installed on the local computer.
The web can continue to be what it was and should be, a set of interlinked documents to be interpreted by applications installed on the local computer.
Sure. Provide me a realistic way to provide an application across Windows, Linux, OSX, Android, iOS and platforms I haven't even considered with the same codebase (allowing for minor changes to coincide with the cross-platform hacks that go into CSS/JS) and it might be realistic.
But even then, we've still got to deal with the unwillingness of users to install applications versus their total willingness to visit a web page.
But even then, we've still got to deal with the unwillingness of users to install applications versus their total willingness to visit a web page.
So... you're advocating that we roll back the last decade or so of web development.
Good luck with that.
Good luck with that.
Why not just properly sandbox web apps?
You'd have to give each web page its own sandbox, at which point installing/using it is no more convenient than a native application.
You're using a web application right now.
You think that's air you're breathing?
Aye, and it would be a much nicer experience if it were native.
Except for everyone who wants to use it outside of the select few OSs for which it would be written.
Web apps are by definition more secure. Well, as secure as the browser, and those are very secure today.
browsers are the new operating system, but what was learned in security architecture of operating systems wasn't carried across.
chrome et al at the moment (and other browsers) are the security equivalent of DOS - single user, unprotected memory, no file permissions etc.
a lot has been done well with isolating the browser from the operating system, but within the browser itself is where more and more interesting information is being held, and the security model there is almost non-existant.
chrome et al at the moment (and other browsers) are the security equivalent of DOS - single user, unprotected memory, no file permissions etc.
a lot has been done well with isolating the browser from the operating system, but within the browser itself is where more and more interesting information is being held, and the security model there is almost non-existant.
[deleted]
I think people are ignoring the end plan.
Native Client isn't for running apps quickly. It's for finally letting Google create a sandbox that they can run their own browser in.
Probably won't happen until HVM support is growing at a certain level.
Native Client isn't for running apps quickly. It's for finally letting Google create a sandbox that they can run their own browser in.
Probably won't happen until HVM support is growing at a certain level.
Once 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.
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.
It'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?
For 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.
I mean, this is standard advice for web apps and services, right? You build the control interface completely outside the main user app.
There 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.
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.
Off 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.
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.
A 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.
They 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.
Thanks. 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]
I 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
Google 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... ]
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... ]
In 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?
"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?
The 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
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
The 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.
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.
$60k seems kind of cheap after reading all that.
yeah 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
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]
Mind blowing. And so great you publish it all to improve the product.
[deleted]
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?