Hacker News Reader

Comment by jaredcwhite | Hacker News Reader

There is no way this isn't going to open up massive security holes. Even if the browser puts up alert after alert, people are just going to randomly click buttons and then all of a sudden wonder why some random web app is deleting all their files and adding malware. And the spec docs aren't exactly reassuring. This is an exact quote! "This API could be used by websites to try to store and/or execute malware on the users system."

View on HN

This is just a variation on <input type=file> as far as read-access is concerned.

For write access, it certainly could be used to store malware on a user's system, but so can "Save As" or clicking a link with HTTP headers that triggers a download. Basically, the "Save As" dialog from browsers have the same issues.

It is not downloading malware that is the issue, it's executing it. So unless you can trick the user into navigating to an existing binary that is normally executing on the system, and have the rights to replace it, executing is not any different that triggering the user to put something in his ~/Download directory and asking him to paste a shell command.

The API doesn't not provide a way to mark something executable, and it should block you from obtaining write access to any file already marked executable just like many mobile OSs don't let you simultaneously mark a page in memory as writable and executable.

The last one looks like a flaw, I couldn't find anything in the spec that says "thou shalt not let the user open a file marked executable for write access", although it does suggest banning access to stuff like C:/Windows, /usr, /Applications, etc.

But what really bothers me is people making uninformed comments. Rather than knee jerk trigger anytime any browser API is changed without fully reading the spec and then actually pointing out any weaknesses, we get the same low signal commentaries.

So again, browsers already allow unaware users to be tricked with bog standard fileupload form elements and Save As dialogs. This just breaks a hardcoded high level UI into smaller reusable parts, and it actually adds more concerns over security than the original 1997 spec for file upload and save.

BTW, for anyone who has children who are doing distance learning during COVID, the vast majority of school districts are using the Web, not native apps on desktop or iOS for the kids to do collaborative learning and submit work.

From what I've seen, they're basically creating APIs like this that set on top of GDrive, DropBox, and File Upload / Server-directed File-Save. So in essence, all this new API is mostly buying you is offline mode.

>So in essence, all this new API is mostly buying you is offline mode.

There's been, for a long time, local storage APIs.

This is filesystem access, which is very different.

Which has policies that can be enabled to block it if necessary

Users click "accept" to make things work.

Filesystem access is going to have nefarious consequences.

That's not how policies work. Schools, organizations and even home users can enable policies to block this feature altogether as well as many others:

https://cloud.google.com/docs/chrome-enterprise/policies/

I'd like to see that ordinary user that is configuring API usage policies on their home network

I think adding a virtual file system to the local storage API's might be fine. One which cannot be mounted easily by non-technical users but has a viewer which allows dragging files into and out of it.

I vaguely recall something like that, a virtual file system using browser local storage. A search yields:

> BrowserFS is an in-browser file system that emulates the Node JS file system API and supports storing and retrieving files from various backends.

https://github.com/jvilk/BrowserFS

It supports storage backends such as: in memory, LocalStorage, IndexDB, HTTP, or the FileSystem API.

It's important not to forget about drive-by DLL injection when making the "execution is the problem" argument.

Lots of executables on Windows link to DLLs that are not protected by the "KnownDLLs" protection. This means that if you can save a malicious DLL next to that executable you can make a perfectly legitimate executable run malicious code.

I haven't read into the API yet to determine how it protects against this, but it's definitely more nuanced than the argument you're making.

> This means that if you can save a malicious DLL next to that executable you can make a perfectly legitimate executable run malicious code.

Some people install browsers onto a USB drive -- or even run a browser directly from their Downloads directory. Such people are easy targets for this type of thing.

If you look at the way most scammers work, it's even simpler than that. They simply phish people by sending them a link and telling them to run it for some reason (it'll fix their computer, it's a required security update, etc) or they tell them to install something like TeamViewer so they can help them eliminate security flaws, and call center scammers then pillage their box.

I'm amazed the the number of people still forwarding chain letters to me in Facebook, so who knows how many people fall for the "pass this Javascript into your browser console" trick.

Running a browser from the downloads directory is unlikely to work correctly on macOS.

It’s funny you say this, because I did exactly this yesterday. I downloaded chromium and forgot I had not yet dragged it to my applications folder and I was running it for a few hours out of my downloads folder.

