Mark L. Murphy's Blog, page 55

Defending Against Activityjack Attacks

A number of media outlets reported on a research paper and USENIX conference presentation describing a way by which your users could be tricked into providing confidential information — passwords, credit card information, and such — to a piece of malware, rather than to your app.

The paper points out that there are ways of writing malware such that:

the malware can pop an activity in front of yours, and

do so at just the right time, to mimic one of your activities, such that the user thinks that the malware’s activity is actually yours and enters the confidential data into the malware activity

For the purposes of this blog post, I’ll refer to this as an “activityjack” attack. Just as a clickjacking attack tricks Web users into clicking on the wrong things, and just as a tapjacking attack steals Android touch events via a transparent layer on top of the screen, an activityjack attack steals input destined for your activity by interposing another activity on top of yours.

The particular means of implementing the activityjack attack outlined in the paper is a bit esoteric. What it does do, though, is illustrate that such an attack is possible. Half the battle with security is knowing what you need to defend against.

The paper outlines solutions to their particular flavor of activityjack attack that require OS modifications. That’s fine, and perhaps the Android project will implement that stuff. But it will take years for such changes to percolate through the Android device ecosystem. For example, tapjacking was “solved” in Android 4.0, but there are millions of people using devices older than that, even today. Hence, we need to think as much, if not more, about application-level solutions.

Let’s ignore the details of the particular approach from the paper. Let’s merely assume that an attacker can get their activity in front of ours at the right time, as there are less-esoteric ways of doing the same thing (e.g., via an AccessibilityService). How do we defend against that for critical activities, such as “login” activities that require the user enter a passphrase?

An activityjack attack has two key weaknesses:

The attacker cannot see the screen, because on non-buggy devices, the attacker has no means of capturing a screenshot of our activity as it comes into the foreground. Hence, while the attacker can create an activity that tries to mimic ours, they can only do so statically, analyzing our activity’s UI on their development machine and creating their own lookalike.

We know that our activity has left the foreground, as we are called with onPause() (and perhaps other lifecycle methods, depending upon the nature of the attacker).

Hence, one defense can be to include in our activity a secure element that cannot be mimicked ahead of time, then hide that element (or our whole UI) when we are no longer in the foreground.

This concept of a secure element is not new. Some financial services Web sites have taken this approach. As part of the user setting up their online banking account, the user chooses an image from a collection of clipart. On the Web page that collects the user’s passphrase, the page also shows this secure element. The user is taught that if they do not see their chosen image, then the Web page they are looking at is not really from their bank, and therefore they should not type in their passphrase.

This is not that hard to implement in Android. You too would allow the user to choose a piece of clipart, displaying that in an ImageView on your secure activity in onResume(). In onPause() you would hide that ImageView via setVisibility(View.INVISIBLE). That way:

Since the image is chosen by the user, the attacker is unlikely to mimic the same image

Since you are hiding the image when you are not in the foreground, the attacker cannot use a transparent region in their activity to have your image “peek through” their attacking activity

As a result, if the user is paying attention, the user should see either the wrong image or no image at all, and the user should realize that they are being activityjacked and therefore fail to proceed.

You might be tempted to do something else in response to your secure activity being replaced in the foreground by another app’s activity, such as pop up a warning dialog. However, there are plenty of valid scenarios when this would occur, such as an incoming phone call, and you have no reliable means of whitelisting all possible valid scenarios. There will be a high incidence of false positives, and that may not help the user. Having this as an user-selectable option is fine, but I would not go this route by default.

With luck, somebody will come up with a better defense, one that makes it more likely that the user will not provide confidential information to the attacker, yet not be so onerous that they get fed up with your app and uninstall you. However, this approach should be reasonably easy to implement and help defend your users from activityjacking attacks in critical activities.

The Return of "Gradle for Android... and You!"

“Gradle for Android… and You!” is back!

Earlier this year, I offered a 30-minute free webinar on Gradle for Android: what it is and why it will be important for you, here in 2014 and beyond.

I am running “Gradle for Android… and You!” again in September and early October, with two changes:

It is now a 45-minute webinar, getting into more about how Android Studio and Gradle for Android are related, how Gradle for Android relates to the larger Android development ecosystem, and more.

To register, you need to make a donation to the Electronic Frontier Foundation. Proceeds from these webinars — minus Eventbrite processing fees — will be contributed to the EFF once the webinars are done. Eventbrite’s minimum donation is $1.

So, if you have been hearing about Gradle for Android and are trying to determine what it gives you and why you should be considering it, sign up for the webinar!

Note that this is not a deep technical dive into how to use Gradle for Android. Gradleware and I have an online training course for that, plus the material in my book on the subject.

Want to Review a Beta Book?

