Gaining a Remote Shell On Android

SharkLaser writes "The security of Android devices has come under scrutiny in recent months. Android Market has been plagued with a number of trojaned apps, and researchers have identified various root exploits and permission leaks that can be exploited, for example, to send premium rate SMSs. Now researcher Thomas Cannon of ViaForensics is demonstrating a method for setting up remote shell on an Android device without using any exploits or vulnerabilities. The security hole is not new, and it has been pointed out for a number of years, but Google has yet to fix it. The method works on various versions of Android, up to and including the newest Ice Cream Sandwich."

Comments

Direct link to Vimeo How-To

[xmas2003]

Thomas has a pretty low-key way of presenting the shell access in the linked article - here's the Vimeo how-to video.

_NSAShell

[Anonymous Coward]

Why do these tinfoil hat types keep bringing up the _NSAShell functionality? Enough already!

Re:_NSAShell

[smpoole7]

> Why do these tinfoil hat types keep bringing up the _NSAShell functionality? Enough already!

Because it hasn't been patched yet, and because it's a significant vulnerability.

Clear enough?

Re:_NSAShell

[CanEHdian]

I guess the sarcasm tag is missing in the parent posting (reference to the _NSAKEY cryptographic API key exposed by the WinNT SP5 updater).

Re:_NSAShell

[VortexCortex]

Woosh

TFA is blank

[Culture20]

I'm guessing it loads all its content via javascript anf my noscript is blocking it. I'm glad I'm also using adblock so they didn't get any ad-views for not showing content.

Re:TFA is blank

[Anonymous Coward]

No-permission Android App Gives Remote Shell

I have been working at viaForensics as the Director of R&D for about 5 months now, and in that time I’ve been involved in some exciting research projects. I haven’t had the opportunity to blog on our company site yet so I thought I’d take a little time out and record a video to demonstrate an Android issue that is of interest to many of our clients.

When talking with people and reading posts on the web I’ve often heard people say that the Android permission system protects their device such that apps without certain permissions are therefore safe to install. The permissions system on Android is a fantastic idea and generally well implemented, it gives apps just enough permissions or capabilities to perform the required functions without exposing capabilities that could be used in a dangerous way. It is a step up in protection when compared with a typical desktop system but this increased protection can give rise to a false sense of security.

Putting aside the issue of users ignoring the permissions when installing apps, can we rely solely on permissions to decide if an app is safe? There are multiple controls in Android and its ecosystem that protect a user and their device, but one should not automatically assume that installing an app, even if it requires no permissions, is safe.

To demonstrate this we’ve built an app which requires no permissions and yet is able to give an attacker a remote shell and allow them to execute commands on the device remotely from anywhere in the world. The functionality we are exploiting to do this is not new, it has been quietly pointed out for a number of years, and was explained in depth at Defcon 18 [1]. It is not a zero-day exploit or a root exploit. We are using Android the way it was designed to work, but in a clever way in order to establish a 2-way communication channel. This has been tested on Android versions ranging from 1.5 up to 4.0 Ice Cream Sandwich, and it works in a similar way on all platforms.

Please see the video below with accompanying audio for further explanation.

Link to video: Android No-permissions Reverse Shell

I should also mention here a recent paper by Michael Grace, Yajin Zhou, Zhi Wang, and Xuxian Jiang from NCSU who have developed a tool to detect capability leaks in Android devices. Using their tool they found a number of capability leaks, such as being able to send an SMS, in various Android applications usually added by OEMs. Malicious applications can call the vulnerable apps and exploit the lack of protection around permission/capability use and therefore do not need to request permissions themselves. In a similar way we’ve exploited the Android Web Browser, although we are not exploiting a vulnerability due to bad coding, but rather using the functionality it legitimately offers to other applications.

In this demonstration Android’s power and flexibility were perhaps also its downfall. Other smartphone platforms may not offer the controls we are bypassing at all, and the multi-tasking capabilities in Android allowed us to run the attack almost transparently to the user. This power combined with the open nature of Android also facilitates the customisation of the system to meet bespoke security requirements. This is something we have even been involved in ourselves by implementing a proof of concept Loadable Kernel Module to pro-actively monitor and defend a client’s intellectual property as it passed through their devices. It is no surprise that we have seen adoption of Android research projects in the military and government as it can be enhanced and adapted for specific security requirements, perhaps like no other mobile platform before it.

I hope this demo was of interest and that it generates some discussion around the best ways to select and use apps which offer the least risk to your device and data.

Update 20-Dec-2011: As mentioned these issues are not new and have been discussed before

Re:TFA is blank

[Anonymous Coward]

Why do people feel so good about creating poor web experiences for themselves?

Re:TFA is blank

[A nonymous Coward]

Amazing web page. A security page that requires javascript to display. If you look at the source, the entire readable content a dozen short paragraphs at the end, each written on one line, and being mere verbaige around the real content, which is a video hosted elsewhere.

Somehow I don't think I'll be taking any of this site's suggestions very seriously.

Re:TFA is blank

[aitan]

Sorry, clicked wrong while moderating the post.

Re:TFA is blank

[Anonymous Coward]

You really can't view a webpage running Javascript?

Re:TFA is blank

[A nonymous Coward]

I use Noscript. Why should I trust some unknown web site to have good intentions and good skills? Further, almost all javascript I have seen is only used to track me or play with the ads.

No thank you. My screen, my rules.

Firewall

[Anonymous Coward]

Easily defeated by a firewall like iptables, which can be easily installed from the market if you have root.

Re:Firewall

