6 ms·

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 sys

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.

cromwellian 6y ago
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.
- snvzz 6y ago
  >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.
  - chromedev 6y ago
    Which has policies that can be enabled to block it if necessary
    - snvzz 6y ago
      Users click "accept" to make things work. Filesystem access is going to have nefarious consequences.
      - chromedev 6y ago
        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/ https://cloud.google.com/docs/chrome-enterprise/policies/
        emteycz 6y ago
        I'd like to see that ordinary user that is configuring API usage policies on their home network
  - im3w1l 6y ago
    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.
    - lioeters 6y ago
      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 https://github.com/jvilk/BrowserFS It supports storage backends such as: in memory, LocalStorage, IndexDB, HTTP, or the FileSystem API.
armada651 6y ago
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.
- inetknght 6y ago
  > 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.
  - cromwellian 6y ago
    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.
  - saagarjha 6y ago
    Running a browser from the downloads directory is unlikely to work correctly on macOS.
    - imwillofficial 6y ago
      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.
cm2187 6y ago
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.
viraptor 6y ago
> 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-hashes/ 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-02/ https://www.yubico.com/support/security-advisories/ysa-2018-...)
dwild 6y ago
I just went to the documentation there: https://wicg.github.io/native-file-system/ 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.

cromwellian 6y ago

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.

snvzz 6y ago
>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.
- chromedev 6y ago
  Which has policies that can be enabled to block it if necessary
  - snvzz 6y ago
    Users click "accept" to make things work. Filesystem access is going to have nefarious consequences.
    - chromedev 6y ago
      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/ https://cloud.google.com/docs/chrome-enterprise/policies/
      - emteycz 6y ago
        I'd like to see that ordinary user that is configuring API usage policies on their home network
- im3w1l 6y ago
  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.
  - lioeters 6y ago
    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 https://github.com/jvilk/BrowserFS It supports storage backends such as: in memory, LocalStorage, IndexDB, HTTP, or the FileSystem API.

armada651 6y ago

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.

inetknght 6y ago
> 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.
- cromwellian 6y ago
  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.
- saagarjha 6y ago
  Running a browser from the downloads directory is unlikely to work correctly on macOS.
  - imwillofficial 6y ago
    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.

cm2187 6y ago

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.

viraptor 6y ago

> 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-hashes/ 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-02/ https://www.yubico.com/support/security-advisories/ysa-2018-...)

dwild 6y ago

I just went to the documentation there: https://wicg.github.io/native-file-system/ 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.