search

Suicide-Squirrel / issues_pie

LG G4 stuff has been completely moved here: https://github.com/LGgFour
8 stars 0 forks source link

microG support? #30

Closed steadfasterX closed 4 years ago

steadfasterX commented 5 years ago

The report: https://forum.xda-developers.com/showpost.php?p=80285021&postcount=989

The patch: https://github.com/microg/android_packages_apps_GmsCore/blob/master/patches/android_frameworks_base-P.patch

The problem: https://review.lineageos.org/c/LineageOS/android_frameworks_base/+/195284/2#message-69493308d0767d8a4fe0176a63de5921db614405

More details: https://www.reddit.com/r/LineageOS/comments/8p4169/what_is_lineages_position_on_signature_spoofing/e088xyh/

A review: http://blogs.fsfe.org/larma/2016/microg-signature-spoofing-security/

So is it still security relevant or not?! When this permission can be granted to a system app only I'm fine - as long as:

For this the patch must be reviewed and tested while the above already states more or less clear the impacts it can have.

EDIT Patch repo: https://github.com/sfX-android/android_signature_spoofing

steadfasterX commented 5 years ago

patch review

about (background)

On android every app has a package name, which is used to identify the app. This package name is static and it never mutates across app updates.

To make sure your app doesn't get replaced with a fake one with the same package name, android has a security feature that checks for the app signature before allowing the "update/installation". If this check is disabled (that's what signature spoofing does), I can install whatever I want over any app i want [....]

source

technical review

  1. the patch itself works
  2. when an app requests that permission (tested with "Signature spoof checker" downloaded from f-droid) the user gets prompted for allowing/denying

disadvantages of this patch:

about (security concerns)

note: follow up of the topic "about (background)" above

[...] and gain all that app's privileges (think about your phone app being replaced with a malicious one: you'd not even be asked for access to your contacts / calls). Also it'd gain access to all the original app data: a malicious email app could just read all your emails without having to know your password.

This is just bad and for no reason we'll allow the possibility of an app being replaced with another, even if there are toggles and alerts, those can be "bypassed" through UI spoofs (these kind of attacks that rely on displaying fake content above the real one are pretty common in android and you can find a lot of media coverage about them).

source

security review

  1. breaking trusted APIs is always a bad idea. I totally understand and agree with the LOS devs here
  2. the patch allows to use spoofing on any app (with the user prompting ofc) so it is not possible to restrict it to a specific (set of) app(s). time shown that users do not read or if then they might not understand the impact of this implementation.
  3. while I agree in most parts of the security concerns I am ok with it when it can be implemented in a secure manner, i.e.:
    • disabled by default or limiting it within build to an app or set of apps (the latter would be a plus even when the first can be achieved)
    • disable/enable option in developer options
    • listing all apps with that permission (guess dev options as well)
    • reverting a given permission (guess dev options as well)

Conclusion

I am sorry to say that but the 2/3 disadvantages listed in the "technical review" topics prevents me from adding this to my LOS builds. I do not agree with the opinion of some of the LOS devs who even would reject the patch then because of UI spoofing etc. If that is the concern here then absolutely no option in the developer options or anywhere are safe to use.

Same applies to root of course. LOS comes pre-rooted while it is not enabled by default. You have to go to the developer options, enable adb debugging and select root for adb. No LOS root-addon etc are needed here and this opens up..well root access to the device. More or less the same is what I would do with the microG patch (I won't but if..) as the approach is similar.

Most people (or at least a big amount) have rooted their custom ROM though. Either with magisk or the LOS root-addon. Even when rooting a device is a bit more tricky to use for malware this can be done easily when ppl do not read properly or install stuff from untrusted sources. I get the point to not allow spoofing by default and that it needs to be hardened a bit like I mentioned above though. Other then that it is "just" a major security flaw like root which is accepted by (almost) everyone.

TL;DR

if the listed disadvantages could be solved as described in the topic "security review" this can be added.

steadfasterX commented 5 years ago

omg I was just blind!

steadfasterX commented 5 years ago

completed! :) will be pushed tomorrow, then finally new LOS builds can happen

steadfasterX commented 4 years ago

will be implemented with the next build..

mar-v-in commented 4 years ago

@steadfasterX Sorry for digging this out, but I was linked to it recently.

You are quoting from a reddit post of a LineageOS developer, that apparently had no idea what he was talking about.

To make sure your app doesn't get replaced with a fake one with the same package name, android has a security feature that checks for the app signature before allowing the "update/installation". If this check is disabled (that's what signature spoofing does), I can install whatever I want over any app i want and gain all that app's privileges (think about your phone app being replaced with a malicious one: you'd not even be asked for access to your contacts / calls). Also it'd gain access to all the original app data: a malicious email app could just read all your emails without having to know your password.

This is just bad and for no reason we'll allow the possibility of an app being replaced with another, even if there are toggles and alerts, those can be "bypassed" through UI spoofs (these kind of attacks that rely on displaying fake content above the real one are pretty common in android and you can find a lot of media coverage about them).

This is just completely incorrect. All the signature spoofing patches I am aware of do not affect the security of the android package manager. The package manager always sees the certificate that was actually used to sign the app and not the spoofed one and will not allow you to replace legit apps with rogue ones that spoof signatures. The patches do not affect signature level permissions, or any other official app security system that is based on certificates.

More over, even if the patch affected the package manager, the described attack would not work: the permission to spoof signature has to be granted by the user after installation of the app or the app update introducing the permission usage. Assuming the original app does not use signature spoofing, the rogue replacement would need to be installed first before requesting the spoofing permission, however the update cannot be installed because the certificate mismatches.

IMO the best solution to date if you fear of security impact of signature spoofing (which is debatable) is to use the very same patch but change the permission level to privileged|signature. That way, the permission would only be granted to apps that reside on the system permission (in priv-app folder) which already implies that whoever installed the app got full root access and therefor could have done way severe changes to the system's security.

steadfasterX commented 3 years ago

@steadfasterX Sorry for digging this out, but I was linked to it recently.

You are quoting from a reddit post of a LineageOS developer, that apparently had no idea what he was talking about.

To make sure your app doesn't get replaced with a fake one with the same package name, android has a security feature that checks for the app signature before allowing the "update/installation". If this check is disabled (that's what signature spoofing does), I can install whatever I want over any app i want and gain all that app's privileges (think about your phone app being replaced with a malicious one: you'd not even be asked for access to your contacts / calls). Also it'd gain access to all the original app data: a malicious email app could just read all your emails without having to know your password. This is just bad and for no reason we'll allow the possibility of an app being replaced with another, even if there are toggles and alerts, those can be "bypassed" through UI spoofs (these kind of attacks that rely on displaying fake content above the real one are pretty common in android and you can find a lot of media coverage about them).

This is just completely incorrect. All the signature spoofing patches I am aware of do not affect the security of the android package manager. The package manager always sees the certificate that was actually used to sign the app and not the spoofed one and will not allow you to replace legit apps with rogue ones that spoof signatures. The patches do not affect signature level permissions, or any other official app security system that is based on certificates.

More over, even if the patch affected the package manager, the described attack would not work: the permission to spoof signature has to be granted by the user after installation of the app or the app update introducing the permission usage. Assuming the original app does not use signature spoofing, the rogue replacement would need to be installed first before requesting the spoofing permission, however the update cannot be installed because the certificate mismatches.

IMO the best solution to date if you fear of security impact of signature spoofing (which is debatable) is to use the very same patch but change the permission level to privileged|signature. That way, the permission would only be granted to apps that reside on the system permission (in priv-app folder) which already implies that whoever installed the app got full root access and therefor could have done way severe changes to the system's security.

thx for taken the time to write this and shedding some light into the dark!

I still feel better if there is an option to disable it completely. I compare that with Linux: actually you do not need a firewall on a linux server - as long as you handle your system and applications right. But having a protection is good for the case something goes wrong (either by a running service or a human fault).

That means ppl who really do not want to use that feature can simply not enable it and the ROM maintainer do not need to build 2 ROMs for those who want the patch and the others. The main clue I had in mind was also this way might be better accepted by LOS upstream than the current set of patches!

Yes the restriction to just allow spoofing to builds which are included is perfectly fine usually and the above extension is for a small group only but still it really does not hurt having it. It is just another layer of protection and I prefer having it.

debie-A320FL commented 2 years ago

I just find your patch for Pie, and it looks exactly what I am searching for ! Out of curiosity, did you do similar patchs for more recent android version ? (Or/And what do you use in 2022 ?). Thanks for your work and have a good day ;).

steadfasterX commented 2 years ago

I just find your patch for Pie, and it looks exactly what I am searching for ! Out of curiosity, did you do similar patchs for more recent android version ? (Or/And what do you use in 2022 ?). Thanks for your work and have a good day ;).

uh this org is deprecated ;) anyways the latest you can get is here: https://github.com/sfX-android/android_signature_spoofing but yea Pie is the latest. The main reason for that is that I switched completely to /e/ OS