Comment by kiallmacinnes | Hacker News Reader

Comment by kiallmacinnes | Hacker News Reader

Parent Full thread

As another reply to your post says, paraphrased, allowing applications to escalate privileges is absolutely less secure than not allowing applications to escalate privileges.

This really has nothing to do with services not working because root is enabled, instead it has everything to do with companies (Netflix in this case, or Google for Android Pay in your example) preventing widespread theft of employee/customer data.

Even the most cautious users can accidentally click "allow" by mistake. Here's a example of how that might happen:

Build an app that some user wants - maybe a game. Make the user click a "Start" button to play. Time how long between presenting the button and receiving the click, after a few rounds of this, wait a fraction of a second less than the average time and trigger the sudo call which in turn usually triggers an allow/deny popup.

Did it register with you in time, or did you click allow? Did you even notice it if the game starts anyway? Probably not! Netflix just gave an attacker an entry point, and Google just lost the confidence of their banking partners, who are likely looking for any excuse to avoid working with Google (and Apple etc) anyway.

A good IT department has to protect the company from risks like this, and nothing the company requires you to do will require root (There are obviously exceptions, but the number of employees worldwide who fit this bill, outside of phone OS development, is likely less than a 5 or 6 figure number).

If you need root for personal tasks, and the company isn't happy with root, then they are entirely within their right to deny that device access to company systems.

Listen, I'm with you. Root is special and granting root to ~stuff~ should be something you don't do on a whim.

That said: I question that services should stop working if I have the ability to grant root. Reasons:

1) Maybe I know what I'm doing (honestly .. I consider myself capable and still have cringe while writing this)

2) Your software isn't immediately compromised in its core functionality if _I_ own my _own_ device.

For Netflix, this feels like another failed attempt to close the analog hole. Android Pay and whatever else might try to be your wallet (I'm a huge fan, as you might notice in this thread) should be able to withstand that. Otherwise it's just a crappy payment system.

I can pay stuff from my PC (various operating systems) and I do have root (or the equivalent permissions). I also own - as I stated in my original post - a CC that allows me to spend money freely. I don't know how hard it would be to copy it physically, but you'd be able to strip the core details (name, number, CSC) in a couple seconds/with two pictures.

Why is the CC secure, but a rooted phone isn't. Ignore Netflix, they're brain-dead and content related DRM isn't what I'm going for. I'm asking why random legitimate services refuse to work on a phone, because .. the owner actually seems to own the device?

> 1) Maybe I know what I'm doing (honestly .. I consider myself capable and still have cringe while writing this)

My example kinda covers this, phones really are getting faster... It's no longer a case of "I know what I'm doing" when it now comes down to human recognition and reaction time. In other words, you clicked allow before your brain had time to stop you. How do you prevent this?

> 2) Your software isn't immediately compromised in its core functionality if _I_ own my _own_ device.

100% agreed. For the Google Pay example, fair enough. It's your credit cards, and it's harder to come up with a counter point.. For the OP / Netfix example, it's not your data, and likely not your device - or - by connecting to company services, you've basically agreed it's not yours (This could be a whole sidetrack on it's own! :))

> Android Pay and whatever else might try to be your wallet (I'm a huge fan, as you might notice in this thread) should be able to withstand that. Otherwise it's just a crappy payment system.

Credit card companies are generally responsible for theft of money where you remained in possession of your card at all times. Sure, they really hate admitting it, and gathering the proof is hard, many times impossible. But that doesn't change the responsible party when the proof is found.. Given this, it's easier for them to accept less secure alternatives (e.g. the US's reliance on signatures).

The rise of NFC credit cards has changed this somewhat, if a credit card hands out all the details needed to make a purchase to anyone who bumps into you on the street, possession is now not the only factor, and banks have built safeguards around this (e.g. max transaction size, max NFC transactions before being required to enter your PIN).

Google with Android Pay must prevent that same bump on the street from stealing their customers money. The cell phone payment version of this comes in the form of other apps on the device, hackers breaking into the phone remotely, etc. With a rooted device, or a device using unknown firmware[1], all bets are off.

> I can pay stuff from my PC (various operating systems) and I do have root (or the equivalent permissions).

And this is a security hole, granted it's one I wouldn't want to see shutdown, but it's still security hole. I don't have any good answers here, but I do look forward to seeing a solution that works while letting me keep root access on my Linux box!

> Why is the CC secure, but a rooted phone isn't.

I'm think I've mostly covered this, but you're looking at two totally different landscapes. They just cant be compared in the same way.

> Ignore Netflix, they're brain-dead and content related DRM isn't what I'm going for.

While I'm no DRM fan, this entire article is about Netflix's corporate employee device security, it's nothing to do with DRM or content..

[1]: Unknown firmware in this case means firmware google doesn't trust - unrooted AOSP built from a unknown manufacturer can't be trusted any more than rooted firmware from Google itself.

I don't see how protection from hostile NFC and protection from rogue applications are related. You want both, ideally, but the increased difficulty of solving problem 1 on a phone vs. desktop does not make it harder to solve problem 2 on a phone vs. desktop. So I think you're wrong to say that it's "two totally different landscapes".

Ah, I was suggesting that comparing "I have a CC in my wallet and can do stupid things with it" to "I have a CC on my phone now others (hackers, bad apps) do can evil things with it" are two totally different things.

I was drawing parallels between hostile NFC readers and hostile apps/hackers :)

But the more important comparison in those posts is not CC in wallet. It's that CC on desktop computer has no restrictions.

"hackers/hostile apps can do evil things on desktop" is nearly identical to "hackers/hostile apps can do evil things on phone"

So while in a vacuum you could argue that you need to protect against hostile apps the same way you protect against hostile NFC, it's a weak comparison. While the treatment of hostile apps on your heavier home computing device is a super strong comparison.

I'm not sure I agree it's a weak comparison, mostly because I think we've made a whole bunch of bad decisions in how we handle things on a PC.. The PC was born in a different era to the smartphone, and it's treated as such.

Example: CVV numbers, these are needed for "Card not present" transactions are must not be saved (e.g. no browser will save them). Using your phone for an NFC payment on the other hand does not need this number.

Yes, this is a tiny detail. But this detail entirely changes the share of responsibility between the consumer/merchant/payment processor/bank.. This is usually reflected in the different fees that are charged for different types of transactions, card swipe vs card not present vs Chip+PIN vs NFC.

Assuming that just because a CC number + errata stored on a PC can be stolen an abused, that the banks etc should just let me do that on e.g. Android Pay is just wrong..

Nobody is stopping you from creating a text file on your phone with the card and CVV numbers, but don't expect to be able to use that text file as a NFC payment method!

Edit: in case I wasn't clear (I know I wasn't, because I kinda forgot to say it ;)), once your phone is untrusted - as in untrusted by the bank etc - everything stored on it may as well be that plain text file as far as they are concerned.

