OSDev.org

Gonna rant about Android but putting it here because it's definitely relevant to OS design (as it's directly tied to how to install applications in a safe way).


Epic (who decided to by-pass the Playstore for Fortnite on Android) got called out recently for a vulnerability in their installer (fixed by now, don't worry). But what worries me more is the real reason behind it, and I'm calling out Google for that.

For context: the problem with the installer was that it'd install Fortnite on external storage (which at first makes sense, since it's often much larger). The vulnerability is that, huh, it's just another file on storage and as such anything can mess with it (read or write). Google's solution to this problem was that since Android 4.4 all apps have to be installed in a dedicated partition in internal storage that's off-limits to anybody who isn't the OS.

But I'd argue that it should be time for Google to find out how to install an app securely on external storage (especially since most people won't remove the SD card, so for them it could be useful). The dedicated partition is relatively small and apps bloat over time (especially the uninstallable Google apps that will immediately update back again the moment you attempt to disable them) and on low-end phones that means that after a while you'll find yourself uninstalling stuff because it keeps running out of space, and it honestly feels pretty irritating that one has to do this when the SD card has lots of free space that's going unused. I mean, seriously? (and buying a new phone isn't always an option, that costs money that could go to another stuff like, dunno, food - let's not pretend that people are bottomless barrels of money, especially when it's something that's mainly a software issue)

