Hacker News Reader

Comment by crazygringo | Hacker News Reader

Oh, man. The idea that TextEdit automatically parsed .txt files as HTML if they started with a certain file signature is problematic...

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

View on HN

> ...but the fact that file:// schemes can access remote files by appending /net/ followed by a domain name is pretty shocking.

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.

> 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).

Although it was disabled in Debian bash 2.04-5 on 2000-06-05, it was re-enabled in bash 4.0-5 on 2009-09-13 and is currently enabled. See https://metadata.ftp-master.debian.org/changelogs/main/b/bas...

On two different Debian 10 boxes bash seems to have it enabled:

  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
  $

For anyone wondering, it is enabled by default on Ubuntu too. I wonder what made someone think that this was a good idea?

If you follow the everything is a file philosophy it seems quite natural does it not?

Except permissions aren't granular enough / are too confusing, it's a giant footgun with the current Linux architecture, which doesn't have all the nice things Plan9 does

I didn't say that the everything is a file philosophy is necessarily correct and well implemented on Linux. Merely that if you where to continue along this direction it would seem like a logical next step. I don't think I would use this for anything but for shell scripts at best. However especially if you are a plan 9 fanatic then it would seem like quite a good idea which is what the original question was.

I mean, unless you're host is extremely locked down you'll probably also have telnet,netcat, etc installed, so no great difference.

I'm no specialist but I'm inclined to disagree, for me it's the difference between the ability to run an arbitrary binary and the ability to read/write an arbitrary filepath

They are imaginary paths in the bash executable. They aren't usable outside it. Thus the netcat analogy.

Anything you can do in telnet or netcat can also be done in python, perl, ruby. One of those is likely installed, most probably python.

And if you think about if all applications where using files for communication blocking one program from the internet would be as simple as a chmod.

SMB is more understandable though, since you have more trust for things on your local network, and an attacker usually won't have control over those resources. And it's a fairly common and reasonable expectation in a business environment that network drives appear as part of the filesystem.

Whereas a domain name over the open internet is an entirely different story.

Its been a while since i've done windows stuff, but i thought you could use IP addresses in addition to netbios names for smb - \\1.2.3.4\share\file

You can use \\domain.name\share\ as well.

Actually if I am not mistaken it is after they want to fight the browser war they break the barrier between the file system and internet system. It is not in the early version of windows or IE. the integration is one of the major mistakes Microsoft made. And surprise apple fall for it as well.

Can’t trust these two or ,,, who can we trust for network security.

Most likely nobody decided to have file:// access the network. Most likely, someone decided to make file:// the scheme for accessing files, and someone else decided to mount the network as a file.

My memory is hazy, but I think this was a “feature” of Plan9

It's not specific to the file:// URI scheme; /net is an actual filesystem path that works with anything that accesses paths. Or used to work, anyway; it was recently changed to be disabled by default.

“Everything’s a file!”

> In Unix everything is a file. Files are files, folders are files, disks are files, your keyboard is a file, your mouth is a file, the air is a file, you can't breathe, your file lungs fill with files and you try to scream but only files come out oh god Dennis how could you do this

-- https://twitter.com/TartanLlama/status/1375045731644538882

perhaps this is the worst possible abstraction to be protected by a security framework.

How is that? Per-process namespaces in Plan 9 seem like a good idea for isolation. "Everything is a file," but what is and isn't accessible can be managed on a per-process level.

In POSIX we only generally get a user/group level of granularity which seems to practically mean that only daemons are completely isolated.

Per process won’t be good enough in a different app that does legitimately need `/net`, just not when displaying file:/// links inside HTML pages.

I disagree. Use a second process that has a limited namespace where you've mounted only the local files you want an HTML document to be able to refer to and an IPC socket marked for exclusive use. The first process resolves file links and reads file contents via IPC to the second process.

I can see a way this would be useful to use the same abstraction to limit app/user web access to a single domain.

For instance the dropbox binary can only access "/home/dropbox" and "/net/dropbox.com" if this was more well-known/used.

This can be done with a proper capability system.

IMO not so much. Just assume all files are malicious unless accompanied by metadata saying otherwise. That is pretty much the status quo already.

Except we have some grandfathered file types that are implicitly trusted.

In the article, the remote file's contents were not malicious, but merely trying to access it was. That would require a very different security posture to "assume all files are malicious".

> the remote file's contents were not malicious

until ... one day ... they are!

The remote file is only one of two files in the story.

And what about malicious metadata?

I don't think "everything is a file" is necessarily bad. What's worse is "every application I run has access to every resource that the OS gives my user access to".

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.

Modern operating systems can; there is quite granular control.

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 believe this is how Qubes OS is supposed to operate.

On the contrary, it's very good design.

> perhaps this is the worst possible abstraction to be protected by a security framework.

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.

> “Everything’s a file!”

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.

Several ways. In Unix files are streams of bytes. In HTTP resources are complex entities with MIME types, multiple representations, encodings, etc. HTTP URL structure supports parameters and there is a method for providing data and obtaining a result back, a sort of RPC.

On the other side Unix has users and permissions, HTTP does not and you have to build your own.

Looking in /etc/auto_master, which is the configuration for Autofs, the /net mount point is commented out by default. I do not know when (or if) it was ever turned on by default.

Whether or not a default configuration is vulnerable is a pretty typical component of accessing a vulnerability’s severity.

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.

The default configuration was, in fact, vulnerable at the time. Having it be commented out by default is new.

The vulnerability: https://www.fcvl.net/vulnerabilities/macosx-gatekeeper-bypas...

I'm stilling running Mojave (10.14.x) and it is uncommented. The file dates to 2014 so I suspect it was set up with the original OS that came with this machine.

/net is really meant for things like nfs.

I think it carries over from NeXTstep, iirc.

It feels like a choice when "net" meant "my campus network", not "the internet."

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.

A file can be accessed locally, on a private network, or over the internet. The fact that /net/ exists is redundant to http file download... so there's an argument there, but to access a local network file through http requires a webserver which may not be desired. So, having file /net/ solves that problem but of course could work the same way on an internet network so... we're kind of screwed really.

holy batman

> I mean, the entire purpose of "file://" would seem to be to provide access to local/mounted files and only those.

This is the only story here. Everything else sounds like clueless hyperboles.

The extension is meaningless outside of Windows...

File extensions are routinely used by all sorts of software, at least as hints if nothing else. For example, gcc will handle files named .c differently from files named .cpp, and will not even work with static libraries unless they are named .a.

It doesn't sound like that from the article:

>the default text reader on OSX, TextEdit is used to open files with TXT extension by default.

>Gatekeeper doesn’t quarantine TXT files

Far from it. Even Mac OS stopped using type and creator codes in favour of file extensions, 11 years ago (with snow leopard).

Reply on news.ycombinator.com