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.
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.
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?
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.
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:
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.
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.
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.
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.
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?
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.
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.