5 ms·

The ACTION_MAIN loophole has been written about before: https://commonsware.com/blog/2020/04/05/android-r-package-visibility-holes.html https://commonsware.com/

The ACTION_MAIN loophole has been written about before: https://commonsware.com/blog/2020/04/05/android-r-package-visibility-holes.html https://commonsware.com/blog/2020/04/05/android-r-package-vi... Google refuses to patch this. I wonder what would happen if you submit it to the Android VDP as a permission bypass. There’s also this SO question by the author about the bypass: https://stackoverflow.com/q/79527331 https://stackoverflow.com/q/79527331

nexle 2y ago
Thanks for the link, seems like the loophole is already there since the introduction of the package visibility restriction, and almost everyone and their mother knows how to bypass this restriction. > Google refuses to patch this While I don't believe Google engineers are not aware of this widely used loophole, do you have any source that they refused to fix it?
- AznHisoka 2y ago
  That loophole was published 5 years ago, it hasnt been fixed since. Do you need someone from Google to explicitly write an official note, notarized, indicating they are refusing to fix it?
  - ignoramous 2y ago
    > refusing to fix it Google addressed similar isolation concerns (without breaking a tonne of APIs in incompatible ways) with Private Space and Work Profile: https://source.android.com/docs/security/features/private-space https://source.android.com/docs/security/features/private-sp...
    - deleted 2y ago
      [deleted]
    - whs 2y ago
      If it's a security issue fix, they should release it in one of the monthly security patch. I also think that private space do not fix the underlying issue. If you have four apps and you don't want them to know about each other you can put one of them in main profile, work profile, app locker and you run out of profile for the last one. The way app locker work doesn't scale to tens of sandbox.
      - subscribed 2y ago
        I know you didn't ask for this sort of answer, but you could use user profiles for this. You can have more users on the "standard" AOSP Android as well, but with a certain AOSP-derived you can also have notifications forwarding. Until they add Application List Scopes (I believe it's on the road map), in the exactly the same way users can now lie to apps they have only specific contacts in their contact list and only one or two specific folders in the Storage.
    - 1oooqooq 2y ago
      that proves bad faith. they keep releasing overly complicated features to sidestep the obvious reported vulnerability, to silence power users and please corporate enterprise sysadms. the rest of the 99.9 of users keep the vulnerability, which is very profitable for ad networks. wonder why an ad networks who maintains android would do that.
izacus 2y ago
What do you mean with "refused to patch this"? Google will reject any app publishing attempt that asks for that filter and isn't a launcher on Play store.
- jim201 2y ago
  Author claims that this same hack is used widely, including by apps on the Play Store like Snapchat and Facebook.
- whatevertrevor 2y ago
  How is that congruent with the article's claim that 31 out of 47 apps they tested had this filter?
  - izacus 2y ago
    No idea, but we did have apps rejected because of similar permissions.
    - cAtte_ 2y ago
      "similar". so what you said isn't true then?
      - fuckbrownpeople 2y ago
        [dead]
- Mindwipe 2y ago
  The HSBC bank app uses this and is in the Play Store.
3abiton 2y ago
> Google refuses to patch this. That's why projects like XPL-Extended (and previously XPrivacyLua), are an absolute need. I never run an android phone without these.
- ignoramous 2y ago
  XPrivactLua and other XposedMod/Magisk extensions break open the app sandbox. It is better to restrict running those on usereng/eng builds (test devices). For prod builds (user devices), I'd recommend using Work Profiles (GrapheneOS supports upto 31 in parallel) or Private Spaces (on Android 15+) to truly isolate apps from one another.
  - pava0 2y ago
    What do you mean by "break open the app sandbox"?
    - schnatterer 2y ago
      I found this description about the security risks of rooting very eye-opening https://madaidans-insecurities.github.io/android.html https://madaidans-insecurities.github.io/android.html It also explains the sandbox.
      - ignoramous 2y ago
        A more recent (2023) sandboxing + isolation overview by the Android team: https://arxiv.org/html/1904.05572v3/ https://arxiv.org/html/1904.05572v3/ (section 4.3)
        NotPractical 2y ago
        > Android’s security design has fundamentally been based on a multi-party authorization model: an action should only happen if all involved parties authorize it. > these are user, platform, and developer (implicitly representing stakeholders such as content producers and service providers). Any one party can veto the action. How is this not anti-user? It explicitly states that the app developer should be able to veto my decisions...
ErigmolCt 2y ago
Submitting it to the Android VDP is a solid idea, though I wouldn't be surprised if it gets waved off as "working as intended."
- deleted 2y ago
  [deleted]
- gregw2 2y ago
  The right ("as intended", in my view) functionality would be to support a manifest with, say, five apps, and if as a dev you wanted more youd apply to google for an exception (like aws limit increases) with a list of reasons for each app.
  - TeMPOraL 2y ago
    I know people may not remember this, but Android was initially designed with interoperability in mind. It's sad to see both the system development and the community opinion to have turned against it so hard.
fluidcruft 2y ago
It seems like the ACTION_MAIN loophole could be fixed (eventually) if apps that declare it are required to actually be launchers. It seems like legitimate integrations should have more specific intents. At that point, Android prompting if random game you just downloaded should be your defaut launcher seems pretty dangerous interaction for sneaky apps to risk. They either cause the user to bounce and report or the fools select it as default launcher, replace their launcher, can't provide the launcher functionality and break the user's home screen and end up getting reported in Play Store. I also assume actually getting published as a launcher-class app at that point brings automated testsuites and other requirements that will be burdensome for developers.
- robertlagrant 2y ago
  That sounds very sensible.

nexle 2y ago

Thanks for the link, seems like the loophole is already there since the introduction of the package visibility restriction, and almost everyone and their mother knows how to bypass this restriction. > Google refuses to patch this While I don't believe Google engineers are not aware of this widely used loophole, do you have any source that they refused to fix it?

AznHisoka 2y ago
That loophole was published 5 years ago, it hasnt been fixed since. Do you need someone from Google to explicitly write an official note, notarized, indicating they are refusing to fix it?
- ignoramous 2y ago
  > refusing to fix it Google addressed similar isolation concerns (without breaking a tonne of APIs in incompatible ways) with Private Space and Work Profile: https://source.android.com/docs/security/features/private-space https://source.android.com/docs/security/features/private-sp...
  - deleted 2y ago
    [deleted]
  - whs 2y ago
    If it's a security issue fix, they should release it in one of the monthly security patch. I also think that private space do not fix the underlying issue. If you have four apps and you don't want them to know about each other you can put one of them in main profile, work profile, app locker and you run out of profile for the last one. The way app locker work doesn't scale to tens of sandbox.
    - subscribed 2y ago
      I know you didn't ask for this sort of answer, but you could use user profiles for this. You can have more users on the "standard" AOSP Android as well, but with a certain AOSP-derived you can also have notifications forwarding. Until they add Application List Scopes (I believe it's on the road map), in the exactly the same way users can now lie to apps they have only specific contacts in their contact list and only one or two specific folders in the Storage.
  - 1oooqooq 2y ago
    that proves bad faith. they keep releasing overly complicated features to sidestep the obvious reported vulnerability, to silence power users and please corporate enterprise sysadms. the rest of the 99.9 of users keep the vulnerability, which is very profitable for ad networks. wonder why an ad networks who maintains android would do that.

izacus 2y ago

What do you mean with "refused to patch this"? Google will reject any app publishing attempt that asks for that filter and isn't a launcher on Play store.

jim201 2y ago
Author claims that this same hack is used widely, including by apps on the Play Store like Snapchat and Facebook.
whatevertrevor 2y ago
How is that congruent with the article's claim that 31 out of 47 apps they tested had this filter?
- izacus 2y ago
  No idea, but we did have apps rejected because of similar permissions.
  - cAtte_ 2y ago
    "similar". so what you said isn't true then?
    - fuckbrownpeople 2y ago
      [dead]
Mindwipe 2y ago
The HSBC bank app uses this and is in the Play Store.

3abiton 2y ago

> Google refuses to patch this. That's why projects like XPL-Extended (and previously XPrivacyLua), are an absolute need. I never run an android phone without these.

ignoramous 2y ago
XPrivactLua and other XposedMod/Magisk extensions break open the app sandbox. It is better to restrict running those on usereng/eng builds (test devices). For prod builds (user devices), I'd recommend using Work Profiles (GrapheneOS supports upto 31 in parallel) or Private Spaces (on Android 15+) to truly isolate apps from one another.
- pava0 2y ago
  What do you mean by "break open the app sandbox"?
  - schnatterer 2y ago
    I found this description about the security risks of rooting very eye-opening https://madaidans-insecurities.github.io/android.html https://madaidans-insecurities.github.io/android.html It also explains the sandbox.
    - ignoramous 2y ago
      A more recent (2023) sandboxing + isolation overview by the Android team: https://arxiv.org/html/1904.05572v3/ https://arxiv.org/html/1904.05572v3/ (section 4.3)
      - NotPractical 2y ago
        > Android’s security design has fundamentally been based on a multi-party authorization model: an action should only happen if all involved parties authorize it. > these are user, platform, and developer (implicitly representing stakeholders such as content producers and service providers). Any one party can veto the action. How is this not anti-user? It explicitly states that the app developer should be able to veto my decisions...

ErigmolCt 2y ago

Submitting it to the Android VDP is a solid idea, though I wouldn't be surprised if it gets waved off as "working as intended."

deleted 2y ago
[deleted]
gregw2 2y ago
The right ("as intended", in my view) functionality would be to support a manifest with, say, five apps, and if as a dev you wanted more youd apply to google for an exception (like aws limit increases) with a list of reasons for each app.
- TeMPOraL 2y ago
  I know people may not remember this, but Android was initially designed with interoperability in mind. It's sad to see both the system development and the community opinion to have turned against it so hard.

fluidcruft 2y ago

It seems like the ACTION_MAIN loophole could be fixed (eventually) if apps that declare it are required to actually be launchers. It seems like legitimate integrations should have more specific intents. At that point, Android prompting if random game you just downloaded should be your defaut launcher seems pretty dangerous interaction for sneaky apps to risk. They either cause the user to bounce and report or the fools select it as default launcher, replace their launcher, can't provide the launcher functionality and break the user's home screen and end up getting reported in Play Store. I also assume actually getting published as a launcher-class app at that point brings automated testsuites and other requirements that will be burdensome for developers.

robertlagrant 2y ago
That sounds very sensible.