[Anonymous Coward]

And if you don't have root, you can use one of the many remote root exploits to give yourself root access.

Re:Firewall

[Ethanol-fueled]

Pardon my naivete, but why would something as useful and non-destructive as iptables not be easily installed with the phone's default condition?

( signed, a guy who uses his ancient phone just to make calls and take the occasional low-res video )

Re:Firewall

[Overly Critical Guy]

Yes, it's perfectly reasonable to expect users to install and configure iptables on their cell phones. We know this because you wrote "easily" twice!

Re:Firewall

[Anonymous Coward]

There are apps in the market which have a nice easy to use interface.

Re:Firewall

[muridae]

So you would have the firewall prevent your browser from connecting to pages that aren't in your whitelist? Because that's how the exploit works, by using the built in browser to contact a webpage and then execute local instructions.

Re:Firewall

[Fri13]

If leaving out the rooting part... (what is app install from market + single click to root/unroot) the iptables is easy to use in Android

1. Install droidwall (or any other iptables firewall)
2. Start application and check/uncheck applications rights to have connection when in 2G/3G or WiFi mode.

I hope it would be as easy with Linux distributions....

Re:Firewall

[Ash Vince]

Easily defeated by a firewall like iptables, which can be easily installed from the market if you have root.

I am not so sure about that. In this case the actual exploit was using the built in web browser to talk to the internet so surely the only way you could block this with iptables is to block your phones default web browser from accessing the internet, surely that is not a great fix.

Re:Firewall

[Dog-Cow]

Practicality is not a hallmark of Android defenders.

No vulnerabilities?

[Hatta]

Unintended root access is a vulnerability by definition.

Re:No vulnerabilities?

[BlueBlade]

This doesn't give root, it just allows you to run a command within the context of the installed app. The app launches the web browser to pass data to and from a middleware server. So if the app itself doesn't have any specific access (including network access) it can still transfer data through launching a browser session.

It's more of a conscious decision by the android team. If you allow an application to launch an URL, then of course it can transfer data through the http session. However not allowing apps to launch a simple URL link would be very limiting, so they chose not to do that. I'm not sure there's a fix really, as this is a classic security / convenience problem.

Re:No vulnerabilities?

[Trisha-Beth]

In that case it's lucky the method in the article doesn't gain root access, and can do nothing beyond what the "shell proxy" app can do.

Re:No vulnerabilities?

[Culture20]

"Allow App 'Foo' to open a browser? Yes/No/Always/Never/Maybe/Sometimes/EverythirdTuesdayoftheMonth"

Re:No vulnerabilities?

[JAlexoi]

It's not root access. It's shell access.

Re:No vulnerabilities?

[shutdown -p now]

Interestingly enough, you get something of a kind if you install more than one browser on your phone - then, whenever a link is opened by an app, you'll get a dialog prompting you to select the browser to use for this protocol henceforth (and a checkbox to not ask again).

Unfortunately, the setting isn't per-app, so not as useful. Still, can be a handy trick for the more paranoid (but then they're probably using N900, anyway).

Re:No vulnerabilities?

[Anonymous Coward]

The fix is to ask for permissions that an app requires *plus* the permissions of other applications/services that it uses or depends upon.

Re:No vulnerabilities?

[rabtech]

This doesn't give root, it just allows you to run a command within the context of the installed app.

How many times do we need to revisit the MS Word VBScript virus problem before we learn from it?

Here are some obligatory automatic security fails (on any platform) that guarantee your wonderfully architected system will be oft and immediately bypassed:

1. Asking the user to decide. Users don't read dialog boxes and just click/tap to make them go away. They will often happily answer YES to the "Install unsigned ActiveX control" dialog so they can see the dancing monkey or play some game. How often do you think they will pay attention to what rights an app wants and make a reasoned decision about whether that is a good idea or not? (Hint: almost never)

2. Asking the developers to oh-so-politely make sure they use best-practices and don't have any exploits or holes. They can and will not only willfully ignore your security best-practices but in fact will go out of their way to hijack the system because *their* app is special and like totally has a really good reason for it man! (See apps that hijack the right-click menu/sys tray/startup group/install 15 services/drivers that all auto-start/etc on Windows and the awful state of many drivers).

3. Assuming that an app should be able to do what the user can do - Granted this is not a problem with a sandbox system but still... Apps can't be trusted. Even when there is no ill intent there can still be unintended exploits (or just bad designs like running in the background constantly draining the battery when not necessary - part of the reason iOS still doesn't let apps run continuously unless they have an explicit reason like audio playback).

4. Assuming the user has the time or a f**k to give. In most cases the computer, phone, etc is just an appliance and they don't know or care about automatic updates, patches, security, etc. They just want the damn thing to work and stop annoying them. After all... most dangerous things have warnings and/or safety features and don't require you to check the manufacturer's website on a daily/weekly basis to see what new way to kill yourself has popped up. It can be impossible to keep up with even for technically-minded people who happen to have busy lives.

Re:No vulnerabilities?

[Anonymous Coward]

I hear you can get the AIDS if you drop your Android phone in the shower at the state prison.

Re:No vulnerabilities?

[Anonymous Coward]

Well I've just lost a little trust in Android because of this decision.

I wonder what other Apps an App can connect with to use their permissions instead of it's own.

Re:No vulnerabilities?

[StikyPad]

A shell which provides a convenient attack vector for root access if and when a vulnerability is discovered/crafted.

Re:No vulnerabilities?

[Anonymous Coward]

Orly? So by your logic, "some idiot user" should just allow a random third party shell access to their phone?
 