Google Chrome ships in a DMG, doesn’t it? This means that if it is running out if your downloads folder, it’s not subject to the things that would mess it up because you dragged it there.

I think Chromium does get shipped as a normal executable, it's only Chrome which gets released as DMG.

Installers would be the most common I think.

Ugh, my Win32 security knowledge is non-existent, but this sounds horrible. Seems to me that nothing marked 'from web' and non-executable should be loadable into a memory segment which can be executed, and nothing in the system partition should be overridable like this. This sounds like a flaw in the OS design.

The real irony of the comments on HN that "it's dead on mobile because Apple won't support it", is iOS is one of the few operating systems where this kind of API is trust worth. I would not expect iOS to give Safari privileges to see any files other data files the Safari process itself created by user interaction, or something on say, a Permission-protected directory (e.g. Photos). Ditto for OSX.

If anything, the API really a selling point for OSX/iOS security architecture, in that it can be made safe.

> Seems to me that nothing marked 'from web' and non-executable should be loadable into a memory segment which can be executed,

Welcome to modern macOS and Safari. It’s a good idea, but puts up a block to third part or open source software. For now you can right-click and override (who knows for how long before Apple wants 30% of the price of all your desktop software too). I’d be more okay with the Mac version if you could add custom chains of trust.

> nothing marked 'from web' and non-executable should be loadable into a memory segment

How would you "mark something 'from web'"? This is a file after all.

There are ways to sign files (executable or not) but there is no 'from web' flag as far as I know.

Sure there is:

https://textslashplain.com/2016/04/04/downloads-and-the-mark...

Windows File System is very advanced and has metadata streams.

> How would you "mark something 'from web'"? This is a file after all.

Files can have metadata, and most modern filesystems provide some kind of file attribute facility. On macOS browsers do exactly what described, setting a file attribute on downloaded files. The user will then be warned when trying to execute the file.

You would be incorrect.

File Quarantine on OSX:

> https://support.apple.com/en-us/HT201940

Alternate data stream on Windows:

> https://www.howtogeek.com/70012/what-causes-the-file-downloa...

I wouldn't be surprised if Linux had it but I haven't used desktop Linux in a long time so I don't know what to search for, but generally having browsers annotate their file streams isn't an uncommon thing to support for filesystems & browsers.

OK thanks - so this is a NTFS feature, meaning that if the file is stored on an non-NTFS partition, or sent further that "flag" is cancelled.

A decent number of linux filesystems do support extended attributes, which is how I assume you'd do this (actually, looking at https://en.wikipedia.org/wiki/Extended_file_attributes a lot of OSs support xattrs), but I'm not aware of any browsers using them to mark downloads.

I'm not aware of any browsers that don't mark files downloaded from the web as such.

The article says there is a possibility to grant access to a directory. For a non technical user who clicks “ok, whatever” on 200 cookies consent and newsletter nagging popups a day, there is a high probability they will click ok without reading it. This is absolutely not like the file input. Once you have access to a folder, you can write a decent cryptolocker.

> It is not downloading malware that is the issue, it's executing it.