One solution I thought that could work is that when an app is installed its files could be signed with a key specific to that particular phone that only the OS has access to, which at least should make it pretty hard to meddle with it (one side effect is that the app would only run on that phone, but I won't count it as necessarily DRM since that restriction doesn't apply to the installer itself). Ideally same should go for the data they store (e.g. contacts and such, although I'm not sure how much of an impact this has on performance).


PS: oh by the way, even Google's current solution isn't foolproof (and I'm not talking about privilege scalations). The reason many games demand access to your files is because they store their data in a blob in the other partitions (precisely because of size limits). That renders the whole idea completely useless when the apps regularly work around it anyway.

Taking a cryptographic checksum of an app -- especially a large one stored externally -- is a rather expensive operation that would delay startup (something casual users are very touchy about) significantly. I don't say it cannot (or should not) be done, but it's a cost-benefit issue, especially on cheaper smartphones that might not have the raw CPU oomph.

As for applications intentionally circumventing security features, well... basically, you are making two mutually exclusive demands here, that apps should be able to store externally, and that they shouldn't.

As mentioned, the only solution would be to take a checksum of all files involved in the application before starting any of it... which would either rule out even a splash screen with progress bar, or require that to be an OS-controlled feature (static bitmap plus OS-provided progress bar).

This -- as well as other security approaches, like limiting an application's access to its own subdirectory and directories explicitly shared -- relies on a culture of applications playing nice with those restrictions. Unfortunately, the reality of smartphone app culture is "give me all the access, and I won't even really tell you why and what for". Same as websites giving you no alternative but accepting their "use of cookies"-policy if you want to use their service.

We've opened the box, and handed the key to the snoopers. I somewhat despair at getting back security.

I don't understand the whole issue. It seems to be a big smokescreen to me. This is not a technical issue, rather a nasty big money corp business move.

Think about it: all Linux distros allow multiple reporitories without security issues! But let's examine the situation:

1. the downloaded apk is hijacked during the download
This is a threat even if you don't use external storage. And can be easily solved by using ssl and checksum+digital signature check in the installer (no application start penalty, only one checksum calculation after download). Same way as apt-get, yum, pacman etc. does on other Linuxes.

2. the apk is modified on the storage by a malware
How got the malware on the phone in the first place? And why is write permission granted on the apk? It should not be writable at all (regardless if it's on the system partition or on an external storage). The OS is responsible for avoiding that (the famous rwx bits), and should grant temporary write access for the installer (with sudo/setuid etc.). There's nothing an installer can or should do about this. Same way as in other Linuxes a normal user can't overwrite files in neither /bin nor in /usr/bin (where /usr is very likely mounted, therefore can be on an external storage).

3. the apk is modified when the SD card is mounted on another computer
Simple, repeat the checksum calculation on mounting /usr/bin too (or whatever that's called on Android). No application start penalty in this case either, only a bit slower mounts.

Either way this is NOT a Fornite vulnerability, the same stands for any other application. It is a fact, that non-Android Linux distros had already solved this issue therefore it can be done for sure. Anybody saying otherwise is lying. Considering that it is in Google's best interest to lie about that and tie the users to their appstore exlusively. So I'm not surprised at all that they are blaming a third party instead of providing a solution.

OK, I admit I overlooked the performance issue. Mind you, I had assumed that it'd have to decrypt the file and that you'd get corrupt data if you tried to tamper with it (resulting in a crash, which is probably much safer). Though I imagine it wrecks havoc for archives where you'll want to seek (probably a good time to do the encrypting inside the archive itself instead of on top of it).

It'd probably help if the freaking app wasn't 100MB for starters either.

I suppose one of the biggest issues with external storage is that it's usually some variant of FAT and those don't have proper file permissions, right? (and even then, file permissions are often pretty pointless unless the corresponding user list is there to match it against)

Sik wrote:Mind you, I had assumed that it'd have to decrypt the file and that you'd get corrupt data if you tried to tamper with it (resulting in a crash, which is probably much safer)

Not entirely on topic, but I think having the OS try to execute (pseudo)random data is a huuuuuuuuge security concern, especially since an attacker could potentially forge the executable such that when it is decrypted with the wrong key it's actually valid malicious code, so I think this would actually be worse under every aspect.

But that'd imply that there's either some weakness in the cypher used (so you can reliably inject the exploit) or the key got stolen somehow (privilege escalation). In either case you have much bigger problems to worry about.

You could try to checksum while decrypting, but if an attacker can reliably mess with the encrypted file then they can likely figure out how to compute a new checksum too.

The solution seems obvious to me, unless I am missing something:

eCryptfs

The Android phone can keep both public and private keys hidden, so only that specific phone will be able to decrypt the files.

Sik wrote:I suppose one of the biggest issues with external storage is that it's usually some variant of FAT and those don't have proper file permissions, right?

FAT does have read-only access attribute. But one could always force a check upon write regardless to the filesystem (if the filename ends in ".apk" or starts with a certain magic bytes, or the realpath starts with "/usr/bin" etc.). Simple, fast, O(1) checks.

Sik wrote:You could try to checksum while decrypting, but if an attacker can reliably mess with the encrypted file then they can likely figure out how to compute a new checksum too.

No encryption needed. You calculate the checksum for the file, and you digitally sign the checksum. No attacker can reliably recalculate the checksum because they can't sign it. The only problem here is if the private key (used to sign the checksum) gets out. Like it happened with Sony PS4 (which can be redeemed by revoking and distributing a new privkey. The problem with PS4 was that the privkey is burnt into ROM).

As I have said, this whole problem is non-existent, as there are many working solutions out there (PS4, UEFI Secure Boot etc.)

bzt9999 wrote:FAT does have read-only access attribute. But one could always force a check upon write regardless to the filesystem (if the filename ends in ".apk" or starts with a certain magic bytes, or the realpath starts with "/usr/bin" etc.). Simple, fast, O(1) checks.

Er right, should have been more explicit. FAT does have a read-only flag, but it's more to prevent accidental writes and any user is allowed to change the flag. It's not like POSIX-style permissions where you can make it so that only a privileged user or the original owner can mess with the file. The path approach is not that useful here either, since kind of the whole point here is to be able to install programs in a partition shared with other things (maybe "soft" partitions, where specific directories act as if they were sub-partition? then paths could work...)

Not even going to count the possibility of the card being removed and modified elsewhere because there really isn't anything you can do about that (and the people who would use external storage for installing probably would never remove it anyway). This is more to protect against opportunistic malware on the phone itself.

bzt9999 wrote:As I have said, this whole problem is non-existent, as there are many working solutions out there (PS4, UEFI Secure Boot etc.)

Tell that to Google.

Not disputing it, I'm just more calling bullshit on Google's insistence that they can't find a way to make things secure without resorting to a small(ish) partition on internal storage. I could even make the conspiracy that it's to force people to buy more phones once the memory is exhausted (though it's more likely just that Google doesn't want to bother).

Sik wrote:card being removed and modified elsewhere because there really isn't anything you can do about that

I've already answered that

bzt9999 wrote:3. the apk is modified when the SD card is mounted on another computer
Simple, repeat the checksum calculation on mounting /usr/bin too (or whatever that's called on Android). No application start penalty in this case either, only a bit slower mounts.

General case: check any directory which is under the newly mounted path and also listed in $PATH
Alternative: keep a list of modification times in kernel area, so only check executables for the first time execution (if/when they're modified). One time start penalty only, same as with JIT compilers.

Sik wrote:I'm just more calling bullshit on Google's insistence

Agreed!

Sik wrote:I could even make the conspiracy that it's to force people to buy more phones once the memory is exhausted

That's not a conspiracy, all business interested in increasing sales and therefore maximizing their profits. IT IS a fact.
I also say it's about to tie users to their own GayPlay Store, again, simply because of the profit motive.

Nah, I don't think the Play Store has anything to do with this, because older versions of Android allowed you to move installed apps to external storage, regardless if they came from the store or not :​/ (the only downside was that apps on external storage couldn't issue alarms and such, since the SD card may not be ready to use when that happens, depending on the hardware state)

But that only makes the whole thing feel even worse.


EDIT: also, not gonna lie, I started this thread out of curiosity to see if people here have better ideas than what I suggested in the first post :​P