the problem is not about being able to access su from a non-privileged uid, but of kernel code flaws. a buffer overflow can allow the attacker to take control of the stack and run his own instructions in kernel mode. (papers have been published about more sophisticated attacks like return oriented programming without returns) So, just using "su" or "setuid" is not the only method to execute external code in privileged mode. (by the way, su uses setuid to elevate)
On Dec 20, 9:30 am, Kevin Veroneau <[email protected]> wrote: > An issue that has been haunting loyal developers, who are sometimes scared > off by the fact that they can lose revenue from a ROOTed device. ROOTed > devices are also known for the security concerns when used in public > networks, such as a cellular network, or public WiFi. > > I am very surprised that nobody has thought of this idea, which I am about to > propose to the Android community for possible consideration into the kernel > source tree. Yes, this will be kernel related. > > As most Linux kernel developers know, they can release a kernel module which > is non-GPL'd, it taints the kernel, but ultimately the developer controls the > code. Nvidia and VMWare are known for tainting kernels all around the globe. > Not saying, this idea needs to be developed as non-GPL, but it wouldn't > hurt, if we are protecting DRM, and developers who wish to keep their income > flowing from the Android market. Currently, as most websites point out, > copying a bought app from the market can easily be done with ROOT access on > the device, this is a security concern for current app developers who put > many of their resources into delivering great apps to Android users. I would > also recommend having it non-GPL'd, as it would have a slight advantage over > iOS, as they cannot take the code and apply it themselves. If Android is > shown to be a more secure mobile development platform, and developers know > that their products cannot be stolen by a ROOT or Jailbreak, it will attract > them to this platform over the insecure competition. Although at this point, > I see Android succeeding over iOS. > > The idea: Either a Linux kernel module, or a kernel modification which > proxies the system call which SU uses to change the current UID. For > traditional Linux workstations, it would for example, disallow the system > call for any UID greater than 999. It would still allow system services to > utilize SUID permissions, and the system call for changing the UID. I have > seen what SELinux can do to protect Linux systems can many dangers, and I > believe this type of ability can be done. > > Although, I am not a fluent Linux kernel hacker, and have yet to look at how > SU works internally to switch the user. However, considering how a Linux > system is as secure as it is, I am sure it goes through the kernel or some > sort of library to do the UID switch. It sounds more like a kernel feature > to me. > > Currently all Android does is not ship the SU binary... This is very lazy > and not really the best preventive measure to stop hackers from abusing SU. > It's not hard to compile a C program that uses a system call which SU uses. > Now that the NDK is available, I do hope that it does not allow direct access > to such system calls that allows any application to do a UID switch. This > would make the system very insecure for a mobile platform. > > I cannot stress enough, how much this needs to be implemented into the > Android kernel, or libraries. I also cannot believe how such a security > issue could have been overlooked before the release of the Android platform. > In reality, only dev devices should ship with the ability to SU, application > developers do not need such low-level access. Applications from the market > should never need to run as ROOT. I use a Linux workstation, and only trust > a few select applications with ROOT permissions. > > Android could also utilize the Linux chroot as well, as a preventive measure. > Run every single app in a chroot, if SU is obtained somehow, it cannot > escape out of the applications data directory assigned. If I were to start > an Android type mobile platform from scratch, I would utilize as many Linux > security features as possible to prevent exploitation of the mobile system. > Does Android use SELinux? I do not believe so, although I'm not sure if it > is ARM compatible. At the moment, it does seem that Linux is basically just > being used a simple bootloader for the Android system, and minimal security > is placed upon the Linux system. If your going to use Linux, at least use > the security features which have been developed for many years and proven to > work in secure server environments. > > Why doesn't the DelvikVM run each app in a chroot? Using a terminal emulator > on the device should not really reveal the entire Linux system, but a > contained directory for just that app. I feel this is a huge security > concern, this basically means any app and do anything to my data, as long as > it has permissions in the underlaying file system. Which it would have full > permission to my SDCard and my personal data stored there. This is why and > how Malware is starting to appear on the Android system. > > Starting with version 3 of the Android system, I would suggest taking these > security concerns to mind and actually using the security features Linux has > to offer to make Android just as secure as any Linux workstation. I'm sure > there is a way to keep backwards compatibility and add these above security > additions with little issues or overhead. > > I look forward to any discussions upon this idea, as I would like a more > secure device in my pocket. Malware is completely unacceptable in any Linux > environment, if the press says Android has Malware, this negativity will hurt > GNU/Linux, which is for the most part uneffected by Malware at the time of > this writting. > > Thank you for reading and considering this idea. > -- > Sent from my Pocket eDGe. -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