That line is very thin. Local DLLs, application configs setting path to executables, even desktop.ini (https://threat.tevora.com/usb-drives-desktop-ini-and-ntlm-ha...) and that's before we get into NTFS alternative streams and other really out there ideas.

If you can choose which path you download to, the user has lost. Even if they never actively execute the file.

Same on *nix. If you can add something to bashrc, or drop a new file in desktop autostart, who cares about the executable bit.

And sometimes you can point out bad ideas without reading the spec. WebUSB was that kind of bad idea even before someone figured out exactly how they can read one time codes from security dongles that way. (https://www.yubico.com/support/security-advisories/ysa-2018-...)

I just went to the documentation there: https://wicg.github.io/native-file-system/

I get that from your comment you agree that this is enough to mitigate the risk they themselves bring up:

>Another risk factor is that of ransomware attacks. The limitations described above regarding blocking access to certain sensitive directories helps limit the damage such an attack can do. Additionally user agents can grant write access to files at whatever granularity they deem appropriate.

I worked on this. The quote is true, in all honesty. Same as downloading and running applications from the web.

We do our best to make sure the scenario listed doesn't happen. For instance, on Windows, after a writer is closed, we apply the Mark-of-the-Web, apply SafeBrowsing checks and finally call a system API which may trigger an anti-virus check.

On the Mac, we apply the equivalent of Mark-of-the-Web. You may have noticed that when you open the file, sometimes it asks you to ensure the provenance of the file?

Basically, it's a similar procedure as for file downloads.

Edit:

I forgot to say that "sensitive" directories are not allowed. Think C:\Windows, etc.

https://source.chromium.org/chromium/chromium/src/+/master:c...

I'm sure you worked hard and thought a lot about the security of this, but you have to be really arrogant to think that this will be fine because you thought about everything. I'm pretty sure this will open up a lot more possibilities for malware, viruses, harmful web pages than the convenience it will provide.

The alternatives arent that people just dont use it, the alternative is are that people download some random executable that has much larger security vector, ie some electron app that has unlimited file system access.

I have no idea why you were down-voted here. Non-technical people are downloading executable files on their systems by the millions every day.

People can argue about how scary the warning messages should be on this new API, but they can't argue that this is not the way forward to a more secure world.

With this new API in place we'll be one step closer to the goal of having all consumer applications running inside a progressively-permissioned sandbox. It's a dream come true and will allow the culture and OSes to even more strongly stigmatise the opening of executables which immediately gain full system access - something that's completely absurd, but was a necessary evil.

Yeah, they sure thought about everything thats why ad networks abuse the hell out of every API they implemented to fingerprint people, like AudioContext Api, battery API and what not.

Which paths are "sensitive" depends on which other programs the user has installed. Would Chrome recognize ~/.mozilla as a sensitive path? How about adding arbitrary content to ~/.ssh/authorized_keys?

On Windows any directory where users start programs is a ‘sensitive’ directory. With of course the prime case the ‘downloads’ directory.

Are you aware of this security issue? There are also similar issues with DLLs on Windows.

https://glyph.twistedmatrix.com/2020/08/never-run-python-in-...

It won't work on iPhones, which means no one will use it, I hope.

Push notifications don't work on iPhones and yet a lot of sites use them, some in a spammy way but some I actually allowed on my phone and are quite useful.

In plenty of countries iPhone has 0% market share, the local companies don't care about iPhone support.

Name one.

iOS global market share is around 22%, plenty of countries to chose from.

https://leftronic.com/android-vs-ios-market-share/

Here a device atlas (2019) with plenty of countries for you to play with,

https://deviceatlas.com/sites/deviceatlas.com/files/images/m...

In India iOS has 2-3% market share.

Seems like it can be disabled in flags for now, which I just went in and did. That flag is bound to disappear at some point though… might become necessary to wrap browsers in an isolating sandbox or VM just to be sure they can't touch things they're not supposed to.

chrome://flags/#native-file-system-api

I already had it disabled before LOL

It has a policy as well and will always allow you to disable it. No need for hyperbole.

"Will always" is a phrase Google does not know the meaning of.

For filesystem access they are beholden to their enterprise users as well and Chromium still has a lot of open source developers that aren't simply looking out for Google's best interests. If they became overly hostile, then I'm sure we'd see a fork at some point. I'm not saying they are perfect, but a lot of Chromium hate is unfounded and exaggerated.

AMP waves “hello”

AMP isn't specific to Chromium

> might become necessary to wrap browsers in an isolating sandbox or VM just to be sure they can't touch things they're not supposed to.

Honestly I view this as a good idea regardless (it also helps contain exploits, in addition to official APIs). On Linux firejail is amazing for this (but also consider bubblewrap and others), and AFAIK sandboxie is a good choice on NT. No idea what sandboxing options are on Darwin - looks like it has something built in?

Do we need to just create a dummy proof OS for people that are oblivious and click yes to everything? Otherwise, why not give people choice? I mean you could create a pop up asking people for their passwords today on any browser, so how is adding a feature that requires permission any different?

Not dummy proof, just normal human proof. It’s very easy to condition someone to click a yes button when it stands between them and whatever task they’re actually trying to accomplish.

You don't always have to be a dummy to act stupid: https://en.m.wikipedia.org/wiki/Dark_pattern

> why not give people choice ?

https://news.ycombinator.com/item?id=24403392

https://news.ycombinator.com/item?id=20044430

Reply on news.ycombinator.com