Hacker News Reader

Comment by asdfasgasdgasdg | Hacker News Reader

Wait. The vulnerability report says, "Abusing the Accessibility privileges, ..." the trojan can steal your OTPs. If you give a program accessibility privileges, it can read the screen. Is that all we're talking about here? What is the proposed mitigation that Google should implement on the app? You can't block accessibility on the OTP app because then blind people will not be able to use it.

View on HN

There is a huge amount of push in media to cripple our devices because some users don't want to reason and use them responsibly. Because Apple limits something, the assumption is that every other platform now must be limited in the same way and prevent their users from running more powerful software themselves. Because some of them might cut themselves approving too many things.

I don't like that viewpoint.

> some users

While that's technically the truth, it doesn't represent the actual state of events. 99%, and probably 99,9% don't use their devices responsibly. And then companies that bare no responsibility for the actual hack still suffer PR damage, because journalists don't report responsibly too.

It's not necessarily a good thing, but it is a lesson the software industry is going to have to learn.

For example, take the story from a little while back about how Gmail add-ons could access your messages. Any programmer looks at that situation, and they think, "Duh... OF COURSE an add-on could access your data, because how else on earth could it possibly work?"

But a non-programmer doesn't think this way. They think, "Gmail is a platform and a service that I use, which is run by somebody that I'm supposed to be able to trust to handle all that stuff for me. They ought to reason through all these things before they offer it to me." They very well may not have a good enough understanding about how software works to reason through the implications like we can. It isn't self-evident to them where your data goes and what will happen to it if you do this or that. moreover, Gmail (and tech generally) isn't the center of their universe, and they may not realize these add-ons come from a third party or may assume a certain level of vetting would be done if they do.

Whether this expectation is right is one question. In theory people ought to take responsibility for their own choices.

But putting that question aside for the moment, when designing a product, we ought to never forget that many users lack either the knowledge or the inclination to think through all this. You're building a product that you're going to hand over to users, and a lot of users, maybe even the majority of them, are going to approach it this way. I don't have a great solution to offer, but blindly assuming that all users are knowledgeable certainly isn't the right path.

I recently had a discussion with someone who complained about the Gmail permission dialogue when adding his Gmail account to the Windows 10 mail program. He was absolutely convinced that he will not agree to giving Windows permission to view and send emails for him and instead requested that Google and Windows enter a contract that only allows him to do that.

It was completely impossible to explain to him the technical background (e.g. that him sending an email through the program and the program sending an email by itself is technically the same thing for Gmail) and he wouldn't accept that Google is quite rightly informing him about the implications (Google should change the text to say it only allows him to send emails).

As you said he expected Google to give him technically impossible guarantees and handle that the third party software can't do anything without him confirming it.

It is indeed a difficult problem. It's not just that users cannot be expected to be knowledgable. They cannot know who to trust either. If you show them a warning that says "do not install this add-on unless you trust its publisher", what is a user supposed to do? There are thousands of add-on/app publishers with names that no one has ever heard of.

So I do understand Apple's approach. Unfortunately, Apple muddies the waters by mixing up security protections with their own business interests and the interests of authoritarian regimes. To a degree I fear this is unavoidable.

I think the best solution is to have that very restrictive app store that you can trust to vet things for you, but in addition to that they should permit side-loading for apps and content that you have to vet yourself or rely on a third party vetting system.

It's like quarantine. You might think you're smart enough to wear the right gear and behave the right way to keep others safe, but because some people are irresponsible or don't know how to behave, we enforce the rule on everyone, to keep everyone safe.

When we realize that many exploits can mean that devices get co-opted by bad actors to serve some rather nefarious purposes, we have to do more than "trust that the user will be smart" in order to suppress dangerous or economically destructive criminal uses of these devices

More and more I realize that it's not our strategies that I dislike, it's how incompetent and error-prone users actually are. If we were perfect users, none of this would be required.

With quarantine you're preventing the spread of disease which is a general harm to others, with this you're preventing the spread of... your own 2FA codes, which only hurts yourself, if that. Sorry, but I don't think this analogy works. I should have every right to harm myself in any way I see fit. My hardware, my accounts, my control. Preventing accessibility "abuse" does nothing to stop malicious apps from attacking other devices but does a lot to harm accessibility and advanced user features.

Quarantine is actually an apt metaphore here. Apple wants you to stay in the quarantine for the rest of your life because when outside you might ignore the red light and get killed on the road crossing. Or die from other millions of dangerous sources.

But staying in a single apartment for the whole life is not healthy for most people or society. Modern computing grew because people were able to build and experiment on things way beyond what the original manufacturers of hardware envisioned. Even if that gave some people Windows viruses.

