Coincidentally, it was also the era with 37 ie toolbars and constantly having to clean out the infected family pc every week only to find it infected the next day. Definitely the fun times.
I would have totally taken away admin and maxed UAC. "Why can't I install this Ralphy?" "Because it's a virus!"
Personally, I like the choice of app stores and installing anything or installing a third party app store.
There are three main reasons for this, don't underestimate any of them: generally more technically literate to make the choice to use macOS, unix and DE design, and small target for malware makers.
> We got along for decades without centralized app stores taking a 30% cut.
Those decades were largely spent with a physical retail distribution chain taking an even bigger share of most consumer purchases, and being just as essential to reaching most consumers.
There wasn't much gap between online distribution becoming significant and app stores emerging.
It wasn't clear before that instead of having users download and install an apk, users were downloading and installing an apk that downloads and install an apk.
That seems a little bit insane, combined with Androids kind of terrible inability to do useful things like have a place for large storage (SD card), that isn't readible and mutable by all apps.
Telling people to just Google “download Fortnite apk“ is a fantastic way for people to get malware.
What’s surprising about this story is tha what’s surprising about this story isnt that people are ending up with security issues, it’s that they’re ending up with security issues from the OFFICIAL download.
Frankly, I don't think it will. The typical user will never hear about this, and those that do will forget about it in a week. They just want to play Fortnite, and they'll do whatever to get there.
Google should allow users to install trusted keys and then this wouldn't have happened. Users could install apps signed only by the Epic store.
Instead, through Google Play Services deals with manufacturers, they prevent this from happening at the system level, don't they, other than for phone vendor stores?
You can only blanket allow third party apps, which you have to toggle on and off every time you do a third party update, and not just add a specific store's key. At least that's how Amazon Instant Video seems to be.
That isn't how Android works. An app with permission to install things can do so. Play store by default has this permission. It is VERY careful to avoid substitution of downloaded data. For a good reason. Users granted same permission to the Epic installer. Clearly prematurely.
Why should something like the Fortnite installer have to make any effort to ensure that other apps aren't tampering with what it downloads? This definitely sounds like poor platform design more than a flaw in the installer.
"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.
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.
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.
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.
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.
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...
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.
> 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 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.
I totally reject your interpretation. If you're writing a crappy app with limited permissions then you get a pass. You don't get to complain about footguns if you are asking people to give you exceptionally dangerous permissions.
I don't think this was even hidden or obfuscated, doc-wise (exhibit A: doc exists), but even if it was the onus is on Fortnite.
"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."
If you are not an absolute expert on Android across multiple devices and api versions, then you have no damn business releasing something of this nature.
You bring up Linux. It is not a flaw that drivers run in a privileged mode. If you make a device driver and don't understand how memory is allocated and cleared or not cleared, then you have no business writing one because you're going to let people root your customer's boxes eventually.
Sorry, "totally reject" is a bit stronger than I meant (and I'm past the edit window). I just feel strongly about developer obligation & responsibility for security code and infrastructure being commensurate with the risk they ask the users of the software to take.
But they did use the public version. There is no other recommended way of getting access to the public filesystem. They could have just made a file path to sdcard:// but this is not portable across all devices.
The public filesystem is, by design, sharable between apps. This is so you can have stuff like a music playing app or a picture viewing app that interacts with files created by other apps.
Do you have a source for that? Because that detail is definitely not in the Google bug tracker. I'm still not sure you've actually understood that there's a difference between getExternalStoragePublicDirectory() and getExternalFilesDirs().
I don't know how up to date that is, but it says once unknown sources are turned back off, the app using REQUEST_INSTALL_PACKAGES can no longer install unsigned packages. My point was it should be possible to add a key for a store, so that unknown sources doesn't have to be turned back on after installing it.
The explanation in the bug tracker is clearer than the explanation in the article:
"Any app with the WRITE_EXTERNAL_STORAGE permission can substitute the APK immediately after the download is completed and the fingerprint is verified. This is easily done using a FileObserver. The Fortnite Installer will proceed to install the substituted (fake) APK.
If the fake APK has a targetSdkVersion of 22 or lower, it will be granted all permissions it requests at install-time. This vulnerability allows an app on the device to hijack the Fortnite Installer to instead install a fake APK with any permissions that would normally require user disclosure.
"
Why is this not considered a bug in Android? Hasn't this just shown how any app can add a feature to download other apps? Why wouldn't Facebook add that feature to the Facebook app so they can forcefully install any other app they want?
Facebook wouldn’t do that because they don’t need to use illegal/shady means to install their apps, users happily download and install them.
This isn’t a bug “in android” since it can only happen when the user enables permissions to install third party app stores - the Fortnite installer is essentially an App Store that could be tricked to installing any APK rather than the one it means to.
In apt, you can specify trusted keys for repositories and the packages downloaded are verified. Most Debian-based systems ship with standard repositories, but it's easy to add others.
Instead of asking "Allow Epic Installer to install apps", have the option to ask "Allow Epic Installer to install apps by the same publisher", and have to OS do the signature check. This would cover the vast majority of app stores, especially if multiple signatures are allowed.
This is fair, but more app stores also mean more points of failure. We learned quite a bit from what happens in cases like this from root ca's. We had to have certificate transparency, browsers distrusting ca's from vulnerable ca's and so on.
So i would argue this is not as simple as that.
I dont necessarily trust fortnite keeping their keys secure, for example.
The only difficult part is the user getting f-droid on their device to begin with. If google play implemented the functionality provided by F-droid, they wouldn't need to.
Manufacturers should just put F-droid on new devices as standard.
> That is the problem. There is no way to securely allow 3rd party downloads. Microsoft learnt that the hard way.
There is a huge difference between no one has vetted this program and someone other than the device manufacturer has vetted this program. In a contest of "trustworthy not to contain malware" the Debian package manager beats Google Play, and you don't need approval from Dell or Microsoft to use it.
Google Play's TOS generally prohibit apps that install APK. This is why apps like F-droid, Amazon(full-featured variant), getChromium, Amaze, etc. aren't available on Google Play.
> Google's security analysis efforts are appreciated and benefit the Android platform, however a company as powerful as Google should practice more responsible disclosure timing than this, and not endanger users in the course of its counter-PR efforts against Epic's distribution of Fortnite outside of Google Play.
And Google expects researchers to disclose bugs on their platform to them before disclosing to public.
Not if they are creating such a big hole in the company's revenue(30%, source : https://arstechnica.com/gaming/2018/08/fortnite-on-android-m...) without bringing in something substantial. Epic already has a user base who would go to extra length by downloading the game's installer by visiting their website. So, it totally makes sense for Epic to bypass the playstore.
From the article linked above:
> Avoiding the 30 percent "store tax" is a part of Epic's motivation. It's a high cost in a world where game developers' 70 percent must cover all the cost of developing, operating, and supporting their games. And it's disproportionate to the cost of the services these stores perform, such as payment processing, download bandwidth, and customer service. We're intimately familiar with these costs from our experience operating Fortnite as a direct-to-customer service on PC and Mac.
I like when "following standard practice, literally listed in the bug report and used 100's of times" is suddenly "counter-pr efforts"
type: vulnerability is new, but if you search the public bug tracker for the phrase "This bug is subject to a 90-day disclosure deadline", you can see it all
It looks like they have been pretty darn consistent about unrestricting once the patch is available. Usually faster than 7 days!
They have also consistently held people to the 90 day requirement, and the 14 day grace extension they offer This is true even when the reporter is a googler or it affects only google software.
This literally took me 5 minutes to look at and analyze.
Instead of bothering to even look, epic decided it'd be better to issue a press release (as part of their pr efforts, ironically enough).
If they want to complain (like others have!) and debate what the policy should be, that is one thing.
However, the complaint that Google has treated them differently is clearly false.
If they want to argue otherwise, the data is all right there for them to use.
> Google's security team first disclosed the vulnerability privately to Epic Games on August 15, and has since released the information publicly following confirmation from Epic that the vulnerability was patched
Epic Games is making a disappointing choice. The app store taxes are definitely steep, and maybe it is time to talk about how fair this is. But, Epic Games develops probably the most popular video game in the world, and they are telling users to install their app in a way that could only be described as unhygienic, and will condition users to think that it is OK.
Meanwhile, they have accused Google's disclosure, which is completely in line with their existing disclosure behavior that they stubbornly enforce for everybody, as being a PR move, intended to harm Epic Games for their decision to launch outside Play Store. It's clear that Android has a bad reputation for security issues and insane to think that Google would not want to make sure that the launch of a super popular video game on their platform doesn't turn into a security disaster.
I generally respect Epic Games, but I don't understand what seems to be pretty greedy on their part. If they wanted to start a discussion about the fairness of app store taxes, I don't think this will accomplish that personally.
Meanwhile, Apple's definitely looking pretty smart. They're probably making good money off of Fortnite and won't suffer any of the bad UX or security issues Android users will be exposed to.
As a Developer I have massive respect for Epic Games here. And anyone thats developed apps for more than 5 minutes for the App store knows that the rules are completely arbitrary based on how big you are. The review team are much less harsh on the large name brand apps with legal teams and massive audiences while smaller devs are given an entirely different more hardcore set of rules. This is bad for innovation, bad for smaller businesses and bad for users.
App store rules is a whole different can of worms from the app store tax. I don't claim to agree with the state of either, but all the same the partially overlapping needs of the three parties (user, developer, platform) are difficult to balance and align and I don't believe in any extreme here.
That would be fantastic but I won't hold my breath. Improvements could be made but at the scale they operate at it's probably not ever going to be great.
Fornite game makers (and a handful) of others have been figting against 'Googles Play Store Tax' and suddenly Google announces this. It’s subtly saying, downloading anything outside of Play Store is dangerous for you.
As indicated in the article this vulnerability has as much to do about ... the way Android's permissions model works...
So, a "feature" in the installer allows an already installed malicious app to install even more malicious apps.
That new malicious app then gets to somehow have more permissions than the original malicious app or the installer.
Guys, that's an Android bug. This is exactly the kind of thing that needs to be fixed at an OS level, you can't be relying on the competence of arbitrary developers to maintain the security of the system.
Of course it's an opportunity for Google to use their own broken security model as an argument on why apps should only come from their own "curated" channels (which presumably also host the malware exploiting this). It just so happens to be their source of revenue...
There are two ways to fix this. One is to not permit dynamic code loading or app installs off the Play Store. This is Apple territory and pisses people the hell off. The other is to not have any world writable filesystem at all. I guess you could do this, but this messes with features surrounding music and pictures that you do want to share between apps.
Epic literally could have used the private filesystem that is right there just for the purpose of having files that are protected from other apps.
Yep. If I might add a footnote for HN reader convenience: Epic actually fixed it by following the second approach you mentioned.
According to Google issue tracker: "This patch changes the default APK storage directory from external to internal storage, which should prevent MITD attacks during the install flow."
No, this is a permissions problem. Reading and writing to an application directory does not cause any issues until some code in that directory starts running with privileges it shouldn't have.
It should not be possible for an application that happens to install other applications to bypass the user for specific permissions. The user must be asked explicitly.
This has nothing to do with being able to "sideload" apps or not. Sideloading apps is actually possible on iOS, it's just such an effort (getting a developer account) that it's rarely done in practice.
This narrative does not make sense. Any installer has privileges on a system, including verifying hashes or keys so you shouldn't just run an unknown software. Installing apps only from an app store is a walled garden and not having the ability to install apps is not a consumer want.
The only people who would advocate this are Google since they gain financially from the model and those who use 'security' to promote walled gardens and moats.
Most technical people don't approve of lockdowns and loss of freedom. There is a balance here. If installing apps from the web is a problem then 90 percent of current software is 'insecure'.
76 comments
[ 4.9 ms ] story [ 145 ms ] threadThose decades were largely spent with a physical retail distribution chain taking an even bigger share of most consumer purchases, and being just as essential to reaching most consumers.
There wasn't much gap between online distribution becoming significant and app stores emerging.
That seems a little bit insane, combined with Androids kind of terrible inability to do useful things like have a place for large storage (SD card), that isn't readible and mutable by all apps.
Seems like a non issue to me, and one easily prevented if side loading wasn't an after thought.
What’s surprising about this story is tha what’s surprising about this story isnt that people are ending up with security issues, it’s that they’re ending up with security issues from the OFFICIAL download.
(The quora one is spam that leads to adware apk site on .in domain)
Instead, through Google Play Services deals with manufacturers, they prevent this from happening at the system level, don't they, other than for phone vendor stores?
You can only blanket allow third party apps, which you have to toggle on and off every time you do a third party update, and not just add a specific store's key. At least that's how Amazon Instant Video seems to be.
Why the downvotes? It is true.
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.
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.
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.
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.
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 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.
I don't think this was even hidden or obfuscated, doc-wise (exhibit A: doc exists), but even if it was the onus is on Fortnite.
"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."
If you are not an absolute expert on Android across multiple devices and api versions, then you have no damn business releasing something of this nature.
You bring up Linux. It is not a flaw that drivers run in a privileged mode. If you make a device driver and don't understand how memory is allocated and cleared or not cleared, then you have no business writing one because you're going to let people root your customer's boxes eventually.
The public filesystem is, by design, sharable between apps. This is so you can have stuff like a music playing app or a picture viewing app that interacts with files created by other apps.
Do you have a source for that? Because that detail is definitely not in the Google bug tracker. I'm still not sure you've actually understood that there's a difference between getExternalStoragePublicDirectory() and getExternalFilesDirs().
I don't know how up to date that is, but it says once unknown sources are turned back off, the app using REQUEST_INSTALL_PACKAGES can no longer install unsigned packages. My point was it should be possible to add a key for a store, so that unknown sources doesn't have to be turned back on after installing it.
But then this seems to say you can:
https://developer.android.com/reference/android/content/Inte...
"Any app with the WRITE_EXTERNAL_STORAGE permission can substitute the APK immediately after the download is completed and the fingerprint is verified. This is easily done using a FileObserver. The Fortnite Installer will proceed to install the substituted (fake) APK.
If the fake APK has a targetSdkVersion of 22 or lower, it will be granted all permissions it requests at install-time. This vulnerability allows an app on the device to hijack the Fortnite Installer to instead install a fake APK with any permissions that would normally require user disclosure. "
CheckPoint's diagram of a Man in the Disk attack is also helpful: https://blog.checkpoint.com/wp-content/uploads/2018/08/Man-i...
This isn’t a bug “in android” since it can only happen when the user enables permissions to install third party app stores - the Fortnite installer is essentially an App Store that could be tricked to installing any APK rather than the one it means to.
The "bug" is that it is extremely difficult for users to install 3rd party apps securely.
If it was easier for developers to securely offer 3rd party downloads, then stuff like this wouldn't happen.
So i would argue this is not as simple as that.
I dont necessarily trust fortnite keeping their keys secure, for example.
Example here: https://f-droid.monerujo.io/
The only difficult part is the user getting f-droid on their device to begin with. If google play implemented the functionality provided by F-droid, they wouldn't need to.
Manufacturers should just put F-droid on new devices as standard.
There is a huge difference between no one has vetted this program and someone other than the device manufacturer has vetted this program. In a contest of "trustworthy not to contain malware" the Debian package manager beats Google Play, and you don't need approval from Dell or Microsoft to use it.
> Google's security analysis efforts are appreciated and benefit the Android platform, however a company as powerful as Google should practice more responsible disclosure timing than this, and not endanger users in the course of its counter-PR efforts against Epic's distribution of Fortnite outside of Google Play.
And Google expects researchers to disclose bugs on their platform to them before disclosing to public.
From the article linked above:
> Avoiding the 30 percent "store tax" is a part of Epic's motivation. It's a high cost in a world where game developers' 70 percent must cover all the cost of developing, operating, and supporting their games. And it's disproportionate to the cost of the services these stores perform, such as payment processing, download bandwidth, and customer service. We're intimately familiar with these costs from our experience operating Fortnite as a direct-to-customer service on PC and Mac.
type: vulnerability is new, but if you search the public bug tracker for the phrase "This bug is subject to a 90-day disclosure deadline", you can see it all
It looks like they have been pretty darn consistent about unrestricting once the patch is available. Usually faster than 7 days! They have also consistently held people to the 90 day requirement, and the 14 day grace extension they offer This is true even when the reporter is a googler or it affects only google software.
This literally took me 5 minutes to look at and analyze.
Instead of bothering to even look, epic decided it'd be better to issue a press release (as part of their pr efforts, ironically enough).
If they want to complain (like others have!) and debate what the policy should be, that is one thing.
However, the complaint that Google has treated them differently is clearly false.
If they want to argue otherwise, the data is all right there for them to use.
> Google's security team first disclosed the vulnerability privately to Epic Games on August 15, and has since released the information publicly following confirmation from Epic that the vulnerability was patched
Meanwhile, they have accused Google's disclosure, which is completely in line with their existing disclosure behavior that they stubbornly enforce for everybody, as being a PR move, intended to harm Epic Games for their decision to launch outside Play Store. It's clear that Android has a bad reputation for security issues and insane to think that Google would not want to make sure that the launch of a super popular video game on their platform doesn't turn into a security disaster.
I generally respect Epic Games, but I don't understand what seems to be pretty greedy on their part. If they wanted to start a discussion about the fairness of app store taxes, I don't think this will accomplish that personally.
Meanwhile, Apple's definitely looking pretty smart. They're probably making good money off of Fortnite and won't suffer any of the bad UX or security issues Android users will be exposed to.
As indicated in the article this vulnerability has as much to do about ... the way Android's permissions model works...
That new malicious app then gets to somehow have more permissions than the original malicious app or the installer.
Guys, that's an Android bug. This is exactly the kind of thing that needs to be fixed at an OS level, you can't be relying on the competence of arbitrary developers to maintain the security of the system.
Of course it's an opportunity for Google to use their own broken security model as an argument on why apps should only come from their own "curated" channels (which presumably also host the malware exploiting this). It just so happens to be their source of revenue...
There are two ways to fix this. One is to not permit dynamic code loading or app installs off the Play Store. This is Apple territory and pisses people the hell off. The other is to not have any world writable filesystem at all. I guess you could do this, but this messes with features surrounding music and pictures that you do want to share between apps.
Epic literally could have used the private filesystem that is right there just for the purpose of having files that are protected from other apps.
According to Google issue tracker: "This patch changes the default APK storage directory from external to internal storage, which should prevent MITD attacks during the install flow."
https://issuetracker.google.com/issues/112630336#comment5
It should not be possible for an application that happens to install other applications to bypass the user for specific permissions. The user must be asked explicitly.
This has nothing to do with being able to "sideload" apps or not. Sideloading apps is actually possible on iOS, it's just such an effort (getting a developer account) that it's rarely done in practice.
The only people who would advocate this are Google since they gain financially from the model and those who use 'security' to promote walled gardens and moats.
Most technical people don't approve of lockdowns and loss of freedom. There is a balance here. If installing apps from the web is a problem then 90 percent of current software is 'insecure'.