Not that shocking. Windows has had that with SMB networking for ages file://SMBSERVERNAME/path/file . Linux somewhat supports /dev/tcp/HOSTNAME/PORT (technically that's application level in bash so not everywhere), and im sure there's daemons you could run to automount things on the fly.
Do note that this has been disabled in the major distributions at compile time for pretty much ever. The debian bug to build bash with that feature by default is ~20 years old (and was closed as wontdo).
Terminal 1
$ echo hi > /dev/tcp/127.0.0.1/9999
Terminal 2
$ nc -vvvlp 9999
Listening on [0.0.0.0] (family 2, port 9999)
Connection from 127.0.0.1 57540 received!
hi
$Whereas a domain name over the open internet is an entirely different story.
Can’t trust these two or ,,, who can we trust for network security.
-- https://twitter.com/TartanLlama/status/1375045731644538882
In POSIX we only generally get a user/group level of granularity which seems to practically mean that only daemons are completely isolated.
For instance the dropbox binary can only access "/home/dropbox" and "/net/dropbox.com" if this was more well-known/used.
Except we have some grandfathered file types that are implicitly trusted.
until ... one day ... they are!
Would be nice if the operating system could set up a fresh, temporary "user" for each application installed, and instead run the application as that user, who starts out with no access to computing resources. Maybe some existing systems already sandbox apps into their own unprivileged users, I don't know, but it would probably be very secure.
But often when such sandboxes are attempted, it turns out that it often became more complex than originally thought, and applications need many resources which were not originally considered, so they are given those resources, and very often those resources can be used again to construct more resources or otherwise to some measure escape the sandbox.
I honestly don't understand how anyone with at least a basic understanding of how OSes are designed and operated could ever arrive at that conclusion. The layers of wrong assumptions required to support that assertion are in the level of "not even wrong" confusions.
I fail to see how HTTP and REST's "everything is a resource" paradigm is significantly different than UNIX's "everything is a file" paradigm, and I'm yet to see anyone claim that the freedom and power to open any HTML document (OMG a file!) made available through the internet is a mistake or a bad design decision.
On the other side Unix has users and permissions, HTTP does not and you have to build your own.
Unfortunate that the author didn’t mention this.
Obviously this doesn’t excuse the bug, but it’s important to contextualize if we hope to compare relative impact and have frank discussions.
Because why would you be connected to the internet all the time? And how could you even afford those long distance calls?
That one East German guy in Cliff Stoll's The Cuckoo's Egg found a creative answer for both of those.
This is the only story here. Everything else sounds like clueless hyperboles.
...but the fact that file:// schemes can access remote files by appending /net/ followed by a domain name is pretty shocking.
I mean, the entire purpose of "file://" would seem to be to provide access to local/mounted files and only those.
The fact that a Mac engineer thought it would be a great "feature" to allow file:// to access the entire internet is... kinda terrifying. Did that get patched, or was it only TextEdit?