This isn't a "Look at this cool thing your phone can do" article, rather it's a "look how easy it is to hack an unsuspecting person's phone" warning. The more idiot users that know about this, the better.

Re:No vulnerabilities?

[thsths]

> It's more of a conscious decision by the android team.

And what makes them decide this for me? Shouldn't this be a permission like so many other features of Android? I am asked whether I grant network access, and calling URLs should be pretty much the same.

Re:No vulnerabilities?

[Anonymous Coward]

app can specify specific handlers, not generic actions

e.g. most apps force the SMS intent, even my phone having several apps (gvoice, etc) that handles messaging, infact, gvoice is my default and i never see the dialog when an app calls the messaging intent. yet, some other apps just bypass that and go straight to sms.

Re:No vulnerabilities?

[thetoadwarrior]

If someone wants to know if their app accesses the network (ie cost them money) then they want to know under all circumstances not just something primarily made for net access. It's a flaw in Google's design.

Re:No vulnerabilities?

[JAlexoi]

Shell access is irrelevant in that case. Because the app itself would root the device without any shell access.
Even in that case the shell is ridiculously restricted on Android. You can't even run sqlite command from the app.

Re:No vulnerabilities?

[Neil Boekend]

You'd better have a Defy or some other ruggedised phone or it'll get damaged by the shower.

Re:No vulnerabilities?

[gl4ss]

and the point really here is that it goes around network capability.
so you can have an app that's not supposed to connect to the net make a connection and run things in linux side, even if just in it's own process.

and you can run sqlite on phones where the commandline sqlite app isn't removed by the oem, it is there in some models - but you can put it there, if it happens through having a shell or a program that takes in code and runs it is rather irrelevant though(well, what is a shell anyways..).

but there's something that's not too well known, even though it is old, old news. sure, android programs are java and ran in a sandbox, right? except that it's not really much of a sandbox in the common sense of the word. you can place linux binaries in the programs own directories and run them with the permissions the app has with a simple exec- so you can put a binary there that escalates some flaw to gain root for your shell.

Re:No vulnerabilities?

[VortexCortex]

Thanks.  I'm glad I'm not alone.

I actually do this: I make all the "best" security decisions default, and automatically applied.

Misbehaving apps in my scripting environment (well, user generated mods for a game engine) simply fail with an error message:
"Script Error: #42. - Returning to main menu."

If a user wants to be able to see those detailed dialogs such as:
  "Script Permission Error #42: MOD attempted a to connect to a domain not in your trust list.
  [T]rust: some.questionable.site.com [C]ancel and return to main menu.
      (o) Just this once  (_) Always"

Then they must enable them in the advanced options, otherwise the sane defaults are chosen automatically.

This means developers (modders) are more likely to avoid causing such errors since mods that include arcane instructions to manually enable things are shied away from.  There is an approved method apps can register trusted domains, and other possibly security sensitive capabilities (Like full disk access), and most modders will use this approach or avoid the needless permission since it gives a better user experience.

Unlike with Android, users can choose which features to allow or deny, and still run the app while deferring the decision to later (this allows sane defaults to be applied).  I think Android needs more granular Allow / Deny behavior than "Here's a list of all the shit this game can do: EVERYTHING.  Either enable EVERYTHING access or DON'T INSTALL this game" -- Guess which the user will choose?  "Install"

My approach is to allow automatic granular defaults to be applied.  So, by default when installing a mod "access this list of 3rd party domains..." is disabled.  Sane defaults are applied to [X] check or [_] uncheck each permission automatically.  A "[D]etails" option allows users to select the individual permissions.  Given that such security permission systems have been around practically FOREVER (The king and his family can access the crown jewels, Apache runs as the user Apache, with access to keyrings and files granted by groups -- access is denied when access is requested beyond its current permissions), I find it severely retarded that very few people actually employ granular permission controls...

My Firefox runs as the Firefox user, and is in the "browser" group, so it can't see any files its not supposed to,
like: ~/archive/taxes/

Even on most Linux distributions there's only the separation between User and Root by default...  Why should Firefox be able to access my ~/Documents/ folder?  We need to just run the Apps as their own users, but hardly anyone does.  The actual human user account simply has access to all the groups, like "browser", "server", "generic", etc.  So they can access the downloads, and what not without problems. (Hint: generic is a group that GIMP, Blender, LibreOffice, etc run under -- access to the ~/documents/ ~/design/ and other "user" home folders, but not ~/archive/taxes or ~/.mozilla, etc)

I see the "exploit" in TFA as an ignorant oversight by the Android devs.  Clearly: "Launch URLs in Browser" should also be a capability.
IMHO, the real issue here is lack of granularity due to an immature permission system, (which is ridiculous since Android uses Linux!).

Re:No vulnerabilities?

[StikyPad]

You're missing the point. If a new 0-day vulnerability is discovered tomorrow, you can write a new program to exploit it, or you can use your existing install base to deliver the payload without any new action on the part of the users/owners. Remote access to a system increases its attack surface. It's *always* a security risk, and it's only irrelevant until it bites you in the ass.

Re:No vulnerabilities?

[Anonymous Coward]

Unlike with Android, users can choose which features to allow or deny, and still run the app while deferring the decision to later (this allows sane defaults to be applied). I think Android needs more granular Allow / Deny behavior than "Here's a list of all the shit this game can do: EVERYTHING. Either enable EVERYTHING access or DON'T INSTALL this game" -- Guess which the user will choose? "Install"

