Can't disable apps with adb - General Questions and Answers

I'm writing a script in windows (batch) that stops, clears, uninstalls updates and disables bloatware..
When I use "adb shell pm disable <packageName>", it causes an error:
Error: java.lang.SecurityException: Permission Denial: attempt to change component state from pid=19900, uid=2000, package uid=10048
I know that using "su" makes the above command work, but this script is intended to work on non-rooted devices.. Is there any way to make this work?
---
If not, I have another idea: launch app info (in "settings" app) and navigate to the "disable" button using adb by emulating key presses.. It would manually+programatically disable apps..
Disadvantage is that I don't know any command to do that

Related

Superuser App - fix the su security hole on modified RC30 - source/apks included

Summary:
There have been a few threads about the root setuid su being a potential security hole on modified RC30 phones. We all want to have root on our phones, but we don't want malicious programs/people to take advantage of it.
To that end, I came up with the following program that fixes the security hole, and also allows you or any application to get root when authorized.
This program works with any application that may use su: no special code or support needs to be written. Just use su like normal from within both Java applications or a terminal.
To install, simply install the Superuser application on top of modified RC30 V1.2.
If Superuser does not install properly automatically, do the following to install it manually:
Make sure you have the adb tool from the SDK.
Unzip the ZIP file (it will create a folder called Superuser).
Run install.bat (or install.sh if you are on Linux) from the Superuser directory.
Here's the script that the install runs:
Code:
adb push bin/su /system/bin
adb shell chmod 4755 /system/bin/su
adb uninstall koushikdutta.superuser
adb install bin/Superuser.apk
How it works:
The modified su command looks in a whitelist database for uids that is allowed root access. That database is only accessible by the Superuser application and root.
If a database entry is found, it decrements the white list counter by one (so, an application can access su 10 times, 1 time, etc, depending on the count).
If no database entry is found, it will show the Superuser confirmation activity and wait for 10 seconds for the user to respond. If the user presses yes or always, it adds the user id to the white list. (If yes is pressed, the white list counter is just 1).
If access was granted, su will setgid/setuid and call /system/bin/sh.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Implementation:
The Superuser Java application was written by me.
su was based on the su implementation built by Google for the Android platform. http://android.git.kernel.org/?p=pl...eb00e56211962786ff89d0e7940f73d7e914e;hb=HEAD
Source code and binaries are attached to this post.
[*]The standard RC30 install will have a setuid /system/bin/su. (if you deleted disabled it, reenable it for setup)
Click to expand...
Click to collapse
v1.2 and up only, correct? Not the setuid sh of v1.1.
jashsu said:
v1.2 and up only, correct? Not the setuid sh of v1.1.
Click to expand...
Click to collapse
Edit: Yeah, you need a setuid su in /system/bin. Having a setuid sh won't work.
?
Can't root just be blocked from the handset..? So the only root access would b from adb..doesn't that make the phone safe? Or is this the only real answer to the security issue?
cookzitall said:
Can't root just be blocked from the handset..? So the only root access would b from adb..doesn't that make the phone safe? Or is this the only real answer to the security issue?
Click to expand...
Click to collapse
Yup, of course you can delete the su command from the handset so you can only adb shell for root.
However, then legitimate uses of having root on your handset would not be possible:
For example, I am currently working integrating the G1 WiFi router instructions sticked in this forum into the Android WiFi settings application.
I did this and now everything is working fine, however I was wondering how another application can have root access other than the shell program you created.
Great work by the way!
persiansown said:
I did this and now everything is working fine, however I was wondering how another application can have root access other than the shell program you created.
Great work by the way!
Click to expand...
Click to collapse
They can use the Intent that is exposed by Superuser, that Shell uses to get root:
Code:
final int SUPERUSER_REQUEST = 2323; // arbitrary number of your choosing
Intent intent = new Intent("android.intent.action.superuser"); // superuser request
intent.putExtra("name", "Shell"); // tell Superuser the name of the requesting app
intent.putExtra("packagename", "koushikdutta.shell"); // tel Superuser the name of the requesting package
startActivityForResult(intent, SUPERUSER_REQUEST); // make the request!
Then, if the user presses Yes or Always, that Java application can call su just like normal:
Code:
Runtime.getRuntime().exec("su -c <your privileged command here>");
Otherwise, that command will fail.
Koush said:
They can use the Intent that is exposed by Superuser, that Shell uses to get root:
Code:
final int SUPERUSER_REQUEST = 2323; // arbitrary number of your choosing
Intent intent = new Intent("android.intent.action.superuser"); // superuser request
intent.putExtra("name", "Shell"); // tell Superuser the name of the requesting app
intent.putExtra("packagename", "koushikdutta.shell"); // tel Superuser the name of the requesting package
startActivityForResult(intent, SUPERUSER_REQUEST); // make the request!
Then, if the user presses Yes or Always, that Java application can call su just like normal:
Code:
Runtime.getRuntime().exec("su -c <your privileged command here>");
Otherwise, that command will fail.
Click to expand...
Click to collapse
Sounds good. Great job. Hopefully apps that require root in the future use this method rather than trying to force it.
Hi Koush,
I have Jf's modified RC30 but I am not that tech savy. Before I could access su in terminal emulator but now i am locked out. I downloaded both your apps off the mark but when I request superuser I get an error. Also terminal emulator now doesn't work when i enter in su. I think that was the point though.
However the error message on shell when i request superuser says;
error: permission denied: starting intent {action= android... and so on....
What should i do to get root back?
PLease advise.
Thank you,
hbguy
question
i change the "su" to a different word...thinking it wouold help with security a little while back..does that effect your program?
hey can anyone tell me what empty whitelist means?
I am having the same issue. I cannot execute su from terminal, permission denied. and when i try to get su access with the new shell program i get and error with "android.permission.ACCESS_SUPERUSER.
now my root job is all for nothing and im wondering how to get it back to normal.
Do i have to reflash from the backup image?
Check to make sure you have the latest version of the RC30 mod (1.2). If not. copy the update to your SD and install the new update. Then superuser and shell will work just fine and you will have root.
Leeah said:
Check to make sure you have the latest version of the RC30 mod (1.2). If not. copy the update to your SD and install the new update. Then superuser and shell will work just fine and you will have root.
Click to expand...
Click to collapse
Yes, don't worry: it is not possible to "lose" root with Superuser. You can always adb shell in for root; and if worst comes to worst (and it shouldn't), you can reflash.
I am updated to Jesusfreke's newest modified version 1.2 but I still get the same error when i request superuser off of shell ( i also remembered to run superuser before requesting access in shell too). I just re-flashed ( i think that's what its called) JF's modified and now I can run root on terminal emulator again if DONKEY still trying to figure out how to get it back.
I'd like to use superuser and shell but I think I'm missing something lol.
Sorry, clearly a noob here.
I think what we need is a combination of fnord's and koush's approach .
I'm thinking something along the lines of a sudo type program. Let's call it asudo (android sudo). Basically, there would be a sqlite database that contains a "white list" of user ids (java applications) that are allowed root access. This could potentially be time limited, or even "use" limited (i.e. a single use permission).
So when asudo is executed, it checks the database for the calling user id, and if it is allowed access to root, it would automatically run the specified command with root access. Otherwise, if the calling user id doesn't have explicit permission, it would prompt for a global password (which only the real person using the phone should know). The password would also be stored in the same sqlite database.
The same type of java based permissions scheme as Koush's could be implemented. When an application requests root access, it would pop up a notification screen similiar to what it shows now, with options something like - "allow access once", "allow access for 10 min", or "always allow access". And "don't allow access" of course. It would write a corresponding "allow" entry into the database based on what the user selected, and then the requesting application could execute asudo.
Thoughts?
Anyone wanna take this on? If not, I may have to do it myself
JesusFreke said:
I think what we need is a combination of fnord's and koush's approach .
I'm thinking something along the lines of a sudo type program. Let's call it asudo (android sudo). Basically, there would be a sqlite database that contains a "white list" of user ids (java applications) that are allowed root access. This could potentially be time limited, or even "use" limited (i.e. a single use permission).
So when asudo is executed, it checks the database for the calling user id, and if it is allowed access to root, it would automatically run the specified command with root access. Otherwise, if the calling user id doesn't have explicit permission, it would prompt for a global password (which only the real person using the phone should know). The password would also be stored in the same sqlite database.
The same type of java based permissions scheme as Koush's could be implemented. When an application requests root access, it would pop up a notification screen similiar to what it shows now, with options something like - "allow access once", "allow access for 10 min", or "always allow access". And "don't allow access" of course. It would write a corresponding "allow" entry into the database based on what the user selected, and then the requesting application could execute asudo.
Thoughts?
Anyone wanna take this on? If not, I may have to do it myself
Click to expand...
Click to collapse
IMO, su should act like normal su in every respect from a scripting perspective. IE, it never prompts for password on stdin. Piping in passwords from Runtime.exec is sort of kludgy. Also, if you start start prompting for passwords on su, you open a whole can of worms moving forward: some su's on people's phones will require passwords on stdin, while others won't.
That is my primary aversion to fnord's implementation; it makes development a pain, and future compatibility scary.
I think one way to do what you are suggesting is to implement a su.jar, and have a /system/bin/su script that launches that jar file. That su.jar can then redirect the stdin/stout to /system/bin/realsu (which is the vanilla RC30 v1.2 su). su.jar can interact with the Android application layer (which realsu can not do) and prompt for a password, ask for confirmation, or check the whitelist in the Android UI.
This way, su behaves exactly as it should from an implementation standpoint, inside a console. Thoughts?
Edit:
Or conversely, you can modify a normal su to block on a call to an Android Activity that asks for user confirmation. That's actually probably the better way to do it: avoid the Java code unless absolutely necessary.
I think one way to do what you are suggesting is to implement a su.jar, and have a /system/bin/su script that launches that jar file. That su.jar can then redirect the stdin/stout to /system/bin/realsu (which is the vanilla RC30 v1.2 su). su.jar can interact with the Android application layer (which realsu can not do) and prompt for a password, ask for confirmation, or check the whitelist in the Android UI.
This way, su behaves exactly as it should from an implementation standpoint, inside a console. Thoughts?
Click to expand...
Click to collapse
Having a su script launch the jar file is more or less just the same as the requesting application launch the jar directly, I think. In any case, the difference would only be relevant for Android apps that use su. Given the relatively small number of apps that will fall into that category, it begs the question whether it is really necessary to implement Android su so perfectly transparent. I also wonder if the fully open Android implementations (e.g. Android on Freerunner) will have a su command and if so what their security implementation will be like.
Also, if you start start prompting for passwords on su, you open a whole can of worms moving forward: some su's on people's phones will require passwords on stdin, while others won't.
Click to expand...
Click to collapse
Coming together and getting a de facto standard solution in place (and possibly pre-installed in JF's update packages) can't hurt.
jashsu said:
Having a su script launch the jar file is more or less just the same as the requesting application launch the jar directly, I think. So the only benefit would be for Android apps that specifically use su. Given the relatively small number of apps that will fall into that category, it begs the question whether it is really necessary to implement Android su so perfectly transparent. I also wonder if the fully open Android implementations (e.g. Android on Freerunner) will have a su command and if so what their security implementation will be like.
Coming together and getting a de facto standard solution in place (and possibly pre-installed in JF's update packages) can't hurt.
Click to expand...
Click to collapse
Yeah, I admit the su script isn't ideal. Which is why I edited my post and suggested that su block on an Android Activity (the other way around) when necessary.
Off the top of my head, there are several applications that I am working on or have planned that will require su:
Fully configurable WiFi Router UI (that basically automates the instructions found in the sticky in this forum)
Screenshot Application
Auto Screen Rotation
And there will be even more applications that will require su as we move forward: and they won't just be reduxes of a console/shell, where it is reasonable to prompt for a password on stdin. So for that reason, I want the su implementation to be as transparent as possible, so future usage from Java applications isn't a pain in the ass.
Jf, you are the man! and yes i am making sure that this message is over the required character and it is indeed a message with a profound meaning...
hbguy

[APP][2.2+] Remote ADB Shell

Overview
Remote ADB Shell is a simple terminal app that allows you to connect to the ADB shell service of another Android device over the network. This works in the exact same way that the "adb shell" command works on a computer. Because this app uses a native implementation of the ADB protocol in Java, it does not require root on either device or any 3rd party apps on the target device. The devices simply speak the same protocol to each other that they would to a computer running the ADB client from the Android SDK.
Features
Command history (accessible by long pressing the command box)
Send Ctrl+C (accessible by long pressing the terminal view)
Auto-scroll (with toggle accessible by long pressing the terminal view)
Screenshots
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Instructions
IMPORTANT: Android 4.2.2+ devices use RSA keys to authenticate the ADB connection. These devices will need to be plugged in to a computer the first time you connect to them (from each device with this app installed). This allows them to display the public key acceptance dialog, which you must accept (and check "Always allow from this computer").
To configure a stock un-rooted target, plug the target device into a computer and run "adb tcpip 5555". This will start ADB listening on port 5555 on the target device. The device can then be unplugged and will remain configured properly until reboot.
For devices that are rooted (although it's not required), you can install one of the several "ADB WiFi" apps to enable the ADB server to listen over the network. Devices with a custom ROM may have an option to enable ADB over the network in the Developer Options pane of Settings. Using either of these methods will properly configure ADB for network access with this app. The extra step for 4.2.2+ is still required for the initial connection.
To connect to your remote Android device, type in the IP address of the device and the port number (5555 from the example above) in Remote ADB Shell. Tap Connect and it will attempt to connect to the device and start up the terminal.
Notes
This app is unique because it runs a custom ADB implementation that I wrote from scratch in Java. I plan to open-source my ADB implementation on GitHub or Google Code once I give it a bit of cleanup and documentation. Using this custom ADB implementation means that I don't require an ADB binary or root on the device running the app. Because it speaks standard ADB, it doesn't require anything special on the target either.
Please post feature requests or suggestions here and I'll do my best to work on them.
Download
The app is available on Google Play for free. https://play.google.com/store/apps/details?id=com.cgutman.androidremotedebugger
Hi, cgutman - I actually have a feature request.
But first, let me say thank you for providing this featureset in an app I already have gotten a fair amount of use out of it.
Backstory:
I use adb shell commands to automate repetitive processes on a Fire TV (Android Settop Box, connected to a TV, runs apps), like launching certain apps, performing certain actions - and so on.
I actually have about 20 actions across multiple Applescript apps on the Mac that allow me to remote controll apps like Spotify or Pandora - and your app allows me to do that from an Android device (smartphone) as well.
That said - I run into two major speedbumps.
Without a "Bookmarks" feature (store a certain shell script, give it a name, be able to edit it, execute it on click), so far I can only effectively cycle through two scripts (using the "recent history" feature in your app) - and I'd like to be able to use 20+ scripts eventually. A bookmark list (sorted by name) would be great for my purpose.
Second - to really be able to speed up the use of those items a launcher shortcut feature would be great. It could look up and reference the bookmark entries from the suggestion above - or let you set an IP and enter a command in the shortcut dialogue (Terminal Emulator does it that way). Maybe even with an auto exit option (although "&& exit" works just as well right now (*yay*) - but people would have to know to use it). Also it should allow you to name the shortcut, before creating it.
The reason why this would be great is to reduce steps. Right now I have to open the app, connect to the remote Android device, longpress on the command line entry field, select a history item, press enter - press OK once the app has finished the script, then exit the app.
It would be great to be able to automate all of this down to one launcher shortcut click.
To give you an Idea - what I am using the app for currently - here is one of the scripts I wrote today:
Code:
monkey -p com.netease.cloudmusic 1 && sleep 5 && input tap 960 978 && sleep 0.8 && input keyevent 19 && input keyevent 19 && input keyevent 19 && sleep 0.3 && input keyevent 20 && input keyevent 20 && input keyevent 20 && sleep 0.3 && input tap 50 960 && sleep 0.8 && exit
This opens the netease app and starts the "daily recommended" playlist.
Code:
input tap 60 100 && sleep 0.8 && input tap 60 100 && sleep 0.8 && input tap 60 100 && sleep 0.8 && input tap 1444 1030 && sleep 0.8 && exit
This exits the app cleanly - and so on...
Again - I've set up dozens of scripts like that on my Mac to be able to navigate Pandora, and spotify - to pull files, make screenshots, and so on and so forth. If you could implement said features (again - Terminal Emulator has them.. ) - your app would allow me to realize the same functionality on my smartphone.
Thank you for reading through my posting and contemplating the idea -
so long
h.
edit: Also thank you for already exiting the session cleanly (adb disconnect) once you type in exit. The Fire TV only allows one adb session at a time, so this is great.
Found a way to make the app a little more usable "as is" for my purposes in the meantime. Part of my problem was, that the shell scripts turned out quite complex - so I couldnt run several of them - because they weren't instantly recognizable on the run history level.
The temporary workaround for me was to move the commands as shell scripts to a folder (I named "shell") in /system on the target device and make them executable. That way the history in Remote ADB Shell stays cleaner and is better parseable by humans.
This is what it looks like now:
http://i.imgur.com/AuGFZ0a.png
Just right. Thank you.
Love this app! However I would like to ask if it were possible to send adb commands from outside the app using apps like Tasker. This could already simply be done by sending your app and intent with the ip, port and command.
I just created a Tasker Plugin myself using the AdbLib library! Have a look if you like https://play.google.com/store/apps/details?id=com.ADBPlugin
Trying to connect to my phone but I am not getting device authorization messages.
Great application, thank you.
My task:
- - the device has no Root
- in the directory / tmp there is a binary file su and SuperSU.apк for this device
- How to launch an "adb root shell tcpip:5555" using your application on the this device?
may be:?
1) adb tcpip:5555
2) adb root
3) adb tcpip:5555
4) adb remount
5) "adb shell"
6) or without "adb shell" -> adb pull ... adb pushh... adb reboot...
This is possible?
Or is this impossible in principle?
I'm having trouble installing apk's with this. The normal command that I use on Windows doesn't seem to work...
Could it be having trouble finding the file on my phone while trying to send it to my fire stick?
Kranium31 said:
I'm having trouble installing apk's with this. The normal command that I use on Windows doesn't seem to work...
Could it be having trouble finding the file on my phone while trying to send it to my fire stick?
Click to expand...
Click to collapse
You can't, it's just "adb shell" commands (where you leave out the adb shell part), not "adb install" for instance.
---------- Post added at 12:23 AM ---------- Previous post was at 12:20 AM ----------
AS2107 said:
Great application, thank you.
My task:
- - the device has no Root
- in the directory / tmp there is a binary file su and SuperSU.apк for this device
- How to launch an "adb root shell tcpip:5555" using your application on the this device?
may be:?
1) adb tcpip:5555
2) adb root
3) adb tcpip:5555
4) adb remount
5) "adb shell"
6) or without "adb shell" -> adb pull ... adb pushh... adb reboot...
This is possible?
Or is this impossible in principle?
Click to expand...
Click to collapse
The app only connects via "adb shell", so only those commands are possible, so no "adb install", "adb tcpip" or whatever. It's like typing "adb shell" on a PC and then you're able to give direct commands to the phone like moving a file with "mv /sdcard/Download/file /sdcard"
Hello I am having an issue
I want to use the adb on my own device (meaning only one device is being used)
I am able to connect the adb shell but whenever I try to type the following command it gives the error adb not found
adb shell sh /sdcard/.chaozhuo.gameassistan2/inject.sh
If anyone knows what the issue is Plz help
Thanks in advance
I just bought a 2019 Nvidia Pro. I installed your Wolf Launch and was attempting to install a widget. A prompt appears and states my device doesn't support a widget and have to run an ADB shell. Troypoint has an app for a remote adb shell as so do others, but I cannot find one for a nvidia.
In the widget binding failure the code it is telling me to type is, appwidget grantbind --package com.wolf.firelauncher --user 0
I was all set to do this but the firelauncher gave me pause. The device I am attempting this on isa 2019 Nvidia Pro v.9.0.1 + hotfix 1
need confirmation this is the correct code for my device.
Thanks,

