Shared publicly  - 
 
Superuser on 4.3

I finally had a chance to dig into seeing why Superuser is broken on Android 4.3.

https://android.googlesource.com/platform/dalvik/+/9907ca3cb8982063a846426ad3bdf3f90e3b87c2

Basically /system is mounted as nosuid to any zygote spawned process (ie, all Android apps). Root will still continue to work via adb shell, etc.

This is a pretty nasty change. It seems that SuperSU works around this by replacing install-recovery.sh to run a su daemon that pipes subsequent through it. Pretty hacky, but understandable why it was done this way.

Will need to look into how to do this in a less invasive fashion, if that is even possible. Of course, if building from source, this change can simply be reverted.
Zygote: remount /system nosuid/nodev Android no longer has any setuid / setgid programs accessible to zygote. Make sure /system is remounted nosuid and nodev for zygote spawned processes. We use mount namespaces to make sure these changes are only visible to zygote spawned processes.
117
32
Mark Kennard's profile photoMark Lear's profile photoDominik Maier's profile photoHarsh Doshi's profile photo
39 comments
 
Wow interesting, wonder why they felt the need to change that.
 
4.3 or Superuser? What a pickle you've put me in +Koushik Dutta. I hope you find a non-hacky way around it soon.
 
Don't revert the change; that's crazy talk.

Implement it right.  Let the device admin (i.e. the user) grant su rights to apps that need it, exactly like a desktop unix admin grants su rights by uid.  Write some known-legit UI for administering su rights like this as part of Cyanogenmod or whatever, and off you go.
 
To clarify no su at all or just no persistent su.
 
+Tadej Rudec - This has zero effect on adb backup/restore and Helium.  None of the framework's backup/restore infrastructure ever runs as root.
 
"Non rooted phones don't need this, as apps couldn't get root anyway"

This is less true than you imagine.
 
+Christopher Tate Yeah, we'll be implementing "su" correctly of course. But ultimately we want to get rid of root altogether, by just exposing the necessary permissions in the framework to do whatever is needed.
 
So, essentially, what they did is made it 10x harder for a malicious app to root a device and screw with it.
Paul W.
+
1
2
1
 
This is the equivalent of killing an ant by dropping the sun on it. There are obviously people that want ROOT, but as per the Google PTB, they'll set the bar at the dumbest of users.

It wasn't unexpected however, at IO one of the panel did state they were working to remove some of the freedom and choices previously granted to users and apps. 
 
Actually I'm not in a position to be able to speak about specifics here.  Talk to one of the Android security guys if you want more background.
 
Does su have to exist in /system? What if the binary was on another partition that was mounted with suid?

BTW, your su app (as a whole) is awesome... loving it much more than any other su app.
 
What if you make one?... Can you make ram disks? If you can, make a tiny one, mount it and copy su over, run it and you have an uncle named Bob.
 
Conceptually, I like the idea of getting rid of the need for root and instead creating framework for root-level permissions.

In practice, though:
1). Won't work for stock devices at all, only source-based Roms
2). Doesn't really leave room for arbitrary execution. Typical root actions can be predicted, but some root apps run their own commands. Could be hard to actually affect change without losing basic functionality.
 
I can't believe that some people are actually complaining that Google fixed a major security leak. Or at least made it a little harder to exploit the system.
If you want root just buy a device with an open boot loader and maybe ultimately force the manufacturers to leave the boot loader unlocked by simply don't buying the ones with a looked boot loader. 
 
Preparing for the inevitable petition for Google to leave root alone
 
Well, if we want root we can still hack around this, either by building a ROM from source without these restrictions, or by hacking around them...

I think we are missing an opportunity here: since this is going to break a lot of root apps anyways, this is a great chance to change the root "API" which is kind of funky anyways.

The current root API is simply to run /system/xbin/su as a process, write commands to its stdin, and read results from stdout and stderr. Problem is flow control and IO separation suck, and also nosy apps can check if a device is rooted just by looking for a specific file.

Now that a daemon is necessary, why not get rid of the /system/xbin/su shim, and have root apps communicate directly with the daemon though another method. If the method is correctly chosen, an app should have no way to tell the difference between a non-rooted device, and one where root access was denied.
Paul W.
+
1
2
1
 
+Christopher Lee Well articulated but you're missing the point. Of course security holes should be patched. In reality we're talking about a tiny subset of users that utilise such a security hole for "good". The problem here isn't so much about patching security bugs, it's about losing the functionality that goes along with said bugs.