> In other words, you clicked allow before your brain had time to stop you. How do you prevent this?

The simple solution to this specifically (which I think has been implemented already anyway for some Android rooting options?) is to have a few seconds of delay where the "Allow" button on the root permission request is greyed out.

> In other words, you clicked allow before your brain had time to stop you. How do you prevent this?

The best SU apps have a timeout on the popup specifically to prevent this. I specifically use phh superuser (or, rather, MagiskSU) which has a 2 or 3 second timer from when the popup shows up till you can press accept.

I can no longer reply any deeper on this thread, must have tripped a reply limit :) Time for bed right after this!

Re adding a delay to counter this, see my other reply here https://news.ycombinator.com/item?id=13701227 - a delay isn't enough..

> My example kinda covers this, phones really are getting faster... It's no longer a case of "I know what I'm doing" when it now comes down to human recognition and reaction time. In other words, you clicked allow before your brain had time to stop you. How do you prevent this?

If this really is a problem, the OS could pop up a question such as "This app is requesting escalated privileges", and then wait ten seconds before popping up the allow/deny buttons so the user doesn't click blindly.

May have nothing to do with it but paying with CC details pretty much always has some traceable chain to the person who is gaining from the fraudulent activity. Contactless payment does not. Therefore a contactless scam could yield higher gains with lower risk than traditional cc fraud, and this poses a huge risk to any payment providers.

I'd tend to somewhat agree, but differ in what I think the big risk is - your cell phone has an internet connection, and a hacker in $foreignCountry can get to it..

The scope of risks are so significantly larger than the traditional "people who can place their hands on your wallet, or read the number while you have it in the open"...

Agreed - I said the same elsewhere on this thread

> failed attempt to close the analog hole

Stethoscope has nothing to do with user's of Netflix's service, and the DRM on it. This is for Netflix employees, on IT managed smartphones. This could have just as easily come from any of a number of other companies that issue phones to employees.

The only argument I would make against your points 1 & 2 is that I as a developer can't assume that a person with a rooted device knows what they are doing. For instance... I have a number of friends that have purchased rooted devices for the sake of using things like Kodi, against my advice. They do not understand their devices, or why downloading movies that hit the theater that day is illegal b/c they legally downloaded Kodi or bought a Kodi device legally. I am constantly having to fix/wipe them because they dont even understand the basics of security, ( i.e. they click ok on every popup without reading them, etc). Fortunately they pay me as I have refused for many years now to give free support, even to family. Anyhow, whenever my friends buy phones and other media devices, they almost always without fail and without asking my advice, purchase rooted ones online. Hell, for all they know, those devices could have software on them specifically for keylogging, etc.. and they would never know. So yeah, you can't assume a rooted device is in the possession of a competent user.

>Build an app that some user wants - maybe a game. Make the user click a "Start" button to play. Time how long between presenting the button and receiving the click, after a few rounds of this, wait a fraction of a second less than the average time and trigger the sudo call which in turn usually triggers an allow/deny popup.

I would consider this a software fault. Your SuperSU-or-equivalent app should do something similar to what Firefox does for downloads (the button is greyed out for a few seconds before you can click it).

Absolutely, 100% agree. I'd go further, and require a password or pin too.

But - they don't currently do this, and there's no way that I can think of to reliably, as a third party, validate SuperSU etc is actually doing this.

EDIT: Also, some users really are.. ill informed and gullible. I hate saying it, but a large number of employees even at a tech company will click accept after a quick popup that says "For best 3D performance, we need root access to use your phones graphics chip directly".

My main reason, or probably only reason to root my devices is to populate the hosts file with anti-advertising entries. Which may be safer than a device that is exposed to all the advertising crap.

And this is one of the few reasons I envy iOS users, Apple shipped ad-blocking APIs of some kind (or did that actually come out yet/ever?)

Google will likely never do this :(

You can do this with an on-device VPN, which doesn't require root: https://github.com/M66B/NetGuard/blob/master/ADBLOCKING.md

The app is also on the Play Store, but the adblocking features are only in the Github version (presumably Google will not approve this functionality for Play Store apps).

Reply on news.ycombinator.com