[SECURITY] Multiple Android Superuser vulnerabilities

Well, I was going to hold off until all of the vendors had new releases posted, but now that the cat is out of the bag and the evildoers have sufficient information to figure out what got fixed:
[size=+1]Current Superuser/SuperSU releases have security holes that allow any application to execute commands as root without the user's permission (even apps with no permissions). Please upgrade immediately to SuperSU >= v1.69 or another patched release.[/size]
This is expected to impact the vast majority of rooted devices and custom ROMs.
Details follow:
[size=+2]Superuser unsanitized environment vulnerability on Android <= 4.2.x[/size]
Vulnerable releases of several common Android Superuser packages may allow malicious Android applications to execute arbitrary commands as root without notifying the device owner:
ChainsDD Superuser (current releases, including v3.1.3)
CyanogenMod/ClockWorkMod/Koush Superuser (current releases, including v1.0.2.1)
Chainfire SuperSU prior to v1.69
The majority of third-party ROMs include one of these packages.
On a rooted Android <= 4.2.x device, /system/xbin/su is a setuid root binary which performs a number of privilege checks in order to determine whether the operation requested by the caller should be allowed. In the course of its normal duties, and prior to making the allow/deny decision, /system/xbin/su invokes external programs under a privileged UID, typically root (0) or system (1000):
/system/bin/log, to record activity to logcat
/system/bin/am, to send intents to the Superuser Java app
/system/bin/sh, to execute the /system/bin/am wrapper script
/system/bin/app_process, the Dalvik VM
The user who invokes /system/xbin/su may have the ability to manipulate the environment variables, file descriptors, signals, rlimits, tty/stdin/stdout/stderr, and possibly other items belonging to any of these subprocesses. At least two vulnerabilities are readily apparent:
- On ClockWorkMod Superuser, /system/xbin/su does not set PATH to a known-good value, so a malicious user could trick /system/bin/am into using a trojaned app_process binary:
Code:
echo -e '#!/system/bin/sh\nexport PATH=/system/bin:$PATH\ntouch /data/trojan.out\nexec $0 "[email protected]"' > app_process ; chmod 755 app_process
PATH=`pwd`:$PATH su -c 'true'
The PATH vulnerability is being tracked under CVE-2013-6768.
- Other environment variables could be used to affect the behavior of the (moderately complex) subprocesses. For instance, manipulation of BOOTCLASSPATH could cause a malicious .jar file to be loaded into the privileged Dalvik VM instance. All three Superuser implementations allowed Dalvik's BOOTCLASSPATH to be supplied by the attacker.
The BOOTCLASSPATH vulnerability is being tracked under CVE-2013-6774.
[size=+2]Android Superuser shell character escape vulnerability[/size]
Vulnerable releases of two common Android Superuser packages may allow malicious Android applications to execute arbitrary commands as root, either without prompting the user or after the user has denied the request:
CyanogenMod/ClockWorkMod/Koush Superuser (current releases, including v1.0.2.1)
Chainfire SuperSU prior to v1.69
The majority of recent third-party ROMs include one of these packages. Older ROMs may use the ChainsDD Superuser package, which is not affected but is no longer maintained.
On a rooted Android <= 4.2.x device, /system/xbin/su is a setuid root binary which performs a number of privilege checks in order to determine whether the operation requested by the caller should be allowed. If any of these checks fail, the denial is recorded by broadcasting an intent to the Superuser app through the Android Activity Manager binary, /system/bin/am. /system/bin/am is invoked as root, and user-supplied arguments to the "su" command can be included on the "am" command line.
On a rooted Android >= 4.3 device, due to changes in Android's security model, /system/xbin/su functions as an unprivileged client which connects to a "su daemon" started early in the boot process. The client passes the request over a UNIX socket, and the daemon reads the caller's credentials using SO_PEERCRED. As described above, /system/bin/am is called (now from the daemon) to communicate with the app that implements the user interface.
If the user invokes "su -c 'COMMAND'" and the request is denied (or approved), ClockWorkMod Superuser constructs a command line to pass to a root shell:
Code:
snprintf(user_result_command, sizeof(user_result_command), "exec /system/bin/am " ACTION_RESULT " --ei binary_version %d --es from_name '%s' --es desired_name '%s' --ei uid %d --ei desired_uid %d --es command '%s' --es action %s --user %d",
VERSION_CODE,
ctx->from.name, ctx->to.name,
ctx->from.uid, ctx->to.uid, get_command(&ctx->to),
policy == ALLOW ? "allow" : "deny", ctx->user.android_user_id);
get_command() would return "COMMAND", unescaped, through "/system/bin/sh -c". By adding shell metacharacters to the command, the root subshell can be tricked into running arbitrary command lines as root:
Code:
su -c "'&touch /data/abc;'"
Upon denial by the operator, "touch /data/abc" will be executed with root privileges. The Superuser variant of this problem is being tracked under CVE-2013-6769.
SuperSU prior to v1.69 removes quote and backslash characters from the string passed to /system/bin/sh, but backticks or $() can be used instead for the same effect:
Code:
su -c '`touch /data/abc`'
su -c '$(touch /data/abc)'
The SuperSU variant of this problem is being tracked under CVE-2013-6775.
ChainsDD Superuser v3.1.3 does not appear to pass the user-supplied input on the /system/bin/am command line.
[size=+2]Superuser "su --daemon" vulnerability on Android >= 4.3[/size]
Current releases of the CyanogenMod/ClockWorkMod/Koush Superuser package may allow restricted local users to execute arbitrary commands as root in certain, non-default device configurations.
Android 4.3 introduced the concept of "restricted profiles," created through the Settings -> Users menu. A restricted profile can be configured to allow access to only a minimal set of applications, and has extremely limited abilities to change settings on the device. This is often used to enforce parental controls, or to protect shared devices set up in public places. The OS requires an unlock code to be entered in order to access the owner's profile to administer the system.
/system/xbin/su is a setuid root executable, and any user may invoke it in client mode ("su -c 'foo'" or just "su"), or in daemon mode ("su --daemon"). In either mode of operation, the user who invokes this program has the ability to manipulate its environment variables, file descriptors, signals, rlimits, tty/stdin/stdout/stderr, and possibly other items. By adding new entries at the front of the PATH for commonly-executed root commands, then re-invoking "su --daemon", an attacker may be able to hijack legitimate root sessions subsequently started by other applications on the device.
"su --daemon" is normally started up very early in the boot process, as root, from /init.superuser.rc (CM) or from /system/etc/install-recovery.sh (other ROMs). The fact that unprivileged users are allowed to restart the daemon later, under EUID 0, appears to be an oversight.
Successful exploitation requires a number of conditions to be met:
- The attacker must have ADB shell access, e.g. over USB. This is disabled by default, and normally restricted to trusted ADB clients whose RSA key fingerprints have been accepted by the device administrator. Root access via ADB (i.e. Settings -> Developer Options -> Root access -> Apps and ADB) is not required. Note that ADB shell access is typically considered a security risk, even in the absence of this problem.
- The attacker must have a way to assume a non-shell (non-2000), suid-capable Linux UID in order to prevent /system/xbin/su from creating infinitely recursive connections to itself through the daemon client UID check in main(). One way to do this would involve uploading an app with the "debuggable" flag and using /system/bin/run-as to assume this UID. "adb install" can probably used for this purpose. However, due to a bug in Android 4.3's "run-as" implementation[1], this does not currently work. This bug was fixed in Android 4.4, so CM11 will probably be able to satisfy this requirement.
- The device owner must have granted root permissions to one or more applications via Superuser. The restricted profile does not need to be able to run this app from the launcher.
Sample exploit:
The restricted local user can reboot the tablet, run "adb shell" when the boot animation shows up, then invoke the following commands:
Code:
echo -e '#!/system/bin/sh\nexport PATH=/system/bin:$PATH\ntouch /data/trojan.out\nexec $0 "[email protected]"' > /data/local/tmp/trojan
chmod 755 /data/local/tmp/trojan
for x in id ls cp cat touch chmod chown iptables dmesg; do ln -s trojan /data/local/tmp/$x ; done
PATH=/data/local/tmp:$PATH setsid run-as.422 my.debuggable.package /system/xbin/su --daemon &
(Note the use of "run-as.422" as a proxy for a working Android 4.3 run-as binary, and the installation of "my.debuggable.package" with the debuggable flag set.)
At this point the USB cable may be disconnected.
The next time a root application successfully passes the Superuser check and invokes one of the trojaned shell commands, /data/local/tmp/trojan will be executed under UID 0.
An ideal candidate for exploitation is a package which runs privileged commands on boot, e.g. AdBlock Plus or AFWall+, as this allows for instant access. Another possibility is to hijack an app which the device's operator runs frequently, such as Titanium Backup.
Note that this can NOT be exploited by malicious applications, as zygote-spawned processes (apps) always access /system in nosuid mode[2] on Android 4.3+. The ADB shell was used as the attack vector as it is not subject to this restriction.
ChainsDD Superuser v3.1.3 does not have an Android 4.3+ client/server mode at all, and SuperSU aborts if an existing "daemonsu" instance is already bound to the abstract @"eu.chainfire.supersu" socket.
Proposed resolution: on Android 4.3 and higher, install all Superuser-related binaries with mode 0755 (setuid bit unset).
This problem is being tracked under CVE-2013-6770.
[1] https://code.google.com/p/android/issues/detail?id=58373
[2] http://source.android.com/devices/tech/security/enhancements43.html
Did you report that to @Chainfire?
SecUpwN said:
Did you report that to @Chainfire?
Click to expand...
Click to collapse
Yes, he's been very responsive.
I contacted all three developers last Saturday, and posted the advisory after there was enough public information available to deduce what the problems were.
In case you're curious, there's been some additional discussion about exploiting ChainsDD Superuser on BUGTRAQ.
Is there a way we can patch this maybe using xposed framework
milojoseph said:
Is there a way we can patch this
Click to expand...
Click to collapse
There are new releases of SuperSU and CWM Superuser posted:
https://play.google.com/store/apps/details?id=eu.chainfire.supersu&hl=en
http://forum.xda-developers.com/showthread.php?t=1538053
https://play.google.com/store/apps/details?id=com.koushikdutta.superuser&hl=en
I haven't seen any updates to ChainsDD Superuser, and AFAICT the project is no longer maintained.
maybe using xposed framework
Click to expand...
Click to collapse
Xposed is useful for patching Java programs, but /system/xbin/su is compiled C code. So the techniques used by Xposed would not apply to this case.
cernekee said:
Xposed is useful for patching Java programs, but /system/xbin/su is compiled C code. So the techniques used by Xposed would not apply to this case.
Click to expand...
Click to collapse
There's always Substrate, that can be used even for patching native code, but still in this case not applicable I guess.
Where you able to find any patch to fix them?
thank you for sharing ...
I am getting this message in lollipop "zygote has been granted superuser permission" i accidentally allowed it root access thinking it was link2sd. Could it be malware? There is a nameless app in my supersu under name "zygote". i didn't installed anything outside from playstore. My supersu version is 2.78
diabolicalprophecy said:
I am getting this message in lollipop "zygote has been granted superuser permission" i accidentally allowed it root access thinking it was link2sd. Could it be malware? There is a nameless app in my supersu under name "zygote". i didn't installed anything outside from playstore. My supersu version is 2.78
Click to expand...
Click to collapse
Did you get an answer for this? I have the same issue on 4.4.4
Vankog said:
Did you get an answer for this? I have the same issue on 4.4.4
Click to expand...
Click to collapse
No I didn't, I reflashed the rom and it solved the problem.

