Hacker News Reader

Comment by klingonopera | Hacker News Reader

> However, if you install an application from an untrusted source, attackers can take advantage of that.

I'm slightly confused: Do they mean any app or a compromised app?

A compromised app. The vulnerability requires local code execution, so either an app you install and run, or a malicious webpage that somehow breaks out of the browser sandbox, or... loading a specially constructed video file in a vulnerable version of VLC, or something. Basically you need to combine this with some other vulnerability or convince the user to just straight up run the code.

Thanks, the ambiguous wording from the article suggested to me that a vulnerability in the system code used for installing from an untrusted source may be used by the exploit.

What wasn't clear was that is there a known browser sandboxing vulnerability at this point that can be used to get root or the idea is that if someone has one they could use this one to get root. Can I use Chrome in my Android phone now or cannot?

Generally to exploit an OS from within Chrome you need 2 vulnerabilities: (1) to break out from javascript into machine code execution within the sandbox, (2) to break out of the sandbox into the general OS (and maybe (3) to then get root on the OS).

From my reading of this comment[1], it sounds like this vulnerability is such that if an attacker has vulnerability (1), this vulnerability can be used as vulnerability (2) and (3). It sounds like NSO group either had or has a separate vulnerability (1), possibly something from [2].

[1] https://bugs.chromium.org/p/project-zero/issues/detail?id=19...

[2] https://www.cvedetails.com/product/15031/Google-Chrome.html?...

Yes, it's frustrating when people casually conflate using any alternative source of apps than official app stores with actual malicious application sources.

The reality is, you don't need to "trust" the source in general, you just need to trust that the source is not malicious. If the source is untrusted but you have faith it is not malicious then you can rely on Android's built in permissions system to protect you from it exceeding the bounds of what you would like it to do.

This may sound very pedantic, but the whole existence of an app ecosystem that isn't controlled by the hegemony of the 2 or 3 big app stores depends on this nuance.

Android’s built in permission system didn’t work too well with the Fortnite installer

https://www.pcmag.com/news/363357/google-irks-epic-games-by-...

this has nothing to do with androids permission system at all... epic made the decision to distribute Fortnite themselves while bypassing the Play Store in order to save on the 30% cut google would otherwise get from game sales. This worked by installing an app manually that did download the game and installs or updates it afterwards. This installer had a serious flaw allowing malicious apps to install other software by abusing rights the installer had gained to install or update the game.

You could claim google has been irresponsible for publishing technical details about this flaw in epics installer too early but it still has nothing to do with Androids permission system.

From the article

“However, on Aug. 15, a Google researcher discovered a flaw with the installer, which can let a separate app on your phone hijack what the software actually downloads.”

So a separate app can hijack what another app does. That means the sandbox is broken.

their installer downloaded the game into shared storage. They should at least have known that access to shared storage is not sandboxed and should have been verifying what they are about to install instead of trusting no other app would maliciously place an apk where their installer did expect it to be... ideally they would never have used shared storage at all... that said, the sandboxing and permission system worked as expected.

So you have to trust the app not to do anything stupid or malicious? Isn’t the whole point of an operating systems permission system so you don’t have to trust the developer? All apps having access to shared storage without explicit permission is no better than computer operating systems.

If an app can trash your user data the permission system is useless.

If you install an app that has permission to install other apps with arbitrary permission sets... Yes, you must trust them not to do anything stupid or malicious. However this is by choice you don't have to trust them although that means you should not allow them either.

I would agree that conflating external storage options with shared storage was a huge mistake which made developers somewhat unaware that this is something that is actually not sandboxed as anything else would have been. But i think nonetheless it is the responsibility of the developer to not just assume how stuff works and in this case it is quite obvious if you actually happen to ask yourself if something like this would be possible. This is especially true if you require novice users to install your app with delicate permissions as the ability to install other apps.

To be clear on this, they made the choice to use shared storage instead of using storage protected by androids sandboxing and permission systems. They probably made this choice without knowing that they are effectively allowing other apps access to files of their installer because shared storage has been conflated with external storage options but mainly because they did not evaluate the options they had and the implications of those carefully enough.

Apparently Android 10 improved this somehow (probably by making filesystem permissions work as usual).

No.

There are things intentionally included and things intentionally excluded from the sandbox. App-specific data storage is part of the former, and external storage access is part of the latter (this changed with Android 10, anyhow).

Epic's installer used the external storage

Kudos to Epic for using their power to attempt to break Google's Play Store hegemony, facepalms for unfortunately proving one of Google's (both legit and pretended) concerns on safety and security regarding acquiring apps from outside of the Play Store.

Hasn’t the entire argument been that Android’s permission system would have prevented this even if the app was installed outside of the store?

The Epic app installed other apps using a private Samsung API, so the apps were installed using the permissions of the Samsung Galaxy Apps Store app, which has permission to install other apps (on Samsung devices). There is nothing to stop a similar confused deputy vulnerability in the iOS App Store. The Android permission system prevents it from taking pictures or doing other things it was not granted permission to do.

Except there isn’t a way for an app to download code outside of the App Store and have the executable bit set.....

There isn't a way to do that on Android either. You have to use the confused deputy to install the app.

The installer as designed was able to download code and execute it - so there was obviously a way to do it on Android.

> The installer as designed was able to download code and execute it

No, it was able to download code and ask a Samsung app store system app to install it. This doesn't work on non-Samsung Android devices, and the exact same confused deputy problem can exist on iOS.

Reply on news.ycombinator.com