Not all users. I was all gung-ho to get myself a phone I could program myself without paying to play in the "Walled Garden". So I bought an Android phone. That night, I went to install a few apps and saw that just about every app demands permissions it shouldn't need. I chose option 3 - return that POS and buy an iPhone. If the app store won't take responsibility for the security of the apps, fine. That's an acceptable compromise for the openness, IMO. But they damn well better give me the tools to do so myself - failing to do so is NOT a part of any acceptable compromise. Since they don't, I chose the lesser of 2 evils.

Re:No vulnerabilities?

[JAlexoi]

That is pretty much true of any platform - therefore installing any apps on any platform is a security risk.

Or Just a Local Shell

[Doc Ruby]

Until my phone's Android lets me run the Android Perl shell app on it without rooting, it's not "open", no matter what Google says. The source code might be open, at least "open readonly", and the binary might be "open execute" by hackers onto unauthorized hardware. But the OS instance is not open if it's not open to me as a user to invoke its API with an app that can do the job.

Re:Or Just a Local Shell

[Anonymous Coward]

Would a Ruby shell do? See if you can install Ruboto IRB. I could on an un-rooted Acer Iconia. YMMV.

Re:Or Just a Local Shell

[Anonymous Coward]

Android is "open" like a stripper's pussy. Pay at the door, look but don't touch.

Re:Or Just a Local Shell

[Baloroth]

I also can't use apt-get on Ubuntu unless I'm root. So... would that also make Ubuntu "not open" by your definition? Plenty of other things I can't do without root in Linux.

Do not confuse "security" with "closed." Don't know anything about the app you reference, but I'm guessing it requires privileges not normally granted to a user-installed app. For security reasons. That's pretty common to Linux in general.

Re:Or Just a Local Shell

[Archangel Michael]

You're right, right up to the point where you are 100% wrong.

The difference between Android running on a Phone and Ubuntu running on your Computer, is that with Ubuntu, you probably have ROOT control, even if you have to grant it to yourself *sudo", and type a password, to do it. On Android, you don't even have that ability ... by default.

Re:Or Just a Local Shell

[Lehk228]

I set up sl4a/python on my eee pad transformer without jumping any hoops

Re:Or Just a Local Shell

[Anonymous Coward]

This is trivial. Linky: SL4A

Re:Or Just a Local Shell

[assassinator42]

Are you talking about an existing "Android Perl" app that requires root permissions? Do you have a link?
I don't see why you'd need root access. You can download one of the terminal emulator apps and run anything within the context of the app.
You may need to figure out how to get it compiled, though.

Re:Or Just a Local Shell

[Anonymous Coward]

So if someone hands you a Linux box but doesn't tell you the root password, whatever distro that is running on there is no longer open source? Got it.

Re:Or Just a Local Shell

[Anonymous Coward]

Straw man argument alert! If you PAID someone for the computer and they didn't give you the root password, well the OS may be open source but are you really going to enjoy your new computer?

Re:Or Just a Local Shell

[bemymonkey]

If rooting consisted of entering "su" in a console and then typing your password/PIN or whatever, I'd agree with you - but have you seen the hoops some users have to jump through to get root on their Android devices?

Re:Or Just a Local Shell

[Ash Vince]

You're right, right up to the point where you are 100% wrong.

The difference between Android running on a Phone and Ubuntu running on your Computer, is that with Ubuntu, you probably have ROOT control, even if you have to grant it to yourself *sudo", and type a password, to do it. On Android, you don't even have that ability ... by default.

Actually, on at least one of my android devices I do have root permission just by doing some equivalent of sudo. That is the one I have reflashed with Cryanomod. It is still Android though.

But Oh, you were talking about the commercial devices produced by Motorola, HTC and the like? These companies have made a choice to close their devices and remove something that Android can easily do, but that is not Andoid, that is whoever produces the locked down device.

Re:Or Just a Local Shell

[Dog-Cow]

You are an idiot of the first order.

If you have shell access on a Linux server, but not root, does that mean that the source is no longer open? Google never promised that the system would be "open", only that they would provide source for anything based on Open Source.

Re:Or Just a Local Shell

[Dog-Cow]

I hope you ignite yourself when you burn those straw men.

Re:Or Just a Local Shell

[Doc Ruby]

A machine that I own and use that doesn't allow me root access is not open. If I have to reinstall or otherwise hack the OS to be granted root access, then the OS is not open - I had to open it, despite the OS.

Re:Or Just a Local Shell

[bemymonkey]

Ah, but there's a key difference - if you own that Linux server, you will most certainly be able to get root access.

Even if you own your phone, that's not always the case.

Re:Or Just a Local Shell

[Doc Ruby]

If you were the owner of the Ubuntu machine, and no other person had the root password, it would not be open. That is the situation with Android.

Re:Or Just a Local Shell

[Doc Ruby]

So Motorola/HTC/etc are the ones who closed the Android instance on the phone. That doesn't argue that it's open, it explains how it is closed, which therefore agrees that it's closed.

I'm not talking about who's to blame, I'm talking about the condition of the OS instance on the phone, the inarguable reality for most people.

Re:Or Just a Local Shell

[Doc Ruby]

Running the Terminal Emulator shell app gives "permission denied" to any invocation of any executable or attempt to read any dir or file. Maybe rooting the phone before installing it would help, but that's my point about how the OS is not open.

This isn't even close to new

[StealthHunter]

