Mark L. Murphy's Blog, page 59
February 17, 2014
Webinars: NFC Basics
Another webinar topic has been added to the roster, this one on the basics of using NFC, covering things like reading and writing tags, pushing data and files to other devices, and so on.
As with the other webinars, this one is 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.
February 12, 2014
Vulnerabilities with Custom Permissions
Mark Carter posted a comment on one of my StackOverflow answers. Based on his analysis, my own, and discussion of this with “Justin Case”, an Android security researcher, it appears that there’s been a limitation to how custom permissions work in Android, one that can leave apps that use them vulnerable to attack.
Specifically, it appears that Android works on a “first one in wins” strategy, and developers need to be aware of what this means.
The Synopsis
If two apps define the same custom permission (via the <permission> element in the manifest, with the same android:name value), whichever app is installed first is the one whose definition is used.
On the one hand, this is not terribly surprising. “First one in wins” is a common approach to handling duplicate definitions of things.
However, unlike duplicate package names or duplicate ContentProvider authorities — where the installation fails due to the duplicate — installation proceeeds in this case. That too is not terribly surprising, as this behavior can be rather useful in cases where the installation order of apps is not known in advance.
However, it does open up significant risks. An attacker can gain access to a defender’s secured components simply by:
Declaring the same custom permission,
Requesting that custom permission via <uses-permission>, and
Being installed first
Android never informs the user that the attacker requested this permission, and so the user is oblivious to the fact that the attacker has access to their data in the defender’s app (to the extent offered via this permission).
Worse, the attacker can decide to have its edition of the custom permission have a normal android:protectionLevel, and this supersedes any signature android:protectionLevel that may be established by the defender. The attacker not only can obtain this permission silently, but it does not need to have the matching signing key.
The Mea Culpa
I should have realized this a couple of years ago, at least. I did some research for determining how apps employing custom permissions can support arbitary installation order. My solution is to define the same permission in both apps, and that is precisely the scenario that an attacker would use. I was focused on enabling communications between apps and failed to do broader research about ensuring that there were no related vulnerabilities. I am deeply sorry that I failed to do this back then.
This issue is also apparently known about in Android security circles. The Android Security team has stated to methat this is “working as intended”.
I am blogging about it here as I suspect that it is not widely known among Android developers, and it needs to be better known. I have already notified the developers of one “brand name” Android app about the issue (since I had proved that they were vulnerable as part of my testing), and I am sure that there are countless others who use custom permissions and are unaware of the problem.
What Now?
You can read a more in-depth write-up of my analysis of this issue.
That paper is in the repository of a new CWAC library, CWAC-Security, where I have a PermissionUtils class that can help you detect, on first run of your app, if some other app has already defined one of your custom permissions. You can then take steps if needed (e.g., the app is not on some whitelist), to notify the user about the other apps and perhaps to record this information yourself to perhaps identify attackers.
I have also filed an enhancement request to try to improve Android’s handling of custom permissions. However, b.android.com issues can rapidly become a cesspool. Please do not post “me too!” or “Google is teh evil!” comments on the issue, as those will merely make it less likely that this will be addressed. If you have additional analysis, thoughts on implementations, or the like, those would be fine comments, if you wanted.
If you find flaws in my analysis, or if you find flaws (or have enhancement suggestions) related to CWAC-Security, feel free to file an issue. If you find additional vulnerabilities in this area, contact the Android Security team, or contact me if you prefer. If you have general development questions in this area, post to StackOverflow in the android tag or use your favorite Android developer support site.
I would once again like to thank Mark Carter and “Justin Case” for their assistance with this issue.
February 8, 2014
Fighting Closed with Open
An article that is making the rounds is Ars Technica’s “Neither Microsoft, Nokia, nor anyone else should fork Android. It’s unforkable.”. The author (Peter Bright) early on states:
Google has worked to make Android functionally unforkable, with no practical way to simultaneously fork the platform and take advantage of its related strengths: abundant developers, and abundant applications.
There is a practical solution, one that can beat Google at its own closed-source game. However, it requires business executives who aren’t control freaks, which unfortunately makes it improbable.
Mr. Bright’s argument is that Android is only partly open source. Google Play Services is closed source, and Google certainly pushes this set of APIs. Only licensees have legitimate access to Play Services, and apps that require Play Services can therefore only run on licensed devices.
His conclusion, therefore, is:
The only way to solve the application issue is to be not merely an AOSP platform but a [Play Services] platform.
Nope.
The only way to solve the application issue is to get developers to become less dependent on Play Services. And, IMHO, the only viable way to do that is for other vendors to collaborate and build up a competing suite of open APIs, ones that can plug into Play Services or into alternative implementations.
Mr. Bright posits that creating a replacement for Play Services is a lot of work, and he is correct. However, there are already replacements for much of it, whether in the open source arena (e.g., Open Street Map) or in the commercial realm (e.g., Amazon’s various replacements for use on the Kindle Fire series).
The problem isn’t a lack of alternatives. It’s a lack of a compelling reason for many developers to bother with those alternatives.
Google has done a reasonable job of ticking off the two major boxes for considering an API:
Making it fairly easy to adopt (e.g., from educational, technical, licensing, and operational standpoints)
Delivering a nice-sized audience for the results
Having an umbrella API, that plugs into Play Services or alternatives, can only expand the audience. Hence, if it becomes easy to adopt, sensible developers will certainly consider it.
The problem is that vendors like Amazon are focused on trying to be Google and have their own lock-in. Some percentage of Android developers will adopt such firms’ proprietary APIs, either for dedicated apps for such firms’ devices, or slogging through multiple implementations. But a lot of developers will not bother, just as a lot of developers do not bother with the Amazon AppStore for Android — and I’ve tried for years to get developers to think about distribution beyond the Play Store. If it isn’t easy, and it isn’t huge, it isn’t on most developers’ radar.
There’s nothing stopping some consortium, or a nicely-backed open source initiative, from taking a page from the same playbook, and aiming to give Android developers a reason to switch to a higher API that offers a larger audience. This would spread the effort amongst multiple interested parties, from major vendors (Amazon) and major ROM modders (Cyanogen, Inc.) to the countless firms who offer something in the Play Services sphere and would relish the opportunity to plug into a common API and not get trampled by all the elephants.
This still will not be easy. And, it would eliminate these vendors’ ability to achieve lock-in in the same areas that Play Services covers. Hence, I have no idea if there is a critical mass of players who would take on such a task. And it will take patience and time, once something is ready, to educate and convince developers to migrate to such a solution. But an open set of APIs would weaken Google’s lock-in ability with Play Services, and I would think that this might be an objective of some of these firms.
If you want to fight the closed Play Services, building fragmented closed alternatives is an unlikely solution. Instead, fight closed with open.
February 4, 2014
Webinars: Streaming Providers and Advanced Maps V2
Two more webinar topics have been added to the roster:
One explores sharing content with other apps via streaming ContentProviders, for operations like ACTION_VIEW
The other expands upon the introductory Maps V2 webinar and gets into more advanced Maps V2 tips and techniques
Each is scheduled for four different dates and times, so hopefully one or two are convenient for your schedule.
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.
January 28, 2014
Upcoming Presentations: WIPJam, Wearables, and 'Week!
I will be delivering presentations at a few upcoming events.
First, I am honored to be speaking at WIPJam@MWC, the “developer conference within a conference” hosted by WIP and held in concert with Mobile World Congress. There, I will be delivering a short keynote entitled “The Fuuuuuuuuuuuture! The Next Billion Users”. I will also be experiencing what life is like in a ~72,000-person event – I expect to have flashbacks to attending sporting events in college, just with fewer foam fingers.
(unless Miley Cyrus is attending MWC, in which case the foam finger count may be higher than expected)
The following week, I’ll have moved from Barcelona to Burlingame (CA) for Wearables DevCon, where I will be talking about “When Microwatts are Precious: Battery Tips for Wearable Apps” and “Gradle and Your Android Wearable Projects” in support of this new event.
After a couple of weeks of rest and recovery, I will be jetting off to London to deliver a pair of talks at DevWeek 2014, where I will be delivering presentations on “Options for getting into Android” and “Top ten Android app security steps”.
Later in the spring I will be speaking in NYC and Boston. And who knows what else may crop up.
I look forward to seeing many of you there!
January 23, 2014
AndGlobe: Call For More Sites
I maintain a list of Android developer support sites called AndGlobe. The particular emphasis is on sites that are not in English. Android development is worldwide and multilingual; our support sites need to match.
If you operate, or know of, a site for asking Android development questions and answers, that is not listed on the AndGlobe site, please let me know, or follow the instructions on the GitHub repo to contribute new sites that way.
And, of course, please link to or otherwise promote the AndGlobe site, so Android developers know the wider range of Q&A sites that they can use for getting their questions answered.
Thanks!
January 21, 2014
Webinars: Maps V2 and Permissions
Two more webinar topics have been added to the roster:
One is an introduction to using Maps V2 in your Android application, for showing maps to the user
The other is “Permissions, Front to Back”, covering the Android permission system, from the basics through some advanced techniques
Each is scheduled for four different dates and times, so hopefully one or two are convenient for your schedule.
These are in addition to those already scheduled for SQLCipher for Android and external display support.
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.
January 15, 2014
Referral Program Out of Beta
I have rolled out some new stuff for subscribers out on the Warescription site, and I’ll be posting about those this week. Yesterday, I mentioned the StackOverflow Bump benefit.
I have also moved the referral program out of beta. All subscribers should have to the “Referral Programs” section of their Warescription page (filed under “Settings”) with the basic instructions. You can set your own referral code, and you can then publish that code for use by new subscribers. There is a link structure you can use to automatically apply that referral code as well.
The objective of this referral program is to thank those who would be linking to the book anyway, without generating link spam. That is why the benefit (a free month on your Warescription for each month that has a referral purchase) really only helps subscribers.
If you have any questions regarding the referral program, let me know.
More Android Development Webinars
I have rolled out some new stuff for subscribers out on the Warescription site, and I’ll be posting about those this week. Monday, I mentioned the StackOverflow Bump benefit. Yesterday, I mentioned the newly-out-of-beta referral program.
I am also ramping up the webinars. While the free beta test ones are completely booked, I will be adding new webinars every week. You can find out about the scheduled webinars by visiting the CommonsWare Eventbrite profile or by subscribing to the CommonsWare Eventbrite RSS feed. I will also announce new events here in this blog.
Webinars are $25 for an hour-long session, though subscribers have access to limited-quantity discount codes that knock the price down to $5.
The two that I have scheduled right now are on SQLCipher for Android, plus another round of the external display support presentation (which has proven popular). Each have multiple dates, at various times of the day, in hopes that one or more of the times will fit your schedule.
If you have any questions regarding the webinars, let me know.
Android Micro-Consulting
I have rolled out some new stuff for subscribers out on the Warescription site, and I’ll be posting about those this week. Monday, I mentioned the StackOverflow Bump benefit. Tuesday, I mentioned the newly-out-of-beta referral program. Yesterday, I pointed out a regular series of webinars.
I have also added the ability to request “micro-consulting”.
The primary way that I can help subscribers with their Android development issues is via the office hours chats. The StackOverflow Bump service will also work in this regard. But sometimes the help needs to be more private, or where a text interface is not the best solution. Often times, the next step up from StackOverflow is having to hire a consultant, and that usually requires a certain number of hours. There is limited “middle ground” for cases where you need a bit of advice but do not need 10, 100, or 1000 hours of consulting time.
The “micro-consulting” service allows subscribers to book some private discussion time with me, in chunks as small as 15 minutes, to keep the costs down. We can do the consulting via a Campfire chat room (what the office hours chats use), a dozeo Web conference (what the webinars use), or an audio or Web conferencing solution that you supply. The Warescription site allows you to submit a request for consulting, and I will get back to you to confirm the time for the consulting and other details.
If you have any questions regarding the “micro-consulting” service, let me know.