I understand the "old days" idealism of hacking things in the 80s, but there weren't million computer botnets conducting massive criminal attacks on banks and governments in the 80s. It's a different era.

It's like saying "quarantine is pointless in my rural village of 29 people, so therefore it's also pointless in my city of nine million"

Another app that stores credentials mitigates this by putting up a 30-second delay; the text goes a bit like this:

"It seems that you are using a screen reader or something else that uses the Accessibility services. If you have no idea what this is, do not continue past this screen. The below buttons will be enabled in 30 seconds [I know what is happening] [This doesn't sound familiar, exit]"

(Of course it only appears when you actually have something subscribed into the accessibility services, which is how I found out) Yes, it's inconvenient, but forces you to actually read the message instead of blindly barging through Accept Accept Accept.

Does it do that every time, or just the first time? If it just happens once I guess that might be a tolerable tradeoff. Still doesn't seem like it's worth classifying Google's app as abandoned just because they declined to implement this particular feature.

Each time. Annoying, but bearable for something I use once a day...

That places the burden on people required to use such assistive technology. I’m sure life as a blind person is already full of obstacles, so we should maybe think twice before actively seeking to build new barriers.

And how does this actually prevent abuse? Wouldn’t malware happily wait 30 seconds and click “yes”? And if the dialog isn’t accessible to the screen reader, doesn’t it then exclude some users entirely?

I would think that the expected behavior is "if you don't know what this is, close the app manually." But yeah, it's only a mitigation.

So after you posted to it I finally found the report[1] (three levels deep from this post :)

So actually that's not how it works. If it was just reading the screen it would only get a single OTP password which is only valid for up to 60 seconds.

The trojan is actually tricking user to enable accessibility privileges. Those privileges give the trojan ability to control the phone. With this privileges it actually can navigate settings and grant itself other permissions.

I suspect that with authenticator it can navigate and extract a private key somehow. I don't know how it's doing, because I don't see an option in the UI to obtain such key. So perhaps it is still somehow exposed to accessibility application but not the user. Or the report makes it look worse than it is and only talks about the one time code (it is not clear).

Anyway the real issue though is that accessibility is giving app full access to the phone. Restricting that though would affect accessibility, I believe Android though should make such accessibility request more scary.

I think the fatal flaw there is maybe allowing an app to prompt the user to enable accessibility settings. Although it is still not as terrible, an app can only send the user to the right setting page, but it can write whatever it wants in the description of the app (typically they say why they need the setting). The only warning from android is when you're about to enable the setting, but that warning is very dry, it lists the permissions, and some description for them. It doesn't seem to distinguish more scary ones from less scary ones. It also conflates them.

For example I have app called "back button" which basically emulates a back button (actually also other buttons), quite useful when it is broken. Though the only permission the app is requesting is "observe your actions (receive notifications when you're interacting with an app)" it doesn't say anywhere that it is more than that, the app actually can emulate pressing various buttons and nothing like that is even mentioned.

[1] https://www.threatfabric.com/blogs/cerberus-a-new-banking-tr...

AFAIU it's the trojan app that uses the accessibility privileges? Which are probably only activated when the user activates them in the OS settings.

Not sure if possible, but perhaps the authenticator app could detect that accessibility mode is on, and refuse to show the codes? (or at least do it behind a warning?)

Also, I think the trojan app would need to ask for accessibility permission from the user to be able to read other apps' text?

So you would prevent blind people from using 2FA because someone else installed a tool that also reads screen? Please no.

You build speaking the OTP code into the authenticator app itself, controlled by a setting in the app itself rather than the system wide accessibility settings, and possibly using its own text to speech library instead of the system wide text to speech facilities.

Whether or not it should use its own text to speech depends on whether or not you need to worry about malware subverting the system wide text to speech system.

If it does use its own text to speech, it might be possible for it to just use the system text to speech system on install to do generate speech for the 10 digits and save that, and use those recordings for speaking codes.

That avoids having to worry about system text to speech compromises except during authenticator app installation so is probably almost as safe is including a dedicated text to speech system, an ensures that they can handle all languages that the system text to speech can handle.

What about users that are deafblind and use external braille devices? Are you going to build support in for those too? Is the maker of every other security relevant app also going to?

But there's a lot more that goes into accessibility services.

Redirecting all output to a single mono headphone is really important, and most users who use talkback adjust the speed and how things are spoken to better suit them.

And it still doesn't solve the problem, as accessibility services can still tap into the audio output and run speech-to-text to get the codes back still accomplishing the same exact thing.

OK, so the idea of having the authenticator app entirely handle its own accessibility might not solve the problem in the case of users that are actually using accessibility features. Or at least it would require some serious system level support [1].