Woah, if you install an app, it can do stuff! Presentations (Defcon 18), numerous student thesis and a number of academic papers do nearly (or exactly) this. (agreed that apps w/o INTERNET permission probably shouldn't be able to leverage the browser, etc, but again, not new or newsworthy)

Re:This isn't even close to new

[gl4ss]

well, the "big" thing here is really that browser doesn't need NETWORK capability.

a little off topic but,,,

[phrostie]

what is the best way to install vim to my android?

TIA

it is not root access

[craftycoder]

What happening here is that the app he installed opens the web browser to when you lock the screen. The app is then, in here in lies the secret sauce, is able to get the commands from the the browser is receiving. The browser part is simple, it can poll looking for input. How the app gets that input is interesting part. I don't know how its doing that. It may have created a callback from the browser to there app. Android has excellent inter process communication tools, but I don't know how he is doing this from an app he doesn't control. I've only thought about it for 5 minutes though. With this app and another app you control, this exploit would be trivial (one with internet access and another with sdcard access for example). I think any app can execute process with would give it access to the shell. That doesn't mean it has root access, but Android will let you view much of the file system without root. You cannot get to private app data storage, but you can see the sdcard and other basic parts of the file system like /framework or /etc.

http://developer.android.com/reference/android/os/Parcel.html this shows inter-process communication.
http://developer.android.com/reference/android/content/Intent.html this shows how to launch the browser.

Re:it is not root access

[shutdown -p now]

Yup, so basically "gaining a shell" is not at all interesting here, since it doesn't let you do anything the app can't otherwise do. The real gem is being able to do network communications without requesting the appropriate permission for your sandbox when installing.

Re:it is not root access

[craftycoder]

The magic is getting the browser to return its data back to the app without privileges. That turns out to not be hard either. I found an example and posted it below. With this, you have a functional two way link from app without privileges to webserver and back. I'm not impressed and I don't consider this an "exploit". If you want a system that allows apps to communicate with each other, which we all do, then you have to be careful of what you install on your phone. This is better than a PC which almost always has full root access. This is just voyeur access...

http://www.android10.org/index.php/forums/49-other-coding-problemsarticles/1575-example-communication-between-an-activity-and-the-browser-callback

Re:it is not root access

[shutdown -p now]

It is an exploit in a sense that Android does have a "permission to use networking" for apps, and if I install the app that does not have such a permission in the Market, it shouldn't have network access.

You've got a point regarding inter-app communication. Perhaps that should be a separate permission; or, better yet, prompt it whenever the app tries it (though then the app could just open some kind of "about" page in the browser on first launch, user gives it permission... and then it does the whole thing again).

Re:it is not root access

[craftycoder]

I'd support a permission for launching intents originating outside this signed package. Starting an Activity, like a new screen in the current app uses the same code as starting the browser or any other activity. If Android is able to tease apart the difference, and I think that would be possible, then that seems reasonable. I have an app that launches a service for listening for an Accessory (ADK) mode device that is outside the original package because ADK requires Android 2.3.4 but the app only requires 2.2. I compiled them separately because of the different kernel requirements but they still talk to one another. While I'd be VERY put off if I could not do this at all, I am ok with documenting it to the user.

Re:it is not root access

[gl4ss]

well, install opera, when it asks you which browser to use to fill a browser opening request, choose opera and don't tick the box to open it always if you think it might work through opera too.

anyhow. on maybe 80%+ of android phones, if you get shell access you can run some exploits to get root access.

Why does Android forbid root to the owner?

[Morgaine]

This is a question which doesn't seem to get asked much, probably because Google is an unmovable behemoth that's not really interested in the owners of devices, but only in advertisers. Nevertheless, it needs to be asked.

These cellphones and tablets belong to us, they don't belong to the device manufacturer, nor to the cellphone service operator, and even less to Google. They are ours. So why are we, the owners, forbidden direct root access to our own devices? It's like owning a Linux desktop without root, or owning a Windows machine and not being allowed Administrator access.

It's daft, and it's completely wrong.

Currently the crackers seem to have easier access to root than the device owners. Google, stop navel gazing and caring only about profit, and do something for users for a change. Add to standard Android a legitimate method for users to have access to root on their own devices, so that "rooting" becomes a thing of the past. It's not your right (nor anyone else's) to deny it.

Morgaine.

Re:Why does Android forbid root to the owner?

[Anonymous Coward]

good rant.

It's just a pity that it's 100% factually incorrect.

Re:Why does Android forbid root to the owner?

[0123456]

It's like owning a Linux desktop without root, or owning a Windows machine and not being allowed Administrator access.

Uh, 'Secure Boot', dude. With Windows 8 you will only have whatever control Microsoft allow you over the Windows computer you thought you owned... if they disable admin access in Windows 9, you won't be able to patch the loader to re-enable it because it will refuse to run.

Re:Why does Android forbid root to the owner?

[Anonymous Coward]

Googles branded phones basically do provide root access. You have to enable it, but it's no more complicated than typing in a couple commands. Don't blame them for what the carriers impose on other models.

Re:Why does Android forbid root to the owner?

[Anonymous Coward]

So why are we, the owners, forbidden direct root access to our own devices?

If having root access is important to you, then purchase a device that allows it. My Nexus S allowed me root access quite easily. I can also compile and install Android onto my device all by myself.

Re:Why does Android forbid root to the owner?

[mjwx]

This is a question which doesn't seem to get asked much, probably because Google is an unmovable behemoth that's not really interested in the owners of devices, but only in advertisers. Nevertheless, it needs to be asked.

For years we've been saying that local users should never operate as administrator by default. Now someone is doing it, you're getting pissy? Double standards much.

