A bash exploit has been discovered that may give hope to rootless devices. In theory, install an apk with a vulnerable bash binary and run a script to gain root.
Keep an eye on this one
jocala said:
A bash exploit has been discovered that may give hope to rootless devices. In theory, install an apk with a vulnerable bash binary and run a script to gain root.
Keep an eye on this one
Click to expand...
Click to collapse
This has nothing to do with gaining root. The only way you gain root is by having a binary that already runs as root that has an exploit or finding an exploit in the kernel. Installing an apk with bash in it won't magically make bash run as root.
rbox said:
This has nothing to do with gaining root. The only way you gain root is by having a binary that already runs as root that has an exploit or finding an exploit in the kernel. Installing an apk with bash in it won't magically make bash run as root.
Click to expand...
Click to collapse
Sorry, you're mistaken. It has everything to do with gaining root, that's why this is marked as a urgent remote vulnerability. You exploit a bug in bash to gain a # prompt, at least in theory. It also applies to ssh.
Will it apply to the various android bash binaries? I have no idea.
jocala said:
Sorry, you're mistaken. It has everything to do with gaining root, that's why this is marked as a urgent remote vulnerability. You exploit a bug in bash to gain a # prompt, at least in theory. It also applies to ssh.
Will it apply to the various android bash binaries? I have no idea.
Click to expand...
Click to collapse
No, there is no magic. The entry says
"use this flaw to override or bypass environment restrictions to execute shell commands. Certain services and applications allow remote unauthenticated attackers to provide environment variables"
This means if a service or application which was running as another user (lets say root) and you provided it environment variables that exploited this vulnerability, then you could make it do stuff as root. But you'll only be able to make it do something that user could already do. Since there is no way to make a bash binary run as root in the first place, you aren't magically going to get root.
rbox said:
No, there is no magic. The entry says
"use this flaw to override or bypass environment restrictions to execute shell commands. Certain services and applications allow remote unauthenticated attackers to provide environment variables"
This means if a service or application which was running as another user (lets say root) and you provided it environment variables that exploited this vulnerability, then you could make it do stuff as root. But you'll only be able to make it do something that user could already do. Since there is no way to make a bash binary run as root in the first place, you aren't magically going to get root.
Click to expand...
Click to collapse
Here's more info:
http://www.csoonline.com/article/26...ity/remote-exploit-in-bash-cve-2014-6271.html
This has to do with Privilege Escalation -- it has nothing to do with a binary that already has root privileges. That's why security mavens are so freaked by this possible exploit. Lots of devices routinely run bash with non-root access; the possible exploit is to make bash crash, leaving you at a # prompt.
More info:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
jocala said:
Here's more info:
http://www.csoonline.com/article/26...ity/remote-exploit-in-bash-cve-2014-6271.html
This has to do with Privilege Escalation -- it has nothing to do with a binary that already has root privileges. That's why security mavens are so freaked by this possible exploit. Lots of devices routinely run bash with non-root access; the possible exploit is to make bash crash, leaving you at a # prompt.
Click to expand...
Click to collapse
I see nothing in there to indicate anything remotely related to privilege escalation. You can't gain root from thin air. If that were the case, it would be a kernel bug. This is just a vulnerability that can make the bash shell do something other than the script it's running says it should do. But it can't gain the ability to become a root shell.
A good example of a way to exploit this is passing in a specially crafted header into a cgi script, causing it to send that in to a bash shell, which would then be running arbitrary commands as the user of the cgi script. Similar to SQL injection where you cause the SQL server to run arbitrary commands.
Related
Anyone have or know where I can download the telnetd binary for Android? I think I might have a way to get root privileges on the Samsung Moment...and if it works, I see no reason why it wouldn't work on the Hero.
Just need that darn telnetd binary and any of the support files so I can install it into my phone (as long as the root exploit works.) It's running Android 1.5 btw if that makes a difference.
Why not ssh?
Download dropbear
telnet is an open invitation to get hacked, since the connection is not encrypted.
I know telnet is not encrypted...that's why I'll turn off the radio and enable wifi when I do this.
I was on the IRC (#android-root on freenode) and was pointed in the direction of JesusFreke's build environment, in which (s)he has built a veritable ****-ton of ARM binaries that are *extremely* useful.
http://jf.andblogs.net/2009/05/24/jfv151-images-are-out/
I found JFV1.51 CRB43 US BuildEnvironment (1324) to be particularly useful. Once extracted, I found binaries for a very full busybox, and a few dozen other useful goodies, including telnetd.
From the extracted tar, the binaries are under 'Build/System/ModifiedFiles/xbin'. adb push them to /data/local on the device, then call them via adb shell.
Example:
With device connected, and with the Android SDK installed and in your PATH:
Code:
# tar xvf JFv1.51_CRB43-US_BuildEnvironment.tar.gz
# cd Build/System/ModifiedFiles/xbin
# adb push <program of your choice> /data/local
# adb shell
# /data/local/<program of your choice>
Just out of curiosity...what is your hunch for getting root on the Moment?
@gargarxp - Thanks for the info!
gargarxp said:
Just out of curiosity...what is your hunch for getting root on the Moment?
Click to expand...
Click to collapse
I was looking through all of the recent kernel privilege level escalation reports, and ran across this one:
http://seclists.org/fulldisclosure/2009/Nov/105
It works on kernels up to 2.6.31...which the Moment runs 2.6.27. My plan is to use an Android app to execute this exploit contained in a native executable (which I have confirmed I can execute native code), which will then trigger a shell script I will write to copy the telnetd files into the proper places and start the service as root. From there, I'll telnet in...see if the root user has a password...and go from there.
Actually, if you get this to execute as root, the procedure from there is fairly simple.
From my understanding, the other root exploits have a singular goal: to gain a root shell for the purpose of creating a suid su for the system to use to gain root in the future. From the CDMA Hero process, once a root shell is gained:
Code:
# mount -o remount,rw -t rfs [COLOR="Red"]/dev/stl5[/COLOR] /system
# cd /system/bin
# cat sh > su
# chmod 4775 su
They:
Remount the /system fs as read-write
Go to the /system/bin directory
Copy sh to (a new) su
Set the permissions on that to 4 (SetUID) 775 (User-Group: RWX, Other: RX)
* The bit in red is what I observed the device mounted to /system to be on my Moment. I obtained this information by running adb shell mount and seeing what /dev device was next to /system. Should be the same for every Moment, but the procedure is useful for any Android (or Linux for that matter) device.
Once this is done, any user executing this su will do so as the user/group that the owns executable, which in this case is root:shell.
So, via this method, if you can manage to get a root shell on *any* Android device, bada bing bada boom: rooted.
...At least that is my understanding of it all.
Well...the problem is I can't get my Moment connected to my computer to run adb. I'm on Windows 7 64-bit...and the drivers won't load...and Samsung's PC Studio won't install properly. So, I found source code online for executing native code via an Android app...which should work to execute the native exploit.
And you'll have to excuse me...I've been using Linux for the past 10 years...programmed some projects on the platform...but this is pretty much my first time developing on Android.
Oh no problem at all. Frankly, I'm being overtly descriptive so as to make this post useful to the community in general and not be Moment-specific. I don't wish to encouter the ire of the XDA mods Just trying to do a public service.
So, do you have an ARM binary of the exploit built already (ImpelDown.c)? And if so, could you post a link to download it? I've never cross-compiled before and am currently going 10 rounds with gcc and the android-2.6.27 source tree.
Thank you! I know...it's kinda risky for me posting stuff about the Moment in an XDA forum...but I figure this could help the Hero efforts as well...and XDA was so good to me back when I was using my DIAM500...I wanted to contribute something back.
I'm still trying to get my cross-compiler built. I initially started out with Cygwin and a tool for building a cross-compiler...but that went horribly wrong...tons of compiler errors. I attempted to use Scratchbox on OpenSuse 11.2...but Scratchbox wants to run on a Debian system...ugh...haha.
And as I was typing my response to you...I decided to Google for "arm compiler windows" and found http://www.gnuarm.com/
But rest assured...once there's a working binary...I'll upload it here.
From the Gnash project's dev wiki....
http://wiki.gnashdev.org/Building_for_Android
They raise some issues with using a standard cross-compiler (GNUARM uses Newlib, which isn't the Android libc implementation Bionic...which is apparently a problem)
I grabbed the toolchain they link to on the page and am trying that.
Yeah...I found that out as well after I installed gnuarm...
I also just loaded the native toolkit.
Well gargarxp...I compiled it...ran it...didn't work. I'm going to try another one tomorrow.
One click root with impactor now works. Works on <4.3. No need for unlocked bootloader. Does not wipe data.
http://www.saurik.com/id/17
Copy over the superuser.apk and the such binary onto your phone, then use the MV command to move it to /system/app and /system/xbin respectively.
Beamed from my Grouper
Mach3.2 said:
Copy over the superuser.apk and the such binary onto your phone, then use the MV command to move it to /system/app and /system/xbin respectively.
Beamed from my Grouper
Click to expand...
Click to collapse
What should the permissions on each be?
EDIT: Can you alternatively only push the su binary and download superuser from gplay?
krackers said:
What should the permissions on each be?
EDIT: Can you alternatively only push the su binary and download superuser from gplay?
Click to expand...
Click to collapse
If the binary is wrong, the one from play store may not work.
Permission should be rw-r-r(0644) for the su.apk and rwsr-sr-x(0645) for the su binary.
Beamed from my Maguro.
I tried it myself and while it appears that commands do run, they don't appear to work. I think it might have to do with running as system vs running as root. Why else would saurik use an indirect method of gaining root (using ro.kernel.quemu) as opposed to directly pushing the su binaries.
krackers said:
I tried it myself and while it appears that commands do run, they don't appear to work. I think it might have to do with running as system vs running as root. Why else would saurik use an indirect method of gaining root (using ro.kernel.quemu) as opposed to directly pushing the su binaries.
Click to expand...
Click to collapse
This is correct: sometime in the Android 4.1 release cycle, they removed the ability to use /data/local.prop as an attack vector to go from system->root. The signature bug lets you modify the code of any APK, but the most powerful user an app can ever run as is system, not root.
However, in an update to Impactor today, I've added a system->root escalation. This allows one-click rooting, and even though the system->root I'm using has already been patched in AOSP (the idea was not to waste something to go along with a shell->system that is already long burned) it works on my 4.2.2 Nexus 4 (and so I'd imagine will also work fine on a Galaxy Nexus) as Android sucks at getting patches to real devices ;P.
Using Impactor on my Panasonic Eluga dl01 does somehow not work.
(Android 4.0.4)
I get following error message:
/data/local/tmp/impactor-6[3]: /data/local/tmp/impactor-4: Operation not permitted
I also tried and played around with the command line in Impactor.
"adb devices" won't list my phone
But when I use the adb from the current Android SDK I just installed, it will display my phone with "adb devices".
I also downloaded a ICS 4.04 root zip file with a script and adb files inside. When using that adb version, my phone won't be displayed too. Now when I run adb from the android SDK, it will say something like "server is outdated" then something like "kill and restart with new server" --> "adb devices" lists my phone correctly again.
May be the adb version used in Impactor is outdated and responsible for the error message?
I would really appreciate any help with this topic, because the Panasonic Eluga phone was never rooted until now and no known root method is available. I always kinda hoped that someone would use the masterkey thing to make a universal rooting tool
saurik said:
This is correct: sometime in the Android 4.1 release cycle, they removed the ability to use /data/local.prop as an attack vector to go from system->root. The signature bug lets you modify the code of any APK, but the most powerful user an app can ever run as is system, not root.
However, in an update to Impactor today, I've added a system->root escalation. This allows one-click rooting, and even though the system->root I'm using has already been patched in AOSP (the idea was not to waste something to go along with a shell->system that is already long burned) it works on my 4.2.2 Nexus 4 (and so I'd imagine will also work fine on a Galaxy Nexus) as Android sucks at getting patches to real devices ;P.
Click to expand...
Click to collapse
Do you need to have an unlocked bootloader for the root exploit to work? I am hoping to get root without having to wipe the device by unlocking.
To the poster above me: Try using a different computer and if that doesn't work, switch operating systems.
krackers said:
Do you need to have an unlocked bootloader for the root exploit to work? I am hoping to get root without having to wipe the device by unlocking.
Click to expand...
Click to collapse
That's the whole point in securing Android, not that people have easier ways instead of unlocking a device.
Tested and works great. I now have root. Yay!
Does it show any of the problems that chainfire's superSU 1.41 shows?
Sent from my Galaxy Nexus using xda app-developers app
The root exploit only places the su binary and sets the right permissions. You can use any root manager you want (I used clockworkmod's superuser app).
mercuriussan said:
Using Impactor on my Panasonic Eluga dl01 does somehow not work.
(Android 4.0.4)
Click to expand...
Click to collapse
The feature of installing su will not work on every device: a lot of emphasis is put on "rooting" Android devices, but on many devices even root can't do things like modify the files in /system; I'd use the term "jailbreak" as to being what people really want to do with their device, but Android people seem to have that term ;P. What this means is that you really need a kernel exploit, not just a shell->system->root escalation.
mercuriussan said:
I get following error message:
/data/local/tmp/impactor-6[3]: /data/local/tmp/impactor-4: Operation not permitted
Click to expand...
Click to collapse
This error message actually indicates that Impactor succeeded in obtaining root control over your phone. However, when it tried to then, as root, remount /system writable so it could copy the su binary in place, it wasn't allowed to do so. A future version of Impactor will make it easier to drop to a root shell so you can test things out manually, but this means that while you can run code as root, you won't be able to install su.
However, if you have the time to play with it, get a copy of busybox and use adb to push it to /data/local/tmp (this is also something Impactor should help you do, but does not yet). (You will also need to make it executable, don't forget: "chmod 755 /data/local/tmp/busybox".) Then run the suggested Impactor command involving telnetd. Finally, via a shell, run "/data/local/tmp/busybox telnet 127.0.0.1 8899": you are now root.
You can verify that you are root because you will now have a # as a prompt instead of a $. Then run "mount -o remount,rw '' /system" (<- note, that's two single quotation marks as an argument between remount,rw and /system). This is the command that should fail with the "Operation not permitted" message. You are, however, root, so maybe there's something you want to do on the device at that point ;P.
mercuriussan said:
I also tried and played around with the command line in Impactor.
"adb devices" won't list my phone
But when I use the adb from the current Android SDK I just installed, it will display my phone with "adb devices".
Click to expand...
Click to collapse
The "Open Shell" in Impactor connects you to the device via adb: if you run adb on the device and ask for a list of devices attached to the device--something I didn't even realize was possible until you pointed it out here ;P I tested it, though, and wow: that actually is possible--you will get a blank list. However, suffice it to say that if you were able to type that at all, it can see your device.
Thanks for the suggestion, I'll try my luck in finding some exploit I can use...
So since Google patched this in 4.3, does this mean almost all devices before 4.2.2 can be rooted with this method?
bmg1001 said:
So since Google patched this in 4.3, does this mean almost all devices before 4.2.2 can be rooted with this method?
Click to expand...
Click to collapse
Yup - assuming they haven't been patched against the methods used (most haven't been).
Very interesting read. Thanks saurik & OP.
Eluga DL1
Hi there,
this post is in some ways a duplicate but different people seem to follow this thread because it is directly involving sauriks impactor.
Is there anything available that i can throw at Elugas 4.0.4 kernel to get r/w on the system partition?
I will try everything that is suggested to me.
So, by going into the settings menu of the FTV and toggling the ADB Debug flag, this allows for installing via a push from ADB.
The text that is displayed when changing this value also says that by enabling the setting, it allows for package installs from unknown sources.
Is this not quite the case though?
Using ES File Manager, when selecting an apk package located in the downloads folder on the device, the message shown in the attached screenshot appears.
Since there's no way to do so from the front-end, I am assuming that we will need root to change the flag to truly allow installing from any source?
Any possible way to do this without root?
mkhopper said:
So, by going into the settings menu of the FTV and toggling the ADB Debug flag, this allows for installing via a push from ADB.
The text that is displayed when changing this value also says that by enabling the setting, it allows for package installs from unknown sources.
Is this not quite the case though?
Using ES File Manager, when selecting an apk package located in the downloads folder on the device, the message shown in the attached screenshot appears.
Since there's no way to do so from the front-end, I am assuming that we will need root to change the flag to truly allow installing from any source?
Any possible way to do this without root?
Click to expand...
Click to collapse
Yeah, this isn't currently possible for the public. There is a root exploit(s) already developed but they have not been released yet. The developer, jcase, said he will release an exploit on the same day the upcoming Fire TV update is pushed (the exploit will not be compatible with the update so if you want it you'll need to follow the instructions in the other thread for blocking OTA updates).
mkhopper said:
Any possible way to do this without root?
Click to expand...
Click to collapse
Are you having issues with ADB? We can probably help you get those resolved.
Chahk said:
Are you having issues with ADB? We can probably help you get those resolved.
Click to expand...
Click to collapse
Thanks, but no. I use the automatic tool to push packages with no problems. I was just looking for other methods of package installation that could be done directly while on the FTV.
mkhopper said:
Thanks, but no. I use the automatic tool to push packages with no problems. I was just looking for other methods of package installation that could be done directly while on the FTV.
Click to expand...
Click to collapse
Not at this time. Amazon disabled side-loading of APKs from the device itself. Root would be the only way to get around that.
mkhopper said:
Thanks, but no. I use the automatic tool to push packages with no problems. I was just looking for other methods of package installation that could be done directly while on the FTV.
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=2715315
Sent from my MZ617 using XDA Premium 4 mobile app
Kramar111 said:
http://forum.xda-developers.com/showthread.php?t=2715315
Click to expand...
Click to collapse
several days ago it occurred to me to alternatively use sshd for terminal access, because:
-a) I feel a little unsafe leaving adb wifi enabled all the time (ok it's only a small thing to turn it on and off, but still) - and for security reasons there is no way to enable/disable it programmatically e.g. from a script/shell/terminal/app (well theoretically this is not exactly true, but practically it is)
-2) some people (i.e. me) would like to do shell/terminal remotely sometimes, rather than on the AFTV (and other people don't have/want a keyboard)
ssh access makes a great alternative to Term.apk, but the problem is:
- Term.apk and/or (pick your favorite android ssh server) don't have permission to run e.g. "pm install foo.apk" - it will fail. (btw 'pm' is a great command, take a look sometime at all the options. it shares a lot of functions as the adb command itself. 'am' is another fun command...)
- so, the hilarious workaround of enabling adb wifi, "adb connect", and then finally "adb shell" or "adb install" etc., is still required. (b/c the adb user is in the 'shell' group, among others - giving it permission to run /system/bin/pm) - oh well.
for random reference:
Code:
127|[email protected]:/ $ id
uid=2000(shell) gid=2000(shell) groups=1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats)
[email protected]:/ $ exit
[email protected]:/ $ id
uid=10009(app_9) gid=10009(app_9) groups=1015(sdcard_rw),1028,3003(inet),50009(app_40009)
(also note it appears the adb shell user might possibly have 'mount' abilities, but since the /dev/block/sd* nodes permissions' are really locked up, who knows...)
https://redd.it/59n5r9
If its possible to do on other phones that run the un-patched kernel I suppose it can be done on the Spring G5. If so that would be the luckiest break ever lol.
Not sure if its really going to be a root method and let super user work because the owner of the repo said "I put 'root' in quotes, because technically, it isn't rooting. However, it creates a binary called 'run-as' that can execute packages as root.".
He also he mentioned it has'sent been tested on 64-bit
I'm working on trying to understand how exactly the bug works, and to see if it can be replicated. In theory, it should work because even 64-bit desktop kernels are affected. Additionally, the bug still exists in the kernel upstream, so all Android devices should be affected.
Update on this. The exploit does work on the LG Stylo 2, which is running very similar software to the LG G5, but I am having issues installing su, but I do have root...temp root at least.
this will not root your phone to let you run titanium backup or Xposed APIs. If you lucky you can maybe make changes to build.prop and only if the system partition is not signed like the kernel is. So I would not bet on this.
with temp root can you mount system as rw and make changes? if not it's completly pointless
can you provide binary, so we do not have to compile. I would try it as well
lg phone ever not get root?
I have the exploit running on my Stylo 2, but I can't do anything. SELinux is set to enforcing, but I do have a root shell.
Code:
λ adb -d shell
[email protected]:/ $ run-as exec whoami
Warning: setcon transition to 'u:r:init:s0' failed (is SELinux Enforcing?)
root
[email protected]:/ $ run-as exec dd if=/dev/block/bootdevice/by-name/boot of=/sdcard/boot.img
Warning: setcon transition to 'u:r:init:s0' failed (is SELinux Enforcing?)
dd: /dev/block/bootdevice/by-name/boot: Permission denied
1|[email protected]:/ $
can you mount system partition as r/w to modify system files?
We can use the Dirtycow exploit to replace any file in the system memory with a file of the same size, but All files will revert once rebooted thanks to SELinux as mentioned, it enforces whatever file you replaced with same security. Escalated privileges doesn't seem possible while SELinux is enforcing. There is a thread dedicated for more discussion from others with more knowledge below:
http://forum.xda-developers.com/general/security/dirty-cow-t3484879
Believe me many people are working for this to be our Savior.
Couldn't we use this method, modify the update file to be rooted, then let the 7.0 install itself?
I think I already know the answer but you'll never know.....
I am looking into options to use LOS17 in combination with LOS recovery because then it is possible to have OTA updates even when storage is encrypted.
Though, I would like to have the option to use a script so I can remove some system apps, add some stuff to build.prop and remove some temporary files after every OTA.
As far as I know the only way this is possible is to add an a script to /system/addon.d.
Therefor I have tried using adb to push a file, though when phone is not rooted, it is not possible to use adb root and then adb remount rw and adb push.
So here the questons;
- Is is possible to add a script to /system/addon.d, though without root and without TWRP?
- When not; is there another way to run a script after every OTA without root and without TWRP?
Setup:
LOS 17.1 without root, encrypted and locked bootloader
I will answer myself as it seems OR a stupid question OR something else....
But, as already expected, without root en with a locked bootloader, the recovery is the only place where you can do something root-related when the recovery is giving this option ofcourse. LOS recovery, automatic OTA updates and additional scripts is therefor not possible because you can not place or modify stuff in /system (as it should be out of security concerns on non-rooted devices).
Though, @nvertigo67 posted a nice post about this topic. After reading I realised that, as I want to be in control of my phone AND I want to pay something back to our great dev's, I will definitely stick with TWRP and flashing and running scripts myself.
How to install LOS with TWRP, encrypt en relock bootloader can be found here.
Topic closed for me.
I messed it up myself with my modified build.prop settings:
By design adb root command works in development builds only (i.e. eng and userdebug which have ro.debuggable=1 by default). So to enable the adb root command the ro.debuggable=1 line must be in build.prop, which I have set to 0 for CTS reasons.
Unfortunately it seems my banking app is looking for this parm because when set to 1 the app is giving an error message on startup.
So no adb root for me as long as I want to use the banking app.