[Q] What is the "Package Manager"? And why is it not running on my phone?

I've tried to use a couple apps to disable certain services on my phone - but they have not worked. (I have tried DisableService and MyAndroidTools)
When I try to use those apps, the SuperSU log gives the following output:
Code:
pm disable com.google.android.gms/com.google.android.gms.wearable.service.WearableService
exit
Error: Could not access the Package Manager. Is the system running?
I'm still trying to figure out what the "Package Manager" is, and why it seems to be missing/not running on my device.
Is the Package Manager part of the ROM, or the kernel, or what?
For reference, I have an AT&T SGS4, running a custom Lollipop ROM (GoldenEye53)
Thanks!
sac02 said:
I've tried to use a couple apps to disable certain services on my phone - but they have not worked.
When I try to use those apps, the SuperSU log gives the following output:
Code:
pm disable com.google.android.gms/com.google.android.gms.wearable.service.WearableService
exit
Error: Could not access the Package Manager. Is the system running?
I'm still trying to figure out what the "Package Manager" is, and why it seems to be missing/not running on my device.
Is the Package Manager part of the ROM, or the kernel, or what?
For reference, I have an AT&T SGS4, running a custom Lollipop ROM (GoldenEye53)
Thanks!
Click to expand...
Click to collapse
Package Manager it is the service which can install an apk on your phone (it's like an apk reader if you know what i mean)
but about the error i don't know why this message come to you ...but don't try to stop necessary services !!it could brick your ROM my friend
Hmm, so if I can install an apk (I definitely can) then that should be evidence that I have functioning Package Manager?
So I wonder what the issue is with these apps... or my phone...
Also, I am going to be very very careful with disabling services. I only plan to disable services that are:
1. Affecting my phone negatively (waking and looking for wearable devices that I do not use would be an example), and
2. Are confirmed OK to disable based on research. I will not disable anything I am not certain is safe.
Thanks for your help.
I've got the same setup as you with the phone, rom, app, and error message. I haven't figured out what the problem is yet.
Sent from my SGH-I337 using Tapatalk
I know you said you tried a couple apps, but maybe try using the Xposed module Amplify? That is, if you have the Xposed Framework installed.
Try killing system_server first then run your command. It might work. Here's how to do
Code:
su -c pkill system_server
It will fast-reboot your phone, Then run your command
samsungrockz said:
Try killing system_server first then run your command. It might work. Here's how to do
Code:
su -c pkill system_server
It will fast-reboot your phone, Then run your command
Click to expand...
Click to collapse
It doesn't recognize this command
Code:
[email protected]:/ # su -c pkill system_server
tmp-mksh: pkill: not found
If I try kill it requires process number, not name
Code:
127|[email protected]:/ # kill system_server
tmp-mksh: kill: system_server: arguments must be jobs or process IDs
Suncatcher16 said:
It doesn't recognize this command
Code:
[email protected]:/ # su -c pkill system_server
tmp-mksh: pkill: not found
If I try kill it requires process number, not name
Code:
127|[email protected]:/ # kill system_server
tmp-mksh: kill: system_server: arguments must be jobs or process IDs
Click to expand...
Click to collapse
kill doesn't take process names, it takes process IDs
simply use
Code:
su
ps|grep system_server
you will see the system_server process with an ID, 3 to 5 digit numbers like 16458
then "kill 16458"
and pkill isn't recognized probably because of busybox (installs bunch of useful command tools on your system), install an busybox installer from playstore, install busybox then try again.
samsungrockz said:
kill doesn't take process names, it takes process IDs
simply use
Code:
su
ps|grep system_server
you will see the system_server process with an ID, 3 to 5 digit numbers like 16458
then "kill 16458"
and pkill isn't recognized probably because of busybox (installs bunch of useful command tools on your system), install an busybox installer from playstore, install busybox then try again.
Click to expand...
Click to collapse
No, I have bysybox. Maybe this command exists only in Pro-version?
Nevertheless, I already solved the problem by rerooting with another su binary.
Suncatcher16 said:
No, I have bysybox. Maybe this command exists only in Pro-version?
Nevertheless, I already solved the problem by rerooting with another su binary.
Click to expand...
Click to collapse
good to hear that

[Vulnerability] Bluestacks root access via adb

On GitHub: https://github.com/KDVB/BlueStacks-ADB-root-access​​Disclaimer​For informational purposes only. The author does not call for further actions. Created to warn users who use this product
Background​ADB (Android Debug Brigde) - is a versatile command-line tool that lets you communicate with a device. The adb command facilitates a variety of device actions, such as installing and debugging apps. adb provides access to a Unix shell that you can use to run a variety of commands on a device.
Research Walkthrough​For default, in Bluestacks, ADB port is open, but we can't to use shell command (output "error: closed")
Searching for information in the emulator files found the following file ".adbcmd" in Root.vnhd image. Path to file "dataFS\downloads". In this file we can see adb commands that we can run without connection to shell
For example, "getprop" command, that gives us information about android propetries
As we can see, interaction with android shell is working. So, I think "if I can interact with unix shell, maybe tryed to use pipe operators" and pwn i can interact with file system, but with shell-user privilage.
As a result i continue my search to find su command to get root access. SU file is in "/boot/android/android/system/xbin/bstk/su". I tryed pipe operator to get root access, but get error and shell didn't open(
After that i tryed list terminator ";" and it works. I get root shell
Result​Bluestacks have this vulnerability and people involved in its development know about it and are engaged in its elimination.
The real test is to see if you can actually do anything. Sure, you've ID'd as root, but will it actually let you change anything?
V0latyle said:
The real test is to see if you can actually do anything. Sure, you've ID'd as root, but will it actually let you change anything?
Click to expand...
Click to collapse
Thanks for your reply. Actually you can change in current session, but when emulator reboot, all changes remove. If we speak about system folders. In sdcard folders changes save. Sorry, I didn't mention it in the post.
When i searched information on the virtual disk, i found some scripts that build a system. That takes information from .conf files, but that works only for local work. For example, when you using OpenVPN Connect that port still open and you can interact with it.

Categories

Resources