Besides this Google has answered it. Root should be as simple as SU.

The enforcement of non-admin privileges is done by the Android manufacturer, they do it because the carriers demand it. Want to stop it, stop buying phones from the carriers and make sure they know.

Re:Why does Android forbid root to the owner?

[Anonymous Coward]

How so? I have had no luck getting root on my Dell Streak 5* and Archos 43** simply to change the LCD density. Any apps to do that require root. It was a cinch to do on my first Android tablet, a Pandigital Novel once I learned of the technique to gain root with an exploitable vulnerability. And that is the trick for getting basic control of your Android device: gaining root by means of EXPLOITing a vulnerability - just to have basic control like changing the lcd density or installing a quick reboot app. Ridiculous!

* If I pursue it diligently enough, it appears I could root the Dell, but have not wanted to mess with running Windows enough to go through all those hoops.
** Only working exploit a while back for the Gen 8 (whatever the 43 is?) Archos models was a mysterious EXPLOIT posted on xda-devs by someone calling himself "Archangel". That caused no end of discussion and anxiety as any number of gurus (and the rest of us) tried to figure out how it worked as he never divulged how he did it - unlike most other root'ers. All that just to change some basic settings or get some convenient features only possible by means of rooting???

What other GUI-enabled OS is that locked down against its own users for such simple, legitimate functions ?? (dunno about iOS, but if so, that explains "jail breaking").

Re:Why does Android forbid root to the owner?

[Anonymous Coward]

And obviously Windows 10 will make you eat puppies and punch your grandma in the face! This is fun!

Oh wait, you were trying to be serious?

Re:Why does Android forbid root to the owner?

[Anonymous Coward]

With Windows 8 you will only have whatever control Microsoft allow you over the Windows computer

Now you've ruined it for me. I was looking forward to Windows 8.

Re:Why does Android forbid root to the owner?

[Anonymous Coward]

You're wrong and you're just repeating group-think about a feature that you don't understand. Get informed about secure boot and the TPE.

Secure Boot will allow you to boot code that the TPE recognises. This just means it needs to be signed by the correct key. I would expect that all of the commercial distributions of Un*x will have solutions for this because they'll be signed up and will have paid whatever it is to be a part of the group that gets signing keys.

If the signing keys for the TPE BIOS ever become public or accessible to people outside of the trusted circle, then the TPE will be useless because those with nefarious intentions will be able to produce correctly signed executable data that is infected.

I expect that Secure Boot will ultimately fail because someone in a position of responsibility will either unintentionally leak a key, create a path to the signing keys that is insecure or will simply be bribed into it.

Re:Why does Android forbid root to the owner?

[Anonymous Coward]

Googles branded phones basically do provide root access. You have to enable it, but it's no more complicated than typing in a couple commands. Don't blame them for what the carriers impose on other models.

No, you can unlock the boot loader on Nexus devices. You cannot root them by "typing in a couple commands".

Re:Why does Android forbid root to the owner?

[Anonymous Coward]

For years we've been saying that local users should never operate as administrator by default. Now someone is doing it, you're getting pissy? Double standards much.

Android doesn't deny operation as root by default. It denies it altogether, because it does not provide a standard legitimate and fully supported "su" or root login app that would allow an owner to become root whenever they desire simply by entering a password.

Instead, the owner has to use unsupported and risky methods to crack their own device.

Imagine if you had to do that on your own desktop computer. It's totally not right.

Re:Why does Android forbid root to the owner?

[Anonymous Coward]

Google enables you to install the superuser apk and binaries on all the Nexus phones. So, yeah. You're wrong.

Re:Why does Android forbid root to the owner?

[bemymonkey]

While I agree with your premise somewhat, you're confusing a few things.

Google's phones (Nexus) are all easily unlockable and rootable. That's no accident...

The problem is the carriers and manufacturers, who just love locking down their phones to turn them into featurephones with apps... no doubt, Google should be looking for a way to force complete openness on both the carriers and the manufacturers, but it looks like that might be far easier said than done...

Now if only Google would release Motorola's next few phones completely unlocked (fastboot oem unlock, or what was it?)... then I'll buy a Droid 5.

Re:Why does Android forbid root to the owner?

[bemymonkey]

Google didn't lock down your streak - Dell did. Same thing goes for the Archos thing... next time, buy Nexus or research properly (whether or not a viable root method is available for the device you intend to buy) before purchasing.

Of course, (IMO) this situation shouldn't exist in the first place - Google shouldn't be allowing carriers and manufacturers to lock down phones this way at all... but that's a different topic. :(

Re:Why does Android forbid root to the owner?

[PolygamousRanchKid]

It's like owning a Linux desktop without root, or owning a Windows machine and not being allowed Administrator access.

. . . which is why I bought a Nokia N9 with Meego Linux. Do you want root access? Switch on "Developer Mode", which warns you of the risks, and you must press "Accept".

. . . and this is why I will (hopefully) buy a Tizen device in the future. A post recently to the Tizen mailing list stated something like, "This will be a real Linux distro, where you can do anything, not like Android."

There is no reason to whine, moan and complain that you have to jailbreak Android for root access. This is already well-known, clearly stated and is there for a good reason: not to let dumb-asses screw up their phones.

I prefer the Nokia N9 Meego model, which lets me choose to have root access, but makes me responsible for accepting the consequences.

Re:Why does Android forbid root to the owner?

[Fri13]

There are many phones what are easily rootable. Depending the country where you live.

Example all Android phones in my country are unlocked to carrier and SIM. So you can do what every you want with them. Rooting phone is just installing root application and pushing button.