Smartphones aren't appliances, they're personal computer devices. What privileges I as the administrator of my device should want to grant to third party software should be up to me as the administrator. And in closing such security holes, knowing in exactly which way they're being leveraged if/when at all, there should be a professional responsibility to provide a saner more secure method.

When forums' software was being hacked on due to its open nature, developers saw fit to provide hooks and further foster the users and their desire to have their forums reflect their wills and individuality. There is a prime example of doing things the right way.

I recently saw an article whereby advertisers were attacking Mozilla because of their recent stance on third party cookies and that's because we the end user are the product, one of the pieces of functionality that's hindered by such a move on the part of Google is adblocking. Why shouldn't I be in charge of my privacy? To add to that, why shouldn't I be allowed to browse the root directory of my phone? Or run shell scripts to provide me simple functionality like reading a periodical synopsis of my calendar thanks to Tasker?

Plugging security holes is fine, but that should happen while providing the ability to legitimately control the device as the administrator requires. Not saying that 90% of our users don't need it and so screw the other 10%.
 
In a perfect world, the answer would be defining additional access levels within the system, so that you could have partial "root" access or full access if the app needs it. I suppose though, that this would fall under core functionality to ensure it's secure, which means it would have to be proposed to aosp... and something tells me that would be a very uphill battle.
 
+Christopher Lee Not really... I'll explain my take on this in simple words.. Security flaw or not, Root mode is more than just a way of computing for some of us, it's God mode, that we absolutely can not live without. 

to quote you: "Root as we know it really shouldn't have to be a part of using Android, because it's generally there to correct for a deficiency-- the lack of a user-controllable method of safely executing various commands and apps at the correct permission level. "

quite in contrast, root is indeed a part of using android, and that 10% of people are the actual android supporters/fighters/well wishers/promoters. It is because of this 10% that the other 90% ever came into the android world. Google can upset the 90%, who don't even really care unless they get basic functionality, but the 10% are the ones you really need to keep happy. We are, proudly, that 10%.

 And there will never be an official user-controllable method of granting root, that will void the concept of warranty.If a user has root access, then they can modify system files, and they can thus screw their own device, with no fault of Google or Samsung or lg. so the OEMs aren't responsible for it and wont give warranty support! 

Besides, we don't root to correct a deficiency, if that's what Google thinks, they are wrong. We root to get extra features, flashy fancy stuff, to do things simply cuz we can, and the things we do, we don't expect it to be standard in android. Some things in fact, we would hate to see in standard android. But we still wanna do it, cuz we are the power users, who like to have complete control over their devices. And these are nexus devices remember ? they are supposed to be developer friendly. ROOT IS the biggest developer driven sector, it enables even the normal user to understand how the phone works, that the whole spirit behind XDA. The whole HUGE XDA community is made on this basic principle, that root is good, it's great, and we love android for root, for the flexibility that no other OS in the world can have. 

As for security flaw, since Google has patched a way to get root, they should provide another sophisticated way. We need a way to have that same complete control, and there cant be an official way, cuz it'll void the concept of warranty, and anyone who cant read can grant root to an app to get a feature to his stock new shiny phone. THAT will raise security concerns. If there are people out there who willingly sacrifice warranty to get root, going through the pain of rooting, what's Google's problem ? Please, don't mess with root Google. We want root. We love android = We love root. 

P.S. sorry for the super long post, was in a frenzy, thanx for reading it fully if u did. :P I forgive you if u didn't. 
 
+Christopher Lee You seem to be conflating two separate things. No one is arguing against the importance of patching vulnerabilities used to gain root access. These vulnerabilities may frequently be exploited by malicious applications in order to escalate privileges and perform unauthorized actions on user devices.

However, that doesn't mean that the mere presence of the ability to legitimately gain administrative privileges on an Android device is itself a vulnerability. It's just not. If you need further convincing, I suggest you request a CVE identifier for every major non-mobile consumer operating system in existence. Windows users can gain administrative privileges by overriding UAC. Linux users can use sudo or su, provided they have authorization. The key here is that there needs to be a mechanism in place to prevent unauthorized code from leveraging root access to perform malicious actions, which every sane implementation of su/Superuser on Android has always had: prompts are presented to the user whenever an application requests root privileges.