Version 6.0 of The Busy Coder’s Guide to Android Development should be released around September 4th. At the suggestion of a subscriber, I am offering early access to a draft of the book to 10 active subscribers who are interested in reviewing the new Android Studio coverage. I should be delivering this draft late this week, so reviewers would have a bit over a week to examine the draft and provide any feedback.

Besides the cap of 10 reviewers, there are some limits on this program:

It is open to active subscribers only, not to former subscribers or the general public.

The draft will only be published in PDF form. In particular, I am testing smallpdf’s PDF compression service, which so far has worked remarkably well in reducing the PDF file size while not seeming to wreck images and whatnot.

I will offer a limited version of the Book Bug Bounty program, where any reviewer who reports bugs in the draft gets a six-month Warescription extension. The normal bounty program offers six months per emailed bug report, but as I will not have completed my own review of the changes by the time I deliver the draft, I am capping the bounty for the draft to one bounty per reviewer.

This is a one-time program, to help with the extensive changes going into this book update. If this program is a success, I may do it for future changes of similar scope, but there will be a fresh call for reviewers at that point.

I reserve the right to cancel the program, though I have no idea why I would.

If you are interested in reviewing the draft of Version 6.0 of my book, please send me an email, stating that you are interested in this program, along with your Warescription user ID. I will reply to let you know if you successfully qualified. I will update the blog post once I have 10 reviewers to indicate that the program is not accepting new candidates.

Thanks in advance to everyone who reviews the draft!

Intel's Android Developer Field Guide... And You!

A few weeks ago, I was recruited to provide some links as a starting point for the “Build” portion of Intel’s Android Developer Field Guide. In addition to the links I contributed for “Build”, Paul Blundell organized the “Ideate” area, Jason Mark covered the “Design” area, and Shen Ye brought up the “Launch” area.

In addition to the resources presently linked to from this site, Intel is interested in your input for other resources that should be considered for inclusion. On each area’s page — such as the “Build” page — there is a “Recommend a Resource” button to tweet the page’s organizer a link that you think belongs on that page.

Each organizer has his own criteria for what belongs there, beyond being relevant for the page’s topic area. In my case, my focus is on links to resources that are likely to be relevant for the next few years. Android evolves rather quickly, and so I’m trying to avoid links that are more prone to become stale too soon. Beyond that, I am looking for links to “quintessential” resources — the sorts of things that developers should not miss. And, I’m going to try to avoid too much overlap with what’s already there, as I do not know how many links Intel wants to have per page.

Intel will be seeking this input over the next few weeks. If you have a suggestion for any of the pages, click the button on the appropriate page on the Intel site. If you are not a Twitter user, or otherwise would prefer not to tweet your idea to the world, you can send me an email. I will try to remember to update this post when the window for recommendations has closed.

