This is not wolf in sheep's clothing, it is wolf in wolf's furry clothing. Oauth access token is pretty much as powerful as a password, and it is being written to debug log here. Amazing how this code passed code review!
It's probably a shame that the technology is abbreviated OAuth(orization) because people think OAuth(entication) and forget to handle the string with the reverence it needs.
This was a similar issue with the CarrierIQ thing. Apps have to explicitly request this permission, and it's a strange one that should raise red flags unless it is explicitly intended for such a purpose.
There are more apps out there that use this permission to submit crash reports and logs to the developer for debugging. The Bible app probably has a large enough scale, high adoption rate, and enough moving parts to make for a bad app if they didn't get that feedback.
Edit: Have this app, contributed some translations. This app is pretty popular across many countries and locales, meaning the crash reports are essential for good user experience.
Yeah, that's something that should be fixed in Android, IMO. You shouldn't need system log permissions to capture a crash report - the OS should give you a standard way to say "I want crash reports" (might be as simple as an email address to send to). After a crash, the user should be given a dialog from the system (not the app) about whether or not they want to send the crash report data. I thought I'd seen something like that in the past, but it might have only been for system apps or something.
In some kinds of apps there can be issues that are not necessarily crashes, but where a log from the user's system is still helpful in diagnosis. Perhaps the answer is to make an app's own log and relevant system logs - but not the logs of other apps - available to that app.
Good point, though the more I think about it the issues are tricky. Access to the app's own log seems like a reasonable convenience (since the app could have recorded that anyway). On the other hand, there are cases I can see (e.g. confidential documents in a word processor) where you don't want the app developer to have access to everything you do with the app (which is what giving access to the app's own log can easily turn into).
The nice thing about the crash reporter case is that even if the crash report is ready-to-go the user still gets to decide whether or not to send it, so they still have direct control. Perhaps the right line would be an "own log" permission.
At least in OAuth 1.0a, the access token is only useful if you also know the consumer secret (provided the PLAINTEXT signature method is not in use). Of course, the consumer secret probably isn't difficult to fish out, and besides, this 'attack' relies on the user typing his password into an untrusted device... so, yeah.
What? It relies on the user typing his password into a personal smartphone that just happens to have a trojan app installed. How much more "trusted" can you get? Relying on users never to install malicious software is not a valid security model (as witnessed by decades of experience in the PC market), and I'm shocked that you think so.
Err... so you're okay with typing your username and password into a personal computer running software configured under another person's control? That's about as far away from "trusted" as possible.
The author describes getting into other folks' FB accounts by having them log in on his own device. Not their own devices.
You've misunderstood the exploit. Logging into someone else's phone is an artifact of the test (because clearly he's not going to push a malicious app to the market!), not a requirement for the exploit. Any app with the log reading capability can do that. And any app can request that capability. As pointed out elsewhere there's a Bible app that does it.
I follow the issue of defeating the purpose of the sandbox -- the token is sent to a log where other apps can read it, so an app that has "read sensitive log files" and "access network" rights could run amok over the user's FB. The article goes on to describe getting access to other folks' accounts, but only after convincing them to enter credentials. But there are already plenty of drawbacks to installing malicious apps on your own smartphone, and lots of reasons not to enter credentials on some random device.
If a user had FourSquare (or Parse) installed during the time of the vulnerability, that exploit would've worked. Maybe hidden in an obscure (partly useful? Wallpapers of a hot movie at that time?) and simple app.
Although the user 'just' logged in to known apps and services on his very own device. So your argument about not entering credentials on random devices seems off to me. The one about not installing each and any application out there is correct and spot on, of course.
If you are a Django developer, please be aware of (and use) the capability to mark data as sensitive to exclude it from error reports. Most people won't need this feature since very often as you don't often define your own new sensitive variables, but it's important to know that it is there:
you can hate Facebook all day but the handling of this issue shows that they have very good understanding of how to deal with exploits reported by white hats
>Is the user prompted for this(don't have android)? Seems pretty explicit.
Explicit to you, I and the majority of the HN readership. However, I'd venture that the vast majority of users have absolutely no idea what that means. It may as well be gibberish.
I've seen this myself while using the Android Facebook SDK (which is quite poor). I'm still debating with myself whether the article overstates the implications of this issue though.
To really make use of it you'd need to create an Android service which extracts/parses the logs from logcat when the device is awake. Then when you find an access token you'd need to try a few opengraph requests to see what permissions you have for that particular token. I suppose such an app could do damage but it does depend on a lot of circumstantial events. But I guess most exploits do.
Edit: You may as well just ask for the READ_CONTACTS permission and take the entire data from there ;)
Sure, Facebook fixed it, but there are probably hundreds of apps on the market that are using older versions of the Android SDK. A lot of independent developers might not be upgrading their apps regularly, much less realize that Facebook added an important security update to the Facebook Android SDK. ...This problem could affect apps for some time to come.
Having used Logcat for a lot of development, I feel like everyone dumps sensitive data there. CarrierID did, Facebook's API did, and a few others did as well (notably Qik specifically sent API keys every ~30 seconds, but patched it later).
Nice catch, but something tells me if this hole were exploited, it'd be easily and quickly shut down.
The next question is, I'm guessing most apps store the access token somewhere for future use, is there a permission that apps can have that let them at this storage? Hope the FB SDK encourages safe handling (encryption, etc) of the access token.
This is not wolf in sheep's clothing, it is wolf in wolf's furry clothing. Oauth access token is pretty much as powerful as a password, and it is being written to debug log here. Amazing how this code passed code review!