5 ms·

"Using a private internal storage directory rather than external storage would help avoid this vulnerability: https://developer.android.com/guide/topics/data/da

"Using a private internal storage directory rather than external storage would help avoid this vulnerability: https://developer.android.com/guide/topics/data/data-storage#filesInternal" https://developer.android.com/guide/topics/data/data-storage... The system offers it and they didn't use it. "Why should something like the Fortnite installer have to make any effort to ensure that other apps aren't tampering with what it downloads?" Because it's running with exceptionally dangerous permissions that Google does its level best to prevent users from granting to 3rd party apps in the first place.

wtallis 8y ago
> The system offers it and they didn't use it. The bug report doesn't seem to be clear on whether the Fortnite installer is downloading the game to a public external storage directory or a private external storage directory. But the existence of the latter API means you can't just say "they should have used internal storage". If the Fortnite installer used the getExternalStoragePublicDirectory() API, then this is a really embarrasing bug for Epic. Otherwise, it's an Android problem, not an Epic problem.
- UncleMeat 8y ago
  Yes they literally used the external storage.
  - wtallis 8y ago
    > Yes they literally used the external storage. That doesn't answer the key question. There are APIs to get public or private directories on external storage. Unless Epic used the public version, then they had no reason to expect other apps to be able to tamper with their working files. You have to dig into the fine print of the API docs to find a clear statement that private directories on external storage don't have any security, which is a surprising difference from how the internal storage works. Google calls the directories private, but they're really not. There's no obvious reason why they couldn't be secured against modification by non-root apps.
    - dmitrygr 8y ago
      Digging through API docs is literally what developers get paid for.
      - wtallis 8y ago
        Searching for potential hidden footguns is not a good use of application developer time; they're paid primarily to create new functionality. This is simply a bad API/platform design aspect that the docs don't do enough to warn about.
        UncleMeat 8y ago
        Potentially hidden footguns? The public/private storage mechanism has been the primary way of protecting files in Android literally since release. This is like saying it is Android's fault that you can put exported=true on a ContentProvider and be surprised when other apps access the underlying tables.
    - makomk 8y ago
      If by "dig into the fine print of the API docs" you mean "read the summary of the different data storage options available, or alternatively read the documentation for the API function you're using", then sure. https://developer.android.com/guide/topics/data/data-storage#filesInternal%22 https://developer.android.com/guide/topics/data/data-storage... The different APIs for accessing external storage are mainly just there for filesystem tidyness and are documented as such. getExternalStoragePublicDirectory puts media files in locations where other apps and the user can find them easily, whereas the application-specific directory is deleted when the app is uninstalled. There's no real security difference and the documentation makes this quite clear. I think the API for application-specific directories in external storage was probably only added because applications were already using it for their internal files in ad-hoc ways that caused a lot of user visible clutter.
      - wtallis 8y ago
        > There's no real security difference and the documentation makes this quite clear. Only once you've dug deep enough. The page you linked to doesn't mention security at all. It does say: "Except for some types of files on external storage, all these options are intended for app-private data—the data is not naturally accessible to other apps." Elsewhere, it mentions that files on external storage are world-readable, but that's not a problem here. The fact that they're also world-writable is left unsaid. Going another layer deeper into the docs at https://developer.android.com/training/data-storage/files https://developer.android.com/training/data-storage/files we get this: "Private files: Files that rightfully belong to your app and will be deleted when the user uninstalls your app. Although these files are technically accessible by the user and other apps because they are on the external storage, they don't provide value to the user outside of your app." That doesn't clearly warn that "private" files on external storage will be modifiable by other apps while you're still trying to use them. Only by going all the way down to the documentation for getExternalFilesDirs() itself do you get a reasonably sufficient and clear warning: "There is no security enforced with these files. For example, any application holding Manifest.permission.WRITE_EXTERNAL_STORAGE can write to these files." For someone coming to Android programming with the knowledge that it's Linux-based with a fairly strict permissions model, and with so many mentions of "private" storage in the high-level docs, it's a surprise to discover that there are no file permissions enforced on "external" storage.
- deleted 8y ago
  [deleted]

wtallis 8y ago

> The system offers it and they didn't use it. The bug report doesn't seem to be clear on whether the Fortnite installer is downloading the game to a public external storage directory or a private external storage directory. But the existence of the latter API means you can't just say "they should have used internal storage". If the Fortnite installer used the getExternalStoragePublicDirectory() API, then this is a really embarrasing bug for Epic. Otherwise, it's an Android problem, not an Epic problem.

UncleMeat 8y ago
Yes they literally used the external storage.
- wtallis 8y ago
  > Yes they literally used the external storage. That doesn't answer the key question. There are APIs to get public or private directories on external storage. Unless Epic used the public version, then they had no reason to expect other apps to be able to tamper with their working files. You have to dig into the fine print of the API docs to find a clear statement that private directories on external storage don't have any security, which is a surprising difference from how the internal storage works. Google calls the directories private, but they're really not. There's no obvious reason why they couldn't be secured against modification by non-root apps.
  - dmitrygr 8y ago
    Digging through API docs is literally what developers get paid for.
    - wtallis 8y ago
      Searching for potential hidden footguns is not a good use of application developer time; they're paid primarily to create new functionality. This is simply a bad API/platform design aspect that the docs don't do enough to warn about.
      - UncleMeat 8y ago
        Potentially hidden footguns? The public/private storage mechanism has been the primary way of protecting files in Android literally since release. This is like saying it is Android's fault that you can put exported=true on a ContentProvider and be surprised when other apps access the underlying tables.
  - makomk 8y ago
    If by "dig into the fine print of the API docs" you mean "read the summary of the different data storage options available, or alternatively read the documentation for the API function you're using", then sure. https://developer.android.com/guide/topics/data/data-storage#filesInternal%22 https://developer.android.com/guide/topics/data/data-storage... The different APIs for accessing external storage are mainly just there for filesystem tidyness and are documented as such. getExternalStoragePublicDirectory puts media files in locations where other apps and the user can find them easily, whereas the application-specific directory is deleted when the app is uninstalled. There's no real security difference and the documentation makes this quite clear. I think the API for application-specific directories in external storage was probably only added because applications were already using it for their internal files in ad-hoc ways that caused a lot of user visible clutter.
    - wtallis 8y ago
      > There's no real security difference and the documentation makes this quite clear. Only once you've dug deep enough. The page you linked to doesn't mention security at all. It does say: "Except for some types of files on external storage, all these options are intended for app-private data—the data is not naturally accessible to other apps." Elsewhere, it mentions that files on external storage are world-readable, but that's not a problem here. The fact that they're also world-writable is left unsaid. Going another layer deeper into the docs at https://developer.android.com/training/data-storage/files https://developer.android.com/training/data-storage/files we get this: "Private files: Files that rightfully belong to your app and will be deleted when the user uninstalls your app. Although these files are technically accessible by the user and other apps because they are on the external storage, they don't provide value to the user outside of your app." That doesn't clearly warn that "private" files on external storage will be modifiable by other apps while you're still trying to use them. Only by going all the way down to the documentation for getExternalFilesDirs() itself do you get a reasonably sufficient and clear warning: "There is no security enforced with these files. For example, any application holding Manifest.permission.WRITE_EXTERNAL_STORAGE can write to these files." For someone coming to Android programming with the knowledge that it's Linux-based with a fairly strict permissions model, and with so many mentions of "private" storage in the high-level docs, it's a surprise to discover that there are no file permissions enforced on "external" storage.
deleted 8y ago
[deleted]