Many Millions of Linux are affected by this security hole
Interesting info about update.zip method. A few googling show that it is device-specific, if only because different devices use different cert to sign the files inside update.zip. Do you have a link? The only one I found is this one: http://forum.xda-developers.com/showthr ... ?t=1610121@jamesbond -just to clarify that not all methods for rooting android use an exploit. su can be installed in an update.zip installed from recovery mode, on devices (many) which allow that.
It's the one-click-root apps which you install and the online root methods which use an exploit of (usually) a kernel bug. I have used these a couple of times -before I learned enough to use the update.zip method and create the update files.
I never use the one-click-root --- although these seem to become a trend (e.g. Kingoroot); I usually look into the individual rooter script to see what it's doing (most rooter scripts are batch files for Windows). I usually try to use an exploit that uses a built-in application rather than an external app that I have to "adb push" ... but sometimes we don't have a choice.
The problem here, like anywhere else, is trust. Do you trust that the app you use to root your device, doesn't do anything else behind your back (because obviously it can).It is spooky to consciously use the apps which use exploits -but not any spookier than knowing that those same exploits can be executed in other ways without one knowing it.
Which is the reason why these devices will *never* be my trusted devices. My effort on FatdogArm is avoid falling into this very trap, but it has a lot usability problem when used for non-desktop purposes.What really bothers me about Android is the way that any old app can access/delete/change my personal data -and that so many are accessing stuff which is completely unrelated to the purpose of the app -I mean *my* purpose for the app. For instance, why should a weather app be able to read my docs, look at my pics, find out my wireless password, etc??!
They will realise their mistake only when what they did hit them back, unfortunately. It's like the guillotine inventor who died by his very own invention. Or, for a more modern example, a senator who promotes NSA spying until he found out that he's being spied on himself.Unfortunately, the vast majority of Android devs come from the M$ crowd and have no problem with closed-source data-mining programs running amok in my $HOME.
EDIT: Make post clearer and remove irrelevant rants.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
Ok. devices which have a bootloader, can only use update.zip if the bootloader is unlocked. Devices which have a bootloader are chiefly Nexus, but some other high-end devices also have them -pretty sure that some LG fit in this category. You can find out by trying to run 'fastboot devices' on the device from your PC over USB. 'fastboot oem unlock' 'unlocks' the bootloader, which means that the recovery system will then allow updates to be installed.
Most devices are not fastboot-compatible -thy don't have a 'real' bootloader. For these, simply rebooting or booting into recovery mode should let you install updates. 'strict' devices do indeed require that the updates be signed with the same key as the manufacturer used. I'm unsure about the percentages here, but all of my devices have allowed updates to be installed -as long as they are signed -the process is the same as with signing an *.apk.
That still doesn't allow for any universal rooting update, since the layout of the ROM varies between different brands, models and OS versions.
The update-from-recovery facility was designed to allow OEM's to offer OS updates to users. In practice, most OEM's do *not* offer updates. But the method can be used in many ways -the update.zip comes with it's own update-binary which is a sort of shell which reads an updater-script and execute the commands. It can mount/umount, copy file/dirs, set perms and other such actions. (An interesting project was/is the Aroma Installer which ships and enhanced update-binary which includes a file manager and more.) Anyway, an update can install anything you like, including the 'su' binary and any 'su management' app.
I certainly do not use any Android device with any trust at all. I do no online-banking from them. Although it is certainly possible to make the virgin system much more secure, by removing many or all google-apps. But one still needs to find an app or two for some purpose -why else would one have a smart device? There are a few apps which are supposed to 'manage' other apps access to things -above and beyond whatever control the OS exercises -but again this all starts with 'Install App XXX', which is most likely not opensource and hence completely opaque.
I actually have zero use for a smartphone, but I wanted to know how it all works -and with my son using one I wanted to do everything possible to defend him from attacks. I really don't care if anyone reads my 'docs' -bash scripts, or looks at my 'pics' -screenshots of widgets. But I love getting in the way of others vested interests -when they are aimed at me.
Search for android 'update-binary', android 'update.zip' or android edify to learn more about update.zip. edify is the Domain Specific Language used by the update-binary.
I really ought to blog about my adventures with android -the view from an old Linux 'rooter' is certainly different from the M$ and web-devs 'java-jockeys'.
Most devices are not fastboot-compatible -thy don't have a 'real' bootloader. For these, simply rebooting or booting into recovery mode should let you install updates. 'strict' devices do indeed require that the updates be signed with the same key as the manufacturer used. I'm unsure about the percentages here, but all of my devices have allowed updates to be installed -as long as they are signed -the process is the same as with signing an *.apk.
That still doesn't allow for any universal rooting update, since the layout of the ROM varies between different brands, models and OS versions.
The update-from-recovery facility was designed to allow OEM's to offer OS updates to users. In practice, most OEM's do *not* offer updates. But the method can be used in many ways -the update.zip comes with it's own update-binary which is a sort of shell which reads an updater-script and execute the commands. It can mount/umount, copy file/dirs, set perms and other such actions. (An interesting project was/is the Aroma Installer which ships and enhanced update-binary which includes a file manager and more.) Anyway, an update can install anything you like, including the 'su' binary and any 'su management' app.
I certainly do not use any Android device with any trust at all. I do no online-banking from them. Although it is certainly possible to make the virgin system much more secure, by removing many or all google-apps. But one still needs to find an app or two for some purpose -why else would one have a smart device? There are a few apps which are supposed to 'manage' other apps access to things -above and beyond whatever control the OS exercises -but again this all starts with 'Install App XXX', which is most likely not opensource and hence completely opaque.
I actually have zero use for a smartphone, but I wanted to know how it all works -and with my son using one I wanted to do everything possible to defend him from attacks. I really don't care if anyone reads my 'docs' -bash scripts, or looks at my 'pics' -screenshots of widgets. But I love getting in the way of others vested interests -when they are aimed at me.
Search for android 'update-binary', android 'update.zip' or android edify to learn more about update.zip. edify is the Domain Specific Language used by the update-binary.
I really ought to blog about my adventures with android -the view from an old Linux 'rooter' is certainly different from the M$ and web-devs 'java-jockeys'.
@amigo - Thank you. I searched for the keywords you mentioned and found all the necessary resources. Now I just need a device for testing 
Last two comments:
---
a) if there is no restriction then we can actually put our own static binary and name it as "update-binary". That binary doesn't have to run edify script, it can run bash-script instead
b) I tried to build grub4dos its associated utilities (including wee.mbr) from its sources; and were successful - both for the earlier ones and as well as the latest git copy. The binaries differ from the official binary tarball though, but a lot of factor can be accounted for it (e.g. different compilers, etc). So at least the sources are legit.
___________________________
@gcmartin: "I am not sure, unless I was a die-heart Security officer whose concept of security is a room with no doors or no windows at all, that I would consider modifying a system for root access a security hole. For Androids, I believe that this was done for development needs. Most system developers would see this as a necessary need, versus how a security developer would view this in any effort to protect the vendor's propietary position."
-> Are you implying that exploiting a kernel bug to gain root access is acceptable, just because it happens on a non-desktop device?
These devices are locked for a reason. Whatever the reasons are isn't isn't relevant to discussion - the point is; end-users aren't supposed to be able to get root access. Now, I love root access like the next guy, but I am deeply sad and concerned that often times the only way to get that is by using kernel bugs.
"There are some things which should be considered as operational needs versus Security holes. ... whether that be closed or open source."
-> In my opinion the ability to gain root by exploiting a kernel bug is *never* an operational needs. You want to hand out root, you give it through a controlled, audited, defined process. Google Nexus devices can be made root quite easily - without the need for kernel bugs, so are Nokia N900 devices. These are just examples.
And, of course, EVERYTHING has perceived risk and actual risk (these 2 are different).
-> Of this, I agree with you. Fully.
Last two comments:
---
a) if there is no restriction then we can actually put our own static binary and name it as "update-binary". That binary doesn't have to run edify script, it can run bash-script instead
b) I tried to build grub4dos its associated utilities (including wee.mbr) from its sources; and were successful - both for the earlier ones and as well as the latest git copy. The binaries differ from the official binary tarball though, but a lot of factor can be accounted for it (e.g. different compilers, etc). So at least the sources are legit.
___________________________
@gcmartin: "I am not sure, unless I was a die-heart Security officer whose concept of security is a room with no doors or no windows at all, that I would consider modifying a system for root access a security hole. For Androids, I believe that this was done for development needs. Most system developers would see this as a necessary need, versus how a security developer would view this in any effort to protect the vendor's propietary position."
-> Are you implying that exploiting a kernel bug to gain root access is acceptable, just because it happens on a non-desktop device?
These devices are locked for a reason. Whatever the reasons are isn't isn't relevant to discussion - the point is; end-users aren't supposed to be able to get root access. Now, I love root access like the next guy, but I am deeply sad and concerned that often times the only way to get that is by using kernel bugs.
"There are some things which should be considered as operational needs versus Security holes. ... whether that be closed or open source."
-> In my opinion the ability to gain root by exploiting a kernel bug is *never* an operational needs. You want to hand out root, you give it through a controlled, audited, defined process. Google Nexus devices can be made root quite easily - without the need for kernel bugs, so are Nokia N900 devices. These are just examples.
And, of course, EVERYTHING has perceived risk and actual risk (these 2 are different).
-> Of this, I agree with you. Fully.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
I think the point to notice about smartphones is that they are conceived as an appliance -just like earlier phones were, with a strictly limited set of possible interactions. Some of us with lots of PC experience are frustrated by the hardware and software limitations of any such appliance -we were used to freely adding or changing hardware and booting whatever we were capable of booting.
smartphones have brought us some of the way back -at least the systems are modular and one can install all you want. But you need 'root' to mess with the real underhood workings. And being root means you can also easily destroy the device. The manufacturers understandably defend themselves from possible warranty claims resulting from such root-ing around.
And still we want to get in there and dew-abi'a-tweekin' -if only to find out WTF is really happening in there.
I have two different tablets -one of them is an old Gingerbread thing which never gets used now. The other one is an ODYS UNO_X10. The ODYS is a typical JellyBean & later device which uses a mtd block device for internal storage.
I have two identical phones, which are typical 'China Phones' -they use an emmc block device. Of course the effect is the same -only the device names are changed to protect somebody. The difference becomes critical, though, when installing updates, because the writable areas of storage have to be mounted read-write first. So, the device type and 'partition' layout matter.
I say 'partition' with quotes because of the way the ROM is structured. The raw device is divided into sections:
1. At first there is the area where the bootcode goes -it's not always called or considered to be a 'bootloader'.
2.Then ,there are usually one or two areas which contain 'ebr' Extended Boot Record -sorta like the grub Stage 2.
3. After that there is an area which contains the 'radio' -a binary blob of drivers and firmware for whichever phone protocol and the parts for wireless and bluetooth.
The above parts all fit the concept of ROM nicely as they are each a single blob of machine code and can only be read or written as a whole piece.
4. Next, come larger sections which hold the recovery.img and boot.img. These work much like an initrd works. But each is separate, containing its' own kernel and filesystem image. These sections are also written/read as a whole.
5. Finally, there are several partitions which comprise the rest of the ROM.
When you boot normally, the boot.img gets loaded, its' kernel loads and after its' own offset, finds the 'initrd' part of the image. It contains a few basic tools and configs, like the (first) fstab file which defines which partition to use for the system. The toplevel of this image remains as the root '/' dir.
The main Android system is all under the /system directory, /system/bin/sh is the shell, libs are in /system/libs and admin-level tools are in /system/xbin. There is also a 'vendor' bin dir. Major OS functions which exist as an *.apk are kept under /system/apps
Android also uses a 'cache' mounted at /cache -it's used sort of like /tmp under linux -but usually only by the system. This is where the jave (dalvik) byte-code for each app is generated and where the programs last 'state' is stored.
Then there is the 'data' partition mounted at /data. This is where your add-on apps get installed and where they keep there individual files. Each directory under /data/app is like a HOME dir for that APP.
The last partition is the internal 'sd' card which is sometimes called 'external storage'. If you don't plug in a real, removeable sdcard, this is the area that gets used to store your screenshots, pictures, downloads, etc. It is like HOME where you can do what you want. This area is always formatted as vfat. If you use a real sdcard, then this area will remain mostly untouched, unless you use the package manager to 'move' an installed (user) app to sdcard.
KitKat and later versions of android make it increasingly harder even to use the sdcard space internal and/or external as you might wish -they may be mounted 'noexec' so that you can't run scripts from there.
If you don't have any device yet, try to find something really cheap and buy two! Use the one as a virgin phone without wireless, 'data' plan or Google Play. Take the other one use it only for wireless and Co. Download apps on it and then transfer to the other phone on an sdcard for any must-haves. root the one you use for wireless -if you have questions or problems you can always refer to the virgin system or create a rescue backup from it.
Install just a terminal emulator and a better file manager which lets you (try) to look at the / dir. The standard FM only lets you look at/use the one or two sdcard areas. Once you have a console you can see into most areas of the filesystem. /proc/ and /sys are right where they are under linux -but there is no thing like /var -that's what /cache does.
Have Fun!
smartphones have brought us some of the way back -at least the systems are modular and one can install all you want. But you need 'root' to mess with the real underhood workings. And being root means you can also easily destroy the device. The manufacturers understandably defend themselves from possible warranty claims resulting from such root-ing around.
And still we want to get in there and dew-abi'a-tweekin' -if only to find out WTF is really happening in there.
I have two different tablets -one of them is an old Gingerbread thing which never gets used now. The other one is an ODYS UNO_X10. The ODYS is a typical JellyBean & later device which uses a mtd block device for internal storage.
I have two identical phones, which are typical 'China Phones' -they use an emmc block device. Of course the effect is the same -only the device names are changed to protect somebody. The difference becomes critical, though, when installing updates, because the writable areas of storage have to be mounted read-write first. So, the device type and 'partition' layout matter.
I say 'partition' with quotes because of the way the ROM is structured. The raw device is divided into sections:
1. At first there is the area where the bootcode goes -it's not always called or considered to be a 'bootloader'.
2.Then ,there are usually one or two areas which contain 'ebr' Extended Boot Record -sorta like the grub Stage 2.
3. After that there is an area which contains the 'radio' -a binary blob of drivers and firmware for whichever phone protocol and the parts for wireless and bluetooth.
The above parts all fit the concept of ROM nicely as they are each a single blob of machine code and can only be read or written as a whole piece.
4. Next, come larger sections which hold the recovery.img and boot.img. These work much like an initrd works. But each is separate, containing its' own kernel and filesystem image. These sections are also written/read as a whole.
5. Finally, there are several partitions which comprise the rest of the ROM.
When you boot normally, the boot.img gets loaded, its' kernel loads and after its' own offset, finds the 'initrd' part of the image. It contains a few basic tools and configs, like the (first) fstab file which defines which partition to use for the system. The toplevel of this image remains as the root '/' dir.
The main Android system is all under the /system directory, /system/bin/sh is the shell, libs are in /system/libs and admin-level tools are in /system/xbin. There is also a 'vendor' bin dir. Major OS functions which exist as an *.apk are kept under /system/apps
Android also uses a 'cache' mounted at /cache -it's used sort of like /tmp under linux -but usually only by the system. This is where the jave (dalvik) byte-code for each app is generated and where the programs last 'state' is stored.
Then there is the 'data' partition mounted at /data. This is where your add-on apps get installed and where they keep there individual files. Each directory under /data/app is like a HOME dir for that APP.
The last partition is the internal 'sd' card which is sometimes called 'external storage'. If you don't plug in a real, removeable sdcard, this is the area that gets used to store your screenshots, pictures, downloads, etc. It is like HOME where you can do what you want. This area is always formatted as vfat. If you use a real sdcard, then this area will remain mostly untouched, unless you use the package manager to 'move' an installed (user) app to sdcard.
KitKat and later versions of android make it increasingly harder even to use the sdcard space internal and/or external as you might wish -they may be mounted 'noexec' so that you can't run scripts from there.
If you don't have any device yet, try to find something really cheap and buy two! Use the one as a virgin phone without wireless, 'data' plan or Google Play. Take the other one use it only for wireless and Co. Download apps on it and then transfer to the other phone on an sdcard for any must-haves. root the one you use for wireless -if you have questions or problems you can always refer to the virgin system or create a rescue backup from it.
Install just a terminal emulator and a better file manager which lets you (try) to look at the / dir. The standard FM only lets you look at/use the one or two sdcard areas. Once you have a console you can see into most areas of the filesystem. /proc/ and /sys are right where they are under linux -but there is no thing like /var -that's what /cache does.
Have Fun!
Hmmmm, as I read your comments I had uneasy feelings about similar comments I read a while ago concerning the stuxnet team. When brilliant minds come together to form intricate code one hopes the motive is benevolent socialism. But maybe it's not.amigo wrote:I will comment more about grub4dos, though. The fellows working on the code are *very* smart people....These are certainly folks who could throw you a curve -software-wise.
...Later, the changes became completely messy, with the difference between one version and the next *micro* increment amounting to thousands of lines of changed code, with features fixes and pure white-space changes all mixed together -without any comments in the code or in the patches.
By now, if you create a diff between their sources and the original, you'll get a patch file of over 500,000 lines. And, if you compare any two branches(two different devs) of the code, you'll get a disturbing picture, indeed.
-
gcmartin