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.<p>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.<p>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.
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.<p>The "ms-windows-store:" protocol is documented.[1] Some other fun things you can launch:<p>- ms-people: - Opens the contacts list program.<p>- 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.<p>- ms-windows-store: - aim user at the Windows store for a specific item<p>- bingmaps:, ms-drive-to:, and ms-walk-to: - bring up the native map application<p>- ms-tonepicker: - mess with ringtone settings<p>There's no mention of "read:", though.<p>However, any installed app can install new protocol IDs, and web pages can then trigger that app. What could possibly go wrong?<p>[1] <a href="https://msdn.microsoft.com/en-us/windows/uwp/launch-resume/launch-default-app" rel="nofollow">https://msdn.microsoft.com/en-us/windows/uwp/launch-resume/l...</a>
<i>Next match in the registry is the calculator: protocol</i><p>...<p><i>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).</i><p>The only thing in my mind when I read this was "<i>Why!? I don't even...</i>" 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:<p><a href="http://www.freeemailtutorials.com/i/operaMailGenPrefs2.png" rel="nofollow">http://www.freeemailtutorials.com/i/operaMailGenPrefs2.png</a>
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 <i>special</i> relationship with the OS" wash over me again. I prefer my applications isolated, thank you very much.<p>(Yes, I know it's not-IE-anymore-nooosir. What's in a name?)
Was this properly disclosed? Has it been fixed?<p>I didn't see anything in the article about this but I may have just missed it.<p>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".<p>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 discovered a similar vulnerability in OSX in 2004. Some things change slowly:<p><a href="https://lee-phillips.org/sshv.html" rel="nofollow">https://lee-phillips.org/sshv.html</a><p>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.)
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?
Here's a (rather nsfw, and potentially time consuming) website demonstrating some older tricks like these, <a href="http://hn.on.nimp.org/" rel="nofollow">http://hn.on.nimp.org/</a>