And user does not even void varranty because that unless problem is caused by software. (if your MicroUSB plug brokes so you dont get good connection, it does not matter if you have third party ROM installed. But if your CPU burns and they find out you have third party ROM with custom CPU scheduler and overlock... you dont get anything).

Re:Why does Android forbid root to the owner?

[Fri13]

. . . which is why I bought a Nokia N9 with Meego Linux.

N9 comes with Harmattan aka Maemo 6.0.
MeeGo is Maemo 5.0 + Moblin 1.1

Harmattan is not 100% compatible with MeeGo and almost only way is to use pure Qt in your applications and even then repackage your software to RPM and DEB to deliver both.

Even Nokia developers needed to explain that Harmattan != MeeGo but it is just a marketing....

Re:Why does Android forbid root to the owner?

[rastoboy29]

It's not Google that denies us root, but the phone manufacturers.  They alter Android so that it is harder to get root.

Check out the actual Google Nexus line of phones, and you can get root with a simple command--basically "gimme root".  No hacks required.

Re:goog: pls try harder!

[Anonymous Coward]

Is this the iphone that was rooted by downloading a PDF?

There's a reason

[Anonymous Coward]

They don't close "flaws" like this.

What are you smoking buddy?

[0ld_d0g]

"Secure Boot" is nothing new. They had that over ten years ago in their xbox game consoles. Its a simple chain of trust where the OS is loaded in a modular approach starting with the BIOS/UEFI handing off control to the next link only after cryptographically verifying their signatures. It has nothing to do with "locking" you out. Its a method to be reasonably sure that the OS is not compromised w/o hardware access (disabling secure boot is a bios option IIRC). If they wanted to lock you out from admin, they would simply not ship the OS with any way to allow you to create an admin account. Secure boot is irrelevant here.

Without resorting to paranoid delusions and conspiracies I don't see how Microsoft benefits if you don't have admin access. As it stands on windows you require admin access for dozens of important things like installing drivers, applications, system maintenance, debugging applications and many such tasks. Besides Windows would never change the existing user & process privilege model if they want to continue to be backwards compatible with previous versions. Hell they include a copy of the heap mnager from w95 just so broken programs continue to work. http://technet.microsoft.com/en-us/magazine/ff625273.aspx

Re:goog: pls try harder!

[PNutts]

Is this the iphone that was rooted by downloading a PDF?

You must be referring to the two exploits in the previous version of iOS that were quickly patched. Apparently Apple has trouble porting functionality to subsequent versions of iOS. Who says Apple can't learn anything from Google?

Re:goog: pls try harder!

[noh8rz]

Your past comments are racist and I don't interact with that sort of people

Re:goog: pls try harder!

[spyder-implee]

You misspelled mum.

Erm

[ctnp]

Couldn't find anything mentioned in this thread about how it was the _simulator_ he was demoing, not an actual device... Big difference.

Re:Erm

[Fjandr]

The simulator was for ease of recording the video, not because that's the only place it was tested.

Not new, but scary!

[nullchar]

Right, big deal, the app calls the browser to do something in the background while the screen is locked. However, you may be scared after reading the following PDF Systematic Detection of Capability Leaks in Stock Android Smartphones -- I was!

Jump to page 9 for the table.

Three HTC phones allow rouge apps (without the defined permissions) to record phone calls and send SMS! The SMS example is neat as they broadcast an intent with the phone number in it; then stock apps on the phones actually send the message. Also, the Samsung Epic 4G allows rouge apps to follow a similar method to wipe the phone to factory defaults! Most of the exploits are in the default packages that come with the bloated firmware from either the device maker or carrier. The Google Nexus phones were the safest as they had the fewest apps installed.

From the PDF:

"...by simply including a premium number in the intent, the built-in app will start sending SMS messages to this premium number!"

"For example, the explicit leak of CALL PHONE capability in Samsung Epic 4G involves passing a component a “technical assistance” phone number, which it calls after considerable processing. Similarly, all the tested HTC phones export the RECORD AUDIO permission, which allows any untrusted app to specify which file to write recorded audio to without asking for the RECORD AUDIO permission."

Maybe use only Opera or Firefox or (other browser)

[Anonymous Coward]

So, Google has made a browser that ignores our rights to privacy... Are you surprised?

Maybe Opera (from Norway) or Firefox (from all around Earth) does not do that...

Does anyone know for sure if this exploit is possible in other, quality, Android-ready browsers?

I find this to be a good thing

[LostMyBeaver]

I did some experiments a long while back... the most interesting one was releasing a VNC viewer to Version Tracker which during installation popped up a huge license message which highlighted in bold print "Do Not Install This App... It includes a trojan and by clicking continue below, it will also gain root access and add the text 'Ha Ha Ha' to the heading of every Word and text document on your file system". It did not actually do that, but it did actually call home and provide statistics regarding the number of times the installer was opened, whether the user just clicked through, whether there was any form of anti-virus on the computer I knew how to check for and then it would call home each time the VNC viewer was run afterwards. As a bonus feature, it also popped up a fake "look-alike" dialog to ask for the administrator password to install the program... it would then pretend like the user typed something wrong and then pop-up the real dialog. I didn't transmit the passwords... but I did collect stats of who actually typed their password.

Shockingly, because Mac users were so damn gung ho on how absolutely secure their OS was, there was an over 90% installation rate. 40% used the application more than once. It took 6 weeks for the app to be taken down... and people were still downloading it even though the comments screamed about how it was a virus.