(and, yes, I know about the typo on link #15 — they’re working on it…)

Of course, definitely take a look at the resources that are already collected, as there may be ones that are new to you that could prove useful.

Better Presentations From a Service

Back in May, I blogged about how to show a Presentation from a Service. In there, I said that the SYSTEM_ALERT_WINDOW permission was required to make all of this work, because we needed a TYPE_SYSTEM_ALERT Window to display content on an external display from the background.

Clearly, somebody had spiked my chocolate milk while I was working on that bit of the code.

Andrew Hughes pointed out to me that removing TYPE_SYSTEM_ALERT and SYSTEM_ALERT_WINDOW from my code worked just fine. I reproduced his findings and updated my PresentationService to match. And it seems to work fine.

My apologies for my mistake, and many thanks to Andrew for his help!

Upcoming Conference Presentations: droidcon UK and AnDevCon

The fall conference season is almost upon us! And the call-for-papers results are starting to roll in!

I have been selected to deliver two presentations and a half-day workshop later in 2014:

My “Getting By With Less Than 1.21 Gigawatts” presentation is scheduled for noon on Halloween at droidcon UK. I will be talking about the Battery Historian and JobScheduler introduced with the “L” Developer Preview, along with other notes on how to reduce your app’s battery consumption.

I will be delivering a half-day workshop (a.k.a., “tutorial”): “Your Android App. On TV.” at AnDevCon San Francisco 2014. Here, we will review the myriad ways that your app can push content to a TV, whether that be from a dedicated TV device (e.g., Fire TV, Android TV), a connection from a phone or tablet (e.g., MHL or Miracast), or via an intermediary bit of hardware (e.g., Chromecast). Note that my focus will be on standard Android SDK capabilities, not any proprietary libraries, so what we cover will be good across the range of display options.

Also at AnDevCon, I will be delivering a presentation called “Notifications, Front to Back”. As with my other “Front to Back” presentations, we start off with a quick review of the basics for putting icons in the status bar, for those who have not used Notification before. Then, we will quickly move into more advanced scenarios, such as the “big” styles for expanded notifications, plus all of the notification extensions added in support of Android Where?… er, I mean, Android Wear… and other stuff that showed up in the “L” Developer Preview.

I look forward to seeing some of you at these events!

Custom Permission Vulnerability and the 'L' Developer Preview

Earlier this year, I blogged about a vulnerability in the way custom permissions work in Android. In a nutshell, the <permission> element is “first one in wins”, opening up scenarios in which an attacker can silently gain access to secured components of another app.

A Google+ post from early July tipped me off that there might be changes in the “L” Developer Preview, and I finally got the time to run some tests.

Near as I can tell, the “L” Developer Preview requires that all apps with a <permission> element for the same android:name value be signed by the same signing key. The actual protectionLevel or other values inside the <permission> do not matter. Even if they are identical, an app trying to define the <permission> will fail to install if an existing installed app already defines the <permission>. Specifically, the installation of the second app will fail with a INSTALL_FAILED_DUPLICATE_PERMISSION error.

As with many changes of this type, there is good news, and there is bad news.

The good news is that this should go a long way towards closing this security hole. No longer can an app gain access to another app’s secured compoennts simply by being installed first. The exception is if they are signed by the same signing key, in which case Android assumes that they are written by the same developer (or firm).

However, there are various aspects of bad news:

Two apps signed by different signing keys cannot access each other’s secured components, if they are secured via custom permissions. You wind up with a “deadly embrace”-style scenario. One app has to be installed first. If that app does not have the <permission> element, it will not be able to hold that custom permission. But if it does have the <permission> element, the second app cannot be installed if it also has the same custom <permission> defined. If both apps each have their own custom <permission>, we cannot simultaneously satisfy the rules for both of those custom <permission> elements, and something breaks.

In a host-and-plugin architecture, the plugins cannot define the <permission>, as if they get installed first, the host cannot then get installed. Hence, if a plugin detects that it was installed before the host, it will need to prompt the user to uninstall the plugin, install the host, then re-install the plugin… which may be enough to cause the user to just uninstall the plugin and go with some other solution.

We may see “denial of service”-style attacks – whether intentional or otherwise – when an app defines the <permission> that should be defined by some other app. For example, any app can prevent the user from later installing Adobe Reader, just by defining a <permission> that Adobe Reader defines. And, because this behavior is different from the pre-”L” behavior, this could easily happen by accident.

One thing that could help here would be to extend <uses-permission> to include an android:permissionMissingMessage attribute (or perhaps something shorter). This attribute would point to a string resource that would be shown in a dialog if the user attempts to install the app and the permission requested in <uses-permission> does not exist. Right now, the installation just goes ahead, despite the fact that there is no obvious scenario in which that permission will ever work. IMHO, the installation should fail, where the permissionMissingMessage would give the user guidance for how to resolve the conflict. For example, a plugin would use a message to tell the user to install the host app first. We could go even further and have an android:permissionProvider attribute, pointing to the package name of the app that should be installed first to provide the missing <permission>. The dialog showing the custom message could then have a button to allow the user to go install the missing app via the device’s default marketplace (e.g., Play Store). I have no idea if “L” offers anything like this, as the “L” developer documentation is merely JavaDocs. I filed an enhancement request about it.

Of course, there is every chance that the shipping Android release stemming from “L” will roll back this change in <permission> behavior, or introduce other modifications that address my concerns.

All that being said, what I am seeing is a distinct improvement over what we had, from a security standpoint, and with minor tweaks, we can fix the UX issues as well.

The Role of Services

“Only have a service running when it is actively delivering value to the user”.

I use the above expression a lot, as it is the shortest way I have found to express when using a service is appropriate. However, as with all short explanations, it is not necessarily intuitively obvious what I mean.

Primarily, a service exists as a flag to the operating system, indicating that you are actively delivering value to the user, and therefore Android should aim to terminate other processes — not yours — when it gets low on system RAM. Secondarily, a service provides a couple of APIs for IPC: the “command” pattern (Intent and startService()) and the “binding” pattern (bindService()).

While we also use those two communication patterns for in-process use, that is mostly in support of the role of flagging our work’s existence to the OS. We organize our code around those communication patterns so that the service is responsible for the “actively delivering value” task, and so when the service is no longer doing that, we can stop the service.

When we have a service running, therefore, we are indicating to Android that we think that the user thinks that our process is more important to the user than are other competing processes, and so the user would prefer that Android terminate those competing processes rather than ours. This affects multitasking, as the more service-laden processes are around, the more quickly that ordinary processes the user might have used recently will be terminated just to free up RAM. This becomes particularly obvious to the user when the user tries switching back to the app and something is lost due to the process termination (e.g., because the app is not handling onSaveInstanceState() well).

The catch is that too many developers don’t think in terms of the user. They think in terms of themselves, believing that what is important to the developer must be important to the user. Sometimes, what is important to the developer works at cross-purposes to what is important to the user. For example, the developer wants to go home rather than clean up some sloppy service code, while the user wants multitasking to work well. What the developer wants (less work in cleaning up the service usage) and what the user wants (fewer processes with running services) are at odds.

Hence: only have a service running when it is actively delivering value to the user.

Here, “value”, like beauty, lies in the eyes of the beholder. And the user thinks the user is the beholder, and so the user is the one defining what is, and is not, “value”. The user must feel that what your service is doing for them is worth the worse multitasking, where they have to start up “Angry Birds: The Battle of the Five Flocks” again from the beginning, rather than return to their in-progress game, because Android terminated the birds’ process when the user took a phone call, rather than terminate your service’s process.

“Actively delivering” means that the service is delivering value right now. Not “maybe in a few minutes”. Not “well, sometime, but we don’t know when”. Right now. And the recipient of that “value” must be the user — you, the developer, are not more important than the user.

So, let’s work through some scenarios:

Having a service around for playing back the media for your music player app is actively delivering value to the user. The user will notice if the music were to all of a sudden stop due to your process being terminated, and so indicating to the OS that you are delivering value to the user is reasonable. In fact, this is one of a handful of scenarios where using startForeground() is relevant.

Having a service around to try to keep your process around rather than have to reload data is not actively delivering value to the user. Your process will not live forever anyway, and so you should be fixing the data-load speed issue to handle those process startups. That, in turn, will alleviate your need to try to artificially keep the process around to avoid the data-load work. The value to the user is having the data be loaded, but the long-running service should not be required to deliver that value.

Having a service around to download a large file is actively delivering value to the user, assuming that they value the file. This is an ideal use case for an IntentService, as you need a background thread anyway for the network and disk I/O, and the service can automatically shut itself down when the download is complete. That allows you to have the running service only while you are actively delivering value to the user, while having the service go away once the value goes away.

Having a service around all the time to do work periodically is not delivering value to the user, in most cases. While the periodic work is value, watching the clock tick in between pulses of work is not delivering value. Instead, use AlarmManager, or the new “L” JobScheduler.

Having a service around because you wanted to have a central point of control in your app is not delivering value to the user. Having a central point of control is reasonable, but you do not need it to be a service. For this role, an ordinary singleton is lighter weight, in that a service is a singleton that happens to have broader impacts with regards to your process lifetime.

Having a service around because… well, you thought that you needed a service, and so you put your code in one and started it, and then you couldn’t figure out when to stop the service, so you left it running… is NOT delivering value to the user. Do not create services because the mood strikes you. Create services because you are actively delivering value to the user when you are not in the foreground, not just “because”.

Usually, we have clear scenarios when we need to use the other three Android components:

Use an activity when you want to show something on the screen

Use a content provider when you want to share stuff with other apps that looks like a database or a stream

Use a broadcast receiver when you are looking to respond to a broadcast, usually issued by a third party

Services are a “Swiss army knife” that can be applied in lots of scenarios. As such, it is sometimes difficult to tell what is and is not a valid use of a service. If services did not have the “keep my process around” role, tossing services around willy-nilly would not be nearly as much of an issue. But services do impact the user and can reduce user satisfaction, and so it is important that developers think through why they are implementing a service, when that service should be running, and when that service should not be running.

And the simplest mantra that I have come up with to help developers work all that out is: “only have a service running when it is actively delivering value to the user”.

Gradle for Android Online Course

Just a reminder: I am teaching a half-day online course on behalf of Gradleware, covering the basics of Gradle for Android:

How to get it set up

How to get your first Gradle build file working

How the new project structure works

How to take advantage of build types and product flavors

How to integrate other projects and third-party code as dependencies

How to use Gradle for Android to automate other aspects of your project builds

You can see a larger outline of the virtual course on the Gradleware Web site.

The course is Tuesday, August 19, 2014, from 8:30am to 12:30pm (Pacific Standard Time).

Webinars: Memory and Security

A pair of webinar topics have been added to the roster for August through early October.

One is a two-hour Webinar on memory management, a trimmed-down and slightly-updated version of a presentation that I delivered at AnDevCon Boston 2014. Here we will examine why you have as many problems as you do, what tools exist to help you determine if you have a memory problem (and where that problem may come from), and some tips for better managing the memory that you have.

The other is “The Security Problems You Aren’t Thinking About”, reviewing a variety of ways in which your app could have security problems, particularly using APIs and Android capabilities that you might think would not present such problems. This is based in part on a conference presentation I delivered at DevWeek 2014 earlier this year.

As with past webinars, these are each scheduled for four different dates and times, to try to provide you with enough options to find one that you can attend.

Subscribers can visit their Warescription page to get the discount codes for these and the other scheduled webinars, though they are also open to the public.

If you have any questions regarding the webinars, let me know.