That's not to say that granting administrative-type privileges at a finer granularity via exposing them through the Android framework wouldn't be better, or that having a rooted device doesn't present additional attack surface, but calling the existence of legitimate root access a vulnerability is an exaggeration.

This new feature implemented in Android 4.3, which remounts the /system partition with the NOSUID flag inside a private mount namespace for each Zygote-spawned process, creates an easily circumvented annoyance for having a setup that allows you to grant root privileges to authorized applications, while doing absolutely nothing to prevent exploitable vulnerabilities that allow malicious applications to gain unauthorized root access on the average consumer's device.
 
+Christopher Lee Sounds like we're in agreement and I need to work on my reading comprehension. To be fair, holy walls of text.
 
Root access isn't needed to run other roms, or use some of the mods people want.

Root access is required to perform some of the tasks required to set up most of those things, and that's it.

And, root access is only needed because the files are otherwise locked, to prevent rogue apps or other processes from breaking them.

I think that some people have a big misconception of what root even is... and to be honest, Linux has a rather barbarian permissions system which is what gave rise to selinux and the use of acl's.
 
+Christopher Lee I meant barbarian in the sense of useless and simplistic. You really can't do much with just rwx and ugo.
 
So if it's just related to how it mounts the partitions, I'm assuming people could make a kernel that removes the nosuid flag when mounting system and that sort of patches the issue? That could be the solution for stock devices.
 
+Mark Kennard I don't think that would work because, as far as I understand it, the change was made to the dalvik vm and not the kernel.  Any time the zygote is cloned it remounts the /system mount for that process with the flag set.  So you would need to swap out the dalvik vm to avoid this process.  I have never done or heard of anyone doing this, so I cannot say whether it can be done on a stock rom, but my guess is that it would not work well since we most likely don't have access to the original source.
 
Does it strike anyone else as odd that in the initZygote function that was modified for this change, it will bail out with a -1 and not do the remount if getMountsDevDir doesn’t return a path after reading the mounts?  The point that I find odd is that the function is intended to return a bool rather than an integer and I would suspect -1 to resolve to true.  This would ultimately allow the execution to continue in the calling function, as if the new code did not exist.

Though I find this odd I don’t see it as a viable exploit since one would have to gain access to the process’s “mounts” file and modify it in a way that would block the finding of the path, during the zygotes initialization flow.
 
They write about this change in the What's new Section of Android 4.3.
 
+Christopher Lee Alright, i thought you misunderstood me too. (reading ur other posts) I'm not saying that gaining root through exploits is right, i frankly was scared of exploits, imagine an app you install can gain temp root access and do all kinda nasty things to your system when u were actually on stock ROM and unrooted ! 

I misunderstood that you meant 'root' was bad and the main problem. Legitimate means of gaining root like unlocking bootloader, having been fairly warned beforehand, and then flashing a recover, etc. is the way to go, i think we both agree to that. But, yeah, root is necessary. 

And about how companies wouldn't care about that 10%, well, i must say, that wont be the case with google/android. Android itself solely exists on the basic principle of Open Source, and thus no mater what, those 10% should be the primary target, and they still are, and will always be, maybe they will increase the 10% to 20%. And they can always have a separate version of devices (like the nexus) or a separate operation model for the 10%. Like it is now ! Normally, on android, much like any other OS, you are locked down and restricted. No root access, no system access, you have to grant an app all the permissions it asks or none at all, and simply not install. (maybe App ops is changing that ?). HOWEVER, if you are a power user, and u need complete access, well, who's to stop you from doing what you want with your phone bought with your money ? By all means, go ahead, we'll just issue warning, and standard warnings that say that u loose warranty, you are solely responsible, yada yada yada...

But, there should only be one secure process and way to gain root, no other exploit should work, no malicious app should be able to gain low level access to anything. THATS how it should work, how it is even on the nexus devices. and after getting root, every time an app wants root, u must be asked for granting the permission, and they get root only if you allow them to, so it's all on you. A stupid person, by all means, should be warned. 
 
ahh. i'm not gonna argue any further. I get your point, and arguing further may vreate more misunderstandings.. but we can always bank upon google to do the right thing.. im not saying SELinux is bad, or that this new implementation of root is flawed (it is actually, for now, just makes root harder but still possible). They should just fix the exploits, which every manufacturer have done in the past and will keep doing.. 
Add a comment...