Microsoft Windows 7 is EXTREMELY secure now because of several things...
1) People DON'T trust Windows apps like the used to... they're skeptical about viruses.
2) People run anti-virus software... which may be useless on zero-day bugs and often can be more harmful to the user experience than any virus they can block, but they run it.
3) Microsoft bought a gazillion anti-virus vendors and has produced one of the best anti-virus programs I've ever seen... they give it away for free... they respond QUICKLY to new viruses and by having access to all system internals, produce applications that can remove even the nastiest viruses from the system.
4) Microsoft now listens to their anti-virus group and makes changes to the OS to make it more secure from user blunder. Things like the ever annoying "Are you sure you want to run this app?" and also, in Windows 8, trying to deter the user from installing applications that are in their central online as harmful or incompatible.

Apple iOS is pretty damn secure because it's a bit harder for the vendor of a malicious app to get an app into the app store. If someone chose to add a virus/trojan/etc... to the app store, it's taken down very quickly if it's detected as such (unless we're talking about apple approved trojans) and the amount of information that has to be gathered on an app developer before they can publish an app makes it much harder to put things there without there being some recourse. Unlike the rest of the Apple Stores, it's not possible to purchase through PayPal. A developer has to use some identifying form of payment. Prepaid credit cards do however work... so if you get one of those and forge some info on it... you're good. Still... quite a big obstacle.

Mac OS X is still a rats nest of security hell as almost no one installs anti-virus software on it. The Anti-virus companies don't even take it seriously since the market for Mac sucks... most Mac anti-virus software really only checks to make sure you're not transmitting known Windows viruses through e-mail. People still trust it too much and the market for Mac is still probably heavily dominated by people who want to use FaceBook but can't find the 'Any Key'. They bought the Mac because the guy at the store said "You want a Mac because you don't ever have to worry about viruses" and they trusted the guy who was obviously a highly educated computer expert working for $10 an hour at a company who treats their employees like slaves and makes them wear a stupid blue shirt.

BlackBerry... haha I won't even begin to bash how useless their device security is. What'

Re:I find this to be a good thing

[Anonymous Coward]

You know nothing of QNX. Their coders are good. Real good. About 10 years ago they had an x86 version of their OS that had a nice desktop environment, common network drivers, and a nice web browser. The entire thing booted and ran off of a 1.44 MB floppy disk. Their coding guidelines work very well.

Re:I find this to be a good thing

[minus9]

"Microsoft Windows 7 is EXTREMELY secure now because of several things...
1) People DON'T trust Windows apps like the used to... they're skeptical about viruses."

Windows is EXTREMELY secure because of its history of MASSIVE insecurity and the tens of thousands of viruses?

Microsoft logic at its finest.

Re:I find this to be a good thing

[Fri13]

Tell which does:

A) Software code quality and software design
B) Software popularity among people .... matter when it comes to bad security?

As you are saying that security is great if there are few users.
So if a few banks use software A, it is safe because it is just few users.
But if millions of users use software A, it is unsafe because it is lots of users....

You are saying that code quality and software design does not matter at all.

You are not talking about risks what crackers need to think as well.

Example, a even typical simple minded criminal knows that he has lower risk when robbing people on parks and pick pocketing people on streets to get a few hundred bucks a day/week, than robbing a bank and gain hundreds of thousands or even millions.

You dont want to go rob a bank, because their security is much tigehter. They have been designed to protect money better.
But you want to rob people on streets and parks because normal people are not as well protected. Even that you gain less and you need to do multiple times it, it is much safer thing than to go after target with better security.

A robber does not want to go rob a know martial arts person on street with a knive, you use a gun then and even then it is even more riskier to get caught.

Which one you would want to rob, a bank or a millitary base? School or Police station?
Private house or a corporation HQ?
Private house or a bank?

Private house with top of the class security system (armored doors and windows, strengten walls and cameras, walls, dogs and alarms) or a privat house with just the lock?

The software popularity means nothing. It is about code quality and design what matters.
You can write almost perfect code or design software so well that there is just a 0.001% change it gets cracked. And that does change even if you distribute it just to 100 person or to 50 million person.

The user is usually problem. If you can get user to skip security measurements, you are in.

Re:I find this to be a good thing

[Anonymous Coward]

".. and the hundreds of thousands of viruses"
T;FTFY.

Re:goog: pls try harder!

[Anonymous Coward]

Also, you didn't capitalise your "T", misspelled "that's", misspelled "your" and failed to use a period at the end of your sentence. Furthermore, you meant to say, "that's what I said to your mum", not "that's what your mum said."

I guess Google usually corrects all that for you.

Devil's Advocate

[morgauxo]

I love the fact that I can root my phone. If all the security holes were fixed would that still be possible? As far as I can tell nobody has ever taken advantage of any security holes on MY phone to cause me any trouble...

Re:goog: pls try harder!

[Dog-Cow]

You deserve torture.

Sandboxen should be as limited as chroot

[sgt scrub]

If the sandbox isn't contained like a chroot environment it is a security issue and needs to be fixed. This reminds me of when web hosting services gave ftp access to users yet placed user content in /home directories. ie. Everyone's content was accessible by anyone with an account. Using user/group restrictions is a long way from sandboxing, IMHO. Linux is perfectly capable of creating chroot environments for daemons.

Its ok, I'm on Verizon

[Anonymous Coward]

As the commercial for the 3G iPhone on ATT shows I cannot access anything while using my iPhone on Verizon. So I am safe as I am using Verizon and thus my Android phone can clearly not access things while on the phone.