9 ms·
This is excellent for security. In the same way that Mozilla's PDF.js does PDF rendering in-browser and in-sandbox, doing SWF rendering in-browser and in-sandb
by willvarfar 13y ago
This is excellent for security. In the same way that Mozilla's PDF.js does PDF rendering in-browser and in-sandbox, doing SWF rendering in-browser and in-sandbox makes the security nightmare that is Flash go away.
ADDED: Mozilla blogging about security benefits of PDF.js, which apply here too to
http://andreasgal.com/2011/06/15/pdf-js/ http://andreasgal.com/2011/06/15/pdf-js/
- Tloewald 13y agoIgnoring flash does an even better job.
- richardjs 13y agoSure, and not browsing the Web at all is even safer. But it's nice to see developments that make insecure technologies more secure.
- Tloewald 13y agoWell, we assume it's more secure than simply running Flash, but we don't know. In fact it increases the overall attack surface since now there's bugs in Adobe's implementation and bugs in this implementation to exploit. Let's suppose we believe our site to be secure because we've tested it on Windows and Mac and checked the flash doesn't cause issues, and we've tested it on mobile and the flash simply doesn't work. Now we need to test all over again. Consider, for example, JPEG injection bugs. There are JPEGs embedded inside Flash content that are now being parsed by different code.
- willvarfar 13y agoWell this is counter to my understanding. As shumway - like PDF.js - is ultimately using the exact same rendering engine and scripting engine via the same interface and in the exact same way as the HTML pages are already exposing, the attack surface just got massively smaller. If there is a jpeg injection bug, its a bug in the browser proper.
- Tloewald 13y agoIt's smaller on browsers running this implementation of Flash but you're dealing with browsers running the real Flash runtime AND this new implementation, which may expose bugs you are not otherwise exposed to. Let's suppose you're an ad network and you don't want to mistakenly inject malware into other websites because that would be bad. Now you need to think of a whole bunch of new cases. E.g. you might have carefully sanitized all the JPEGs on your site, but not the ones embedded in SWFs. This is merely an example. Would it be a Good Thing if every copy of the Flash runtime magically disappeared and got replaced with this thing? Maybe. But as it is, life just got more, not less, complicated.
- reissbaker 13y agoIt might be true that as an ad network if you allow Flash files, but don't allow JS files, your life might become harder. (If you do allow JS files, your life is no different — you were already exposed to JS vulnerabilities). As a user, though, your browser is significantly more secure running Shumway than running Flash. It literally removes an entire attack vector without adding a new one. If there's an exploitable vulnerability in Firefox's JS engine, you're vulnerable to it regardless of whether you run Shumway or not — but if there's an exploitable vulnerability in Flash, you aren't vulnerable if you're running Shumway instead.
- radiusq 13y agoLet's suppose you have no idea what you're talking about.
- richardjs 13y agoFair enough. You have to be careful taking this argument too far, though, or you end up saying something like no other browser besides IE should be developed, because it increases the attack surface. Ultimately, individual users have to take charge of their own individual attack surface. If switching from one Flash player to another increases their personal security, it's a good thing.
- Tloewald 13y agoFair point. Any argument taken to extremes is probably a bad thing. In general, I'd say replacing things with emulations of things is not a good way to get better reliability, performance, or security -- now you have bugs in the original thing and the emulation of the thing to consider. In this case, the emulation lives within a restricted runtime environment and the real thing doesn't. But that's a performance / resource consumption / convenience / compatibility hit in exchange for "security", and those tend to fail simply because most people like their performance / resource consumption / convenience / compatibility.
- reissbaker 13y agoThe attack surface isn't increased. If you can exploit the vulnerability using Shumway, you could also exploit the vulnerability using vanilla JS — because Shumway is just Javascript. Shumway doesn't allow new exploits that are impossible without Shumway. Shumway decreases the attack surface of Firefox for general-purpose browsing: most people would install Flash otherwise, and this way that (infamously broad) attack vector is removed.
- X4 13y agos/Windows/Linux/g thanks :) I, Gabe Newell and many others would like to see this happen.
- robmcm 13y agoClosing your browser trumps it though...
- Anonmattymous 13y agoAgreed, I feel like by building things like this it just hampers all the work that is being built to replace flash. The best way to change things is to make it so that learning HTML5 and JavaScript becomes worth it, and that is easily done by just not supporting flash.
- robmcm 13y agoI think this is aimed at legacy support, I don't think anyone would target this as a supported runtime. Ironically most of the useful flash applications/games etc wouldn't run on these runtimes as they are using features not supported in HTML5. This sort of thing works best for crappy adverts and banners, which no one really wants anyway. This is highlighted by the fact the big competitor (Gordon?) is developed by the Google ad sense team ;)
- Tloewald 13y agoIf it were widely adopted, people would target it. If it's not widely adopted, who cares?
- robmcm 13y agoIt's adopted by having a HTML 5 compliant browser, at which point you would just use HTML 5 tools. Unless you really loved the flash IDE which I guess some people do...
- Sanddancer 13y agoThere's also a lot of flash out there generated through things like libming that people either can't or won't rewrite to use html5.
- robmcm 13y agoI expect there will be a new lib to replace that, I guess this would bridge the gap for those who don't update. I doubt ming would target this runtime though, would be very inefficient.
- rplnt 13y agoI'd be afraid that I lose control of the flash with this. As things are now, I can safely disable the flash plugin and everything is fine. If someone is able to render flash within HTML5, how can I prevent it from doing so?
- willvarfar 13y agoWell you can chose to disable pdf.js already; don't see why Mozilla wouldn't make swf.js configurable too. I'd expect flashblock plugins etc to continue to work also.
- CmonDev 13y agoJust disable JavaScript.
- DavidBradbury 13y agoAnything that this can do, JavaScript can do. If you're worried about losing control with JavaScript, then you should already have that disabled.
- robmcm 13y agoIt's this sort of person who will be calling to bring back flash, so all the annoying banners and CPU intensive code can be easily blocked.
- angle_king 13y agoIn fact IE used to lose control, so it is disabled now.
- nfoz 13y agoFlash is awful, but Firefox and the other browsers don't exactly have a great track record on security either. The less code and business built-in to the browser, the better its security.
- potatolicious 13y agoFlash's security track record is still far, far behind Mozilla's. There aren't that many runtimes in the world that find themselves in a position to be constantly scrambling to patch egregious 0-day exploits, but somehow Flash managers. Firefox is to Flash like a solid wooden door is to a screen door. Even if it isn't bulletproof, it's still a huge improvement over the status quo. And keep in mind this solution precisely fits your desires: "less code and business built-in to the browser". This Flash player runs directly on top of the existing sandbox and does not create yet-another-special-case-for-native-code. It introduces little to no additional attack surface area.
- Terretta 13y ago> doing SWF rendering in-browser and in-sandbox makes the security nightmare that is Flash go away I think it's crucial to make sure end users concerned with security understand the difference between built-in or bundled Adobe Flash Player (Google Chrome style), and what Firefox is offering. As soon as Chrome added a built-in Flash Player, it became the preferred target for hack contests, and still falls over repeatedly: http://www.securelist.com/en/advisories/52983 http://www.securelist.com/en/advisories/52983 > Multiple vulnerabilities have been reported in Google Chrome, which can be exploited by malicious people to compromise a user's system. The vulnerabilities are caused due to a bundled vulnerable version of Adobe Flash Player. That's not what Firefox is doing, and I hope the tech community helps regular users understand the difference.
- mtrimpe 13y ago> I think it's crucial to make sure end users understand the difference between built-in or bundled Adobe Flash Player And please, for the love of all that is holy, also make sure they understand what it might mean for the stability of features such as video recording. Over the past few years Chrome has repeatedly shipped PepperFlash versions with various degrees of brokenness for video recording; wreaking havoc for webcam based services across the web. Ironically enough these issues are extra hard to address, because when you tell Chrome users to 'try another browser' they all go "Nahh. I'm already on the best one."
- brokenparser 13y agoCalling shenanigans. I wrote a couple of fairly complex publishers and Chrome isn't the problematic browser (if you use ExtermalInterface correctly). It's Safari which doesn't handle plugins well, but Camera and Microphone devices should still work as Flash handles those by itself.
- MacsHeadroom 13y agoSafari has how much of the browser market share? Nobody gives two glances about Safari, mate.