But how about the first part of my suggestion, which was to have whether or not accessibility features are used in the authenticator app controlled by a setting in the app separate from the system wide settings?

For people not needing accessibility, at least, and so have it off both system wide and in the authenticator app they would be protected. A rogue app getting system wide accessibility access would still not get access to the authenticator.

[1] The system might have to support two independent sets of accessibility privileges and settings, one for most apps and one for security apps, with severe restrictions on what regular apps can do when a security app is running.

> (or at least do it behind a warning?)

Couldn't the accessibility app just approve the warning? Otherwise how would blind users do it?

> What is the proposed mitigation that Google should implement on the app?

Why are 3rd party apps needed for accessibility ? How about Google take accessibility serious and make the OS accessible without expecting others to pick up the slack ? An API with this kind of far reaching access shouldn't even need to exist.

Accessibility is one of those long tail things, which is why the laws about it are written in relatively vague terms. If you need a wheelchair requiring everything be made suitable for the blind doesn't help you at all but a wheelchair ramp makes a big difference. If you're utterly deaf the wheelchair ramp is not helping.

Google undoubtedly has the resources to build say, Android for Blind People. But it's not realistic to expect Android for this one guy who can twitch his nose, but is otherwise paralysed; or Android for the woman whose brain can't process shapes properly.

By enabling a generic Accessibility feature it doesn't close the door to anybody. If you can adapt it, or get anybody else to adapt it, to be accessible to you then this feature will help you get that done. To do that it's enormously powerful, which means bad guys with this permission can take over your phone.

iOS supports password managers natively. When you focus a password input, the keyboard prompts you to open the password manager. For me it opens BitWarden directly from the keyboard.

Android doesn't support this, so a workaround is to use the accessibility service. The trade-off is having to grant all those permissions. You can also open the app directly and copy-paste, but that's a lot more extra steps. The killer features for password managers are that they're both more secure AND quick/convenient.

> You can't block accessibility on the OTP app because then blind people will not be able to use it.

You can block accessibility from the specific field of the OTP app, if you also have a system framework that retrieves exactly the contents of that field into your paste buffer when you interact with a privileged UI element (i.e. the keyboard-UI “autofill 2FA” accelerator.)

What about people who want to type the code into a different device?

But then how would disabled people access their 2fa codes?

Maybe the app should just read the code out to the user, provided said user has a headset on.

accessibility services can also tap into the audio output of the device.

That won't work if someone it trying to use the code on their desktop. The screen reader won't be able to read the code to them, so they won't be able to log in.

You can autofill the field into a text editor, and read it from there. The security comes from the fact that you had to interact with a privileged UI element to do so, which an accessibility assistant cannot trigger; you need to use the system accessibility features (e.g. the voice assistant) to trigger privileged UI elements.

(See also: accessibility of elevation prompts in Windows.)

Thee is no reason not to have a special privilege level for screen readers.

There is a special privilege level for screen readers. The issue is that the hypothetical malicious app pretends to be a screen reader.

Do you mean it hypothetically actually functions as a screen reader but also steals data, or something that just requests the privilege while being something completely different?

Either one, but realistically the latter.

In the former case, you just call your app SuperLegitScreenReader, prompt the user to grant accessibility access, and then snarf up data. Bonus points if you bundle in some open source or pirated screen reader code so your app can act the part, but you could probably just say “fetching reader data, screen reading will be functional in ~60 minutes” and count on most users to not bother uninstalling the app or revoking permissions.

In the latter case, you call your app “CandyNinjaBirds”, and have it pop up and say “to let you share cute stickers to your friends, you need to enable accessibility access” and count on the vast majority of people to click “allow”.

The latter case is way more common because the former case limits your target audience to people who actually want a screen reader.

Ok - but given the small number of actual screen readers it would be easy for a store to have extra policing for this privilege.

The copy/paste buffer is also accessible via accessibility features. This isn't a fix for the "problem" presented by the article. (personally I think it is hardly an issue)

> You can't block accessibility on the OTP app because then blind people will not be able to use it.

True - but you can make accessibility access an opt-in feature. I hate phrasing it like that. But a piece of security software should allow people to disable accessibility features when they aren't needed.

> you can make accessibility access an opt-in feature

It already is. You have to explicitly go and enable it per requesting program in the system settings.

Accessibility services are disabled by default and need to be explicitly enabled by the user. At that time the user is clearly warned that the enabled service (by name) will be able to read the screen.

Should opting in not be accessible by assistive tech as well, then? People requiring this technology obviously need a way to turn it on. Requiring them to have assistance to initially set it up would seem terribly insulting, regardless of how little trouble it might practically be for most people.

Reply on news.ycombinator.com