Hacker News new | past | comments | ask | show | jobs | submit login
Abusing Protocols to Load Local Files, Bypass the HTML5 Sandbox, Open Popups (brokenbrowser.com)
323 points by jontro on Nov 26, 2016 | hide | past | web | favorite | 43 comments



Exotic protocols being somewhat succeptible to exploits is nothing new (Chrome, Firefox, and Safari have had these in the past as well) and they generally get fixed pretty quickly.

However, the fact that the "read:" protocol is a thing -- and the fact that it works the way it works -- is absolutely insane. Who in their right mind would think that's a good idea? Forget sandboxing, who's bright idea was it to let a web browser access local files willy-nilly? Mind-boggling.

The first thing I'd say if someone came to me with that idea is (a) no way and (b) if you really want to do it, you need a security mechanism like 300x stronger than CORS and probably a popup that lets the user know what's going on.


Even (b) is pushing IMO. There's a reason the standards have evolved to be this restrictive. If you want to allow a way to get around those restrictions (with "you" being a browser vendor), then you should go through the standardization process.

9/10 these "good intentioned" additions to browsers end up being used in exploits, and even if they aren't just being in one browser is rarely useful.


Yep, totally agree. The exploiting potential far outweighs the usefulness.


I don't know, I can't see any way that the read: protocol is any more vulnerable than the file: protocol (standard on all browsers), other than the fact that the code is probably less battle-tested.


The part of the string before the comma may do something interesting; further reverse-engineering may reveal its purpose, but what I'd like to know more is what application(s) actually use read: and for what.


From the function names in the stack trace, I assume it's the internal protocol used for "Reading View" https://support.microsoft.com/en-us/help/17204/windows-10-ta...


That somewhat makes sense, but then one wonders why it wasn't restricted in the same way as file:// or the usual http(s):// protocols. Of course "Reading View" could've been implemented in a simpler way that people were accomplishing the same thing before (either saving the pages or their URLs to a centralised place), but leave it to MS to reinvent it in the form of an overly complex and insecure solution...


It's so Microsoft. Microsoft has a long history of executing anything that looks executable, going back to "autorun" on CD-ROMs. This continued through a long history of Excel and Word executable behaviors, most of which led to exploits. For a few years, Microsoft cleaned up their act. But in the new cloud-centric world of Windows 10 and the Edge browser, it seems that Microsoft has returned to their old strategy of invoking Microsoft products on external data whenever possible.

The "ms-windows-store:" protocol is documented.[1] Some other fun things you can launch:

- ms-people: - Opens the contacts list program.

- ms-settings: - Opens the settings program. Microsoft encourages using this so that if your app wants, say, to access the microphone, and privacy settings won't permit it, it can force the privacy settings app open to apply pressure to the user to let the app use the microphone.

- ms-windows-store: - aim user at the Windows store for a specific item

- bingmaps:, ms-drive-to:, and ms-walk-to: - bring up the native map application

- ms-tonepicker: - mess with ringtone settings

There's no mention of "read:", though.

However, any installed app can install new protocol IDs, and web pages can then trigger that app. What could possibly go wrong?

[1] https://msdn.microsoft.com/en-us/windows/uwp/launch-resume/l...


Microsoft devs who were responsible for WinNT, Win32, IE3+ almost all retired by now. A huge brain drain. Win10 and all of their products since around 2011 are such a mess and of rather lower quality than their older products, it's not even funny anymore. It would be good for them to learn from their past mistakes, like IE and ActiveDesktop had basically the same security problems - that was fixed with WinXP and IE6, now with Win10 and Edge they are back in WinME and IE 5.5 days.


I thought the quality dive was coincident with abolishing their test teams? Didn't they do that? Made all engineers responsible for their own testing. Which is insane.


Yeah good point. The timing does line up.

http://www.networkworld.com/article/2453929/microsoft-subnet...


ActiveDesktop was the bomb. You could embed a flash video stream which shows cats playing in a pen 24/7 365 cats on your desktop.

And all your icons, still worked on top of it.


Next match in the registry is the calculator: protocol

...

There is a lot of interesting stuff here to play with, and if we keep searching for protocols we will find tons of apps that open (including Candy Crush which I didn’t know it was on my PC).

The only thing in my mind when I read this was "Why!? I don't even..." What sort of thought process (or perhaps lack thereof) lead to this ridiculously absurd situation of protocol proliferation? Who needs a Calculator or Candy Crush protocol? What's worse is there doesn't seem to be an easy way of viewing or modifying the list of registered protocol handlers. Contrast this with earlier (Presto) versions of Opera, where the protocols are configurable from the UI:

http://www.freeemailtutorials.com/i/operaMailGenPrefs2.png


Configuration is evil and confusing. The users just need to be able to open calculator from their friend's Facebook profiles.


Brb cleaning up the coffee on my lap


Protocols are often used to pass tokens from the browser to the game for authentication.


That could be done with a download and file association, like a .torrent or the way shoutcast used playlists. I remember Unreal Tournament used unreal:// for connecting to servers so you could use web-based server browsers, but I wondered why not use download approach. It's more cross-platform since every OS supports file associations but not browser supports custom URL handlers.


That will clutter up the user's downloads folder with a bunch of files they don't understand what they're for.

.torrent files are also superseded by magnet URLs for public downloads


Don't most browsers download to a temp folder if the user selects "open" instead of "download"?


OAuth requires a redirect_uri.


tons of Product Managers need to justify their salary every year, so they come up with new ways to add more crap into already bloated Windows


Well, there you go. New IE, same as the old IE. Glad I don't have any of that anymore - reading the article, I felt the dread of "but this browser has a special relationship with the OS" wash over me again. I prefer my applications isolated, thank you very much.

(Yes, I know it's not-IE-anymore-nooosir. What's in a name?)


No wonder. Edge is based on the improved and refactored IE11 (trident) HTML codebase. The rather good UI of IE 3-11 has been replaced with a lousy new UI. One step forward, two steps backwards.


Well, I would think that "interoperating with external programs" is a part of UI, not of the renderer - but that's a bit of a grey area.


Was this properly disclosed? Has it been fixed?

I didn't see anything in the article about this but I may have just missed it.

But aside from that, this is a pretty big deal. MS Edge has been looking pretty good lately. It felt like they have been taking security more seriously, and the new AppGuard stuff looked interesting, but even that doesn't look like it would fix this as it looks like this is "working as intended" letting any link communicate outside the "web sandbox".

I was hoping Edge wouldn't go down the same path that IE did with "special" tie ins to the OS, but it seems they are still trying.


> I was hoping Edge wouldn't go down the same path that IE did with "special" tie ins to the OS

Any app on Android, iOS or Windows can register themselves as a handler for an URI scheme. There is nothing "special" about that. It's up to the app author to ensure this does not expose an attack surface.


Not saying it's special, but at least on chrome it will ask if you want to open that link in another application. Here it seems at least built-in MS applications are exempt from that.


I believe that prompt is a Chrome feature, not an OS feature.


Of course it did. The first clue to that was that it was Windows 10-only. Edge is hardly a reason to "move to Windows 10", so I guess Microsoft just doesn't care about browser market share that much anymore.


The last line of the article links to the email the poster sent to microsoft security report email.


At the very bottom is did say "Reported to MSRC" with a copy of the email.


I discovered a similar vulnerability in OSX in 2004. Some things change slowly:

https://lee-phillips.org/sshv.html

At the same time, others were discovering similar vulnerabilities using other protocols. (I know the page looks like crap, so don't bother mentioning it.)


>it is trivial to construct URLs that execute arbitrary code on a web surfer's machine.

Forget the design, it's "web surfer" what gives the old page age away.

Joking aside, they've put more thought into the tel URL scheme, that allows you to start a phone call on iOS, by disallowing the use of * and # [0].

0.https://developer.apple.com/library/content/featuredarticles...


I submitted the same url earlier, but it seems the duplicate dectection didn't prevent this story from being created. Maybe because the headline was different? Not complaining; just contrary to my expectations. What is the logic behind HN's dupe-detection?


I believe it only looks back a very short time unless the old story has got points (or comments?) above a certain threshold.


Here's a (rather nsfw, and potentially time consuming) website demonstrating some older tricks like these, http://hn.on.nimp.org/


GNAA LastMeasure, extremely NSFW and somewhat well-known shocksite.

Noteworthy in that it uses alternative protocols to open dozens of other windows, and thus is able to shock users quite a bit even with JavaScript off.


It's due for a rewrite with mobile browsers and hosing the host system with expensive buffer reads and writes with canvas, and webworkers and the like.


This is very well written. Felt like I was diving in at the same time as the author.


> Let’s run the code and feel the break. Well, I feel it baby =) breakpoints connect me to my childhood.

lol


Is this windows only? I found the article somewhat hard to follow for some reason.


Yes. It's a problem with ms Edge's handling of custom URL schemes, which are registered via the Windows registry


Site is offline :o




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: