"It has been claimed that the Privacy Guard implementation of ‘su’ has security vulnerabilities even when disabled. In other words, the mere presence of the su binary is enough to compromise the device.
Unfortunately, the person who reported this vulnerabilty refuses to disclose its exact nature, nor could we make sure to properly fix this exact issue. The next best solution is to ensure that su is only accessible when enabled in the Settings app and keep su disabled when it’s not in use.
We’ve created a kernel patch that hides the existence of su from all processes except root and system when the su daemon is not running (root needs access so that init can start the su daemon, and system needs access in order to populate the root access settings appropriately).
This effectively makes it impossible for unprivileged processes to exploit su when it is disabled in settings. Indeed, it makes it impossible to even see that the su binary exists. It cannot be seen either directly (via stat /system/xbin/su) or indirectly (via ls /system/xbin). A side effect of this, is that Play Services can’t detect su binary when root is disabled either, allowing some (older) devices to pass SafetyNet when root is installed but disabled.
This fix cannot be applied globally but must be merged to each device’s kernel. If your device hasn’t been patched yet, or you’re maintaining a device, take the proper patch and apply it as soon as possible (kernel 3.18, 3.10 and 3.4).
This is a precautionary measure. We are not aware of any active exploits targeting this issue....."
Ref: https://www.lineageos.org/Changelog-9/
Any developers looking to resolve this vulnerability, I already had it merged in my kernel weeks ago
Here https://github.com/anupritaisno1/an...mmit/20796ec7f64678ef644cd8c1085bb01c9e951049
Related
Starting with Android 4.4 SELinux's MAC is enforced. Does this mean that if an app somehow can get installed and exploit the kernel to get root privileges, that MAC will still prevent that app with root privileges from accessing private app data?
Android Documentation says: "SELinux can be used to label these devices so the process assigned the root privilege can write to only those specified in the associated policy. In this way, the process cannot overwrite data and system settings outside of the specific raw block device." source - http://source.android.com/devices/tech/security/se-linux.html#use-cases
As a reference I am implementing a Mobile Device Management system and in the process I have to determine how secure Android OS is itself. That is why I need to know how secure corporate data stored on a device is to root-kits, spyware, and other malware.
p.s. This has been posted on the "Unix and Linux" StackExchange site with no one being able to answer yet. I'm hoping XDA's hands on experience with the Kernel will be able to help get this answered, Thank You .
milleraj66 said:
Starting with Android 4.4 SELinux's MAC is enforced. Does this mean that if an app somehow can get installed and exploit the kernel to get root privileges, that MAC will still prevent that app with root privileges from accessing private app data?
Click to expand...
Click to collapse
The answer is: "It depends."
Mandatory access controls systems like SELinux are very good at constraining application behavior to what is allowed by the security policy. In many cases, it can eliminate huge chunks of security vulnerabilities by sandboxing privileged applications so that exploitation of those applications is ineffective.
You may want to take a look at http://selinuxproject.org/~jmorris/lss2011_slides/caseforseandroid.pdf, specifically slides 7-9. This will give you an idea for what SELinux can and can't defend against.
Noob question.
What is the actual password to su on various smartphone models, say Galaxy S5 or LG L3?
Is it a fixed character string or a formula based upon some hw specific like MAC ID?
Why don't vendors and network providers verify certain apps for su and give those sw vendors their devices' root password, or is it done that way now?
OK found the following on the web.
root in Linux (or any Unix-like system) is just the user with User ID 0. The su program (which actually stands for "Switch User", not "Super User") is just a program to start another program with a different user ID than the starting program (by default to uid 0, which is to user root). Android does not use the traditional /etc/passwd, however it still uses Linux User ID and Group ID for managing permissions.
If you want to intercept su requests so you can ask for password or enforce other rules, you will need to replace /sbin/su with your own version of su. Alternative approach is the one described here:
http://www.koushikdutta.com/2008/11/fixing-su-security-hole-on-modified.html
though that will require applications to cooperate by firing an Intent when they want to switch user.
Android security framework is more or less like this: each installed application runs on its own User ID (selected at installation time), and application permissions is implemented as user groups.
Can i change the root password after rooting my android device by simply typing "passwd"?
Android does not use /etc/passwd so it also does not have*passwd*program.
how is the rooting process working ? i mean what is the "one click root" apps doing to my phone?
I'm not quire sure with the exact process myself, you probably want to ask to rooting developers. However, my guess is it just reverts the security check that originally prevent developer from setuid 0.
End of paste.
So the above is saying there are no passwords in Android. To give an app or file root privilege you must change the app's user id that runs it or users id of the user who created the file to 0 (zero).
Therefore giving root privilege to an app on Android is a su app that changes the user id to 0 of the app you want to give root privilege to.
So why don't hw vendors and network providers who provide the Android ROM include a special su app that checks (look up in a file) whether app is OK for root and then grants it ?
We all know the su binary is a hacked binary which opens up the operating system so how can people say they've added security to their device. We all know androids latest security patchs was not made to support a custom so also how can you say oh we added the largest security patchs to our roms but your operating system is still wide open cause that modification to the su binary.. So I'm starting to get confused to how you can take a hack which opens up your operating system and alters it yet say there's added security and that the phone is more secure than a Rom that doesn't have the su binary modification. How can you take security patchs which wasn't made for custom roms and apply it and say yeah you got the best security we can give. Even if you **** root off its still there in the custom roms.
I'm pretty sure this is the latest version of SuperSU, but every time I reboot my phone I get a message that reads: "The SU binary needs to be updated!", and when I click on the prompt to update it, it always fails and asks me to reboot.
Has anyone else run into this issue, or know how to resolve it? Thanks.
SuperSU APK and the SU binary are two different things :
SU is a binary executable, it's used by Android and other *nix based systems to allow a process to change the user it is run by and therefore what the process has the rights to do (as it inherit the user permissions). In the rooting case, processes invoke SU to switch to the root user therefore acquiring root permissions.
SuperSU is an Android application (.apk is an Android application package), it works as a sort of "gatekeeper" to the SU binary. Applications which attempt to invoke SU will be forced to route through SuperSU, which will then prompt the user with the options of approving or denying the access to SU (and optionally having SuperSU remember their decision and automatically apply it for subsequent calls by that app).
So what happens to you is, every time you boot, SuperSU v2.78 (which is the latest version of the SuperSU APK) checks the SU binary version and tells you that there is a newer version of it and that you should update it.
Then for SuperSU failing to update the SU binary I can't help as for me it always worked till now. But maybe there is a way to manually do it (by finding the binary in a flashable zip that you can flash in recovery)?
bafforosso said:
SuperSU APK and the SU binary are two different things :
SU is a binary executable, it's used by Android and other *nix based systems to allow a process to change the user it is run by and therefore what the process has the rights to do (as it inherit the user permissions). In the rooting case, processes invoke SU to switch to the root user therefore acquiring root permissions.
SuperSU is an Android application (.apk is an Android application package), it works as a sort of "gatekeeper" to the SU binary. Applications which attempt to invoke SU will be forced to route through SuperSU, which will then prompt the user with the options of approving or denying the access to SU (and optionally having SuperSU remember their decision and automatically apply it for subsequent calls by that app).
So what happens to you is, every time you boot, SuperSU v2.78 (which is the latest version of the SuperSU APK) checks the SU binary version and tells you that there is a newer version of it and that you should update it.
Then for SuperSU failing to update the SU binary I can't help as for me it always worked till now. But maybe there is a way to manually do it (by finding the binary in a flashable zip that you can flash in recovery)?
Click to expand...
Click to collapse
Thank you for explaining the difference for me. I went ahead and downloaded the .zip from here: http://forum.xda-developers.com/apps/supersu/stable-2016-09-01supersu-v2-78-release-t3452703/page8
And then used the installation instruction found here: http://androiding.how/how-to-flash-supersu-using-twrp-recovery-and-root-any-android-device/
And I don't seem to be getting the prompt that SuperSU needs to be updated anymore.
Huh. Never mind. Seemed to work for about 12 hours, but now it's asking me to update again, and I can't. Looks like I need step-by-step instructions on how to clear this message, cause whatever I'm doing isn't doing the trick.
Did you disable Sony RIC and dm-verity when you modified the kernel? I'm not sure if it has anything to do with or whether it will solve your problem, but one time I patched my kernel leaving one of the options enabled and ran into all sorts of problems with apps that required root, so after that horrible experience I decided to just disable everything. During that horrid experience, I think I also had SuperSU (or was it busybox?) complain about not being able to update binaries.
Ok lets first explain the situation
I've been dabbling with Tasker (Paid for version)- getting some automation depending on certain situations (mainly stuff like 'If I'm @ {location} get volumes set high' or ' If Unread msg then vibrate my Amazefit bip watch' - Nothing too complicated using variables / javascript etc)
One situation I want to attempt though is 'If Gpay app is started - turn on NFC, but when I leave the app - turn NFC off'
Now I already know there are 2 'main' ways I can turn on/off NFC in Tasker.. either use 'AutoInput plugin' or use 'Secure Settings'
- I've tried with Autoinput plugin but the problem is that with the free option, you need to watch an Ad every day to use it but of course I can pay for it (its only a couple of quid)
However you can't Install it & pay for it directly from within the plugin - you need to install yet another App (AutoApps) first - & although this one is free - I just don't like adding more bloat to my phone than necessary. Adding both the plugin & this additional App adds (although only a 'minor' amount) up to 20Mb
The other method is give Tasker 'Secure settings' permission
- So I read the 'What to do to give 'Write Secure Settings Permission' to Tasker' (enable Developer mode > Usb Debugging > Install ADB on PC etc etc) & it looks simple enough,
But (a loooong time ago) I tried other 'hacks' & it ended up disastrously (probably I did something wrong with missing a step or something) & I just want to make sure that it IS as simple as it seems and also ask how safe is it
for example
* If I type in the command in ADB - could something go wrong & could it crash/brick the phone ?
* Is this permanent - ie if I turn off/on phone or if I get an OTA update & phone restarts - will it stay, or will I have to repeat the ADB command each time ?
* Will this 'break' official OTA updates (whether security &/or Android firmware) - I once did a firmware update with a step that used ADB (IIRC) & it broke something that prevented any updates from happening
- official OR manual firmware updates
Any help/advice would be appreciated
Cannon_Foddr said:
* If I type in the command in ADB - could something go wrong & could it crash/brick the phone ?
* Is this permanent - ie if I turn off/on phone or if I get an OTA update & phone restarts - will it stay, or will I have to repeat the ADB command each time ?
* Will this 'break' official OTA updates (whether security &/or Android firmware) - I once did a firmware update with a step that used ADB (IIRC) & it broke something that prevented any updates from happening
- official OR manual firmware updates
Click to expand...
Click to collapse
ADB is the door to your phone's Android. It's a tool not meant to be used by John Doe. Wrongly used you can brick your phone. Hence it's by default disabled.
1. Yes, using ADB you can render your phone absolutely useless. If you e.g. enter
Code:
adb shell rm -rf /
then phone gets totally wiped ( really all gets destroyed, it gets naked ) - you can throw it into electric waste.
2. ADB commands aren't persistent, but their results may be.
3. ADB itself breaks nothing: it's a driver installed on your computer that let you access Android's files and launch Android executables.
Thanks for the reply
I doubt I'll use THAT command.
I forgot to mention what tasker's command is
adb shell pm grant net.dinglisch.android.taskerm android.permission.WRITE_SECURE_SETTINGS
Not 100% sure about your last comment though.
ADB allows access to android files so changing android files could break things, which I'm worried about especially with OTA updates etc. (my last phone stopped getting OTA updates when I rooted it despite using official firmware)
However IF I understand the above command all this does is tell the android operating system ('android') to only give the tasker app (which 'Real' name is 'net.dinglisch.android.taskerm') the rights ('permission') to access the required settings ('WRITE_SECURE_SETTINGS') which the NFC on/off toggle is part of (settings >connected devices > connection preferences> nfc) & 'shouldn' t' affect any other files such as OTA (unless OTA is also part of secure setting?)
@Cannon_Foddr
As I can see you until now haven't understood what ADB is, how it works.
Same probably your understanding of what an OTA is.
Personally never would allow 3rd-party apps ( like Tasker ) to modify sensible system settings: Tasker isn't an open-source app, so you can't control what it does in the last run.
It's simply on you to decide whether Tasker is given that right, or not ...
Can't see why 'open-source' has to do with this
IMHO if Open-source - anyone can release similar apps with added extra hidden code that could spy's on you/steal info etc, but a 'closed sourced' app from a long running developer (tasker been around for 10yrs with over 1mil downloads) must mean people seem to trust him/them & if he was 'dodgy' surely he would've been caught out by now
Anyway the Bottom line seems to be
Safe route: pay for plugin & live with extra bloatware
Or
Risky route: give access to secure system resources, see what happens & keep fingers cross nothing does
Thanks for your replies.. I think I may have to sit down & have a long hard think which route I feel more comfortable with
I have been using Automate for about 4 months now. I granted it WRITE_SECURE_SETTINGS and I have not noticed any modifications in my system. Granted I may have not looked specifically for them but as far as braking the system or disruption of OTAs no issues so far
DennisHarrows said:
I have been using Automate for about 4 months now. I granted it WRITE_SECURE_SETTINGS and I have not noticed any modifications in my system. Granted I may have not looked specifically for them but as far as braking the system or disruption of OTAs no issues so far
Click to expand...
Click to collapse
I assume you had to do something like Taskers command then to grant the secure settings
( "adb shell pm grant net.dinglisch.android.taskerm android.permission.WRITE_SECURE_SETTINGS" )
Cannon_Foddr said:
I assume you had to do something like Taskers command then to grant the secure settings
( "adb shell pm grant net.dinglisch.android.taskerm android.permission.WRITE_SECURE_SETTINGS" )
Click to expand...
Click to collapse
Automate is straight forward, there is a toggle for "modify system settings" needed for some tasks to run and one you run the ADB command, it's done