Slashdot Mirror
CyanogenMod Android ROMs Accidentally Logged Screen Unlock Patterns
tlhIngan writes "Heads up CyanogenMod users — you will want to update to the latest nightly build as it turns out that your unlock patterns were accidentally logged. The fix has been committed and is in the latest build. While not easy to access (it requires access to a backup image or the device), it was a potential security hole. It was added back in August when Cyanogen added the ability to customize the screen lock size.`"
It's these sort of things that make you paranoid about the world+dog having access to everything. If it's not outright surveillance it's accidental. If not by design then by lack of design. A bug, a user error, a missed setting, a weak password etc. *puts on tin foil hat* Screw this, I'm going somewhere, underground, without electricity or things that need it. Log that.
A 'singular oddity' is an event that cannot be explained and only happens when you are alone.
That's one of the issues with many committers, you can't review all the code before it ships off in a build. I seem to remember a bug in openssl where some kid commented an entropy line "because it showed warnings at compile-time" and managed to commit it without raising suspicions.
Bottom line, where are the code reviewers in this process? QA?
FUD:
* it's an open-source project
* the fix has been commited
* it requires access to the device
The Cyanogenmod team (however precisely it is defined) might not be responsible for that one: the guy who added that "feature" seems to be working independently: he used his username directly in the code...
The guy is part of the Cyanogenmod team, he used his username so he could grep the debug output he created with that log line while a testing a feature he was working on.
To sum it up:
Not a big deal, just left over debug code.
Not really a vulnerability either, because in most cases where you can read the local log file you already unlocked the phone in the first place.
--
Me
If an official ROM did this it would be taken as an evil invasion of privacy by Samsung, HTC or Google, but when the Cyanogen team does it it's immediately accepted as an accident.
Interesting.
No, things like this have happened with the larger developers and it has always been explained as a bug and accepted as incompetence. The times you see outrage is when the larger developers logs data and send it to them as part of the intended function. Cyanogen has not done anything like that yet and indie teams generally don't have an interest to do so.
So, nothing to see here, move along.
Not interesting in the slightest. The difference between evil invasion of privacy and an accident is purely intent.
If a company had done it you can't prove it one way or another so it's safe to assume the worst.
If on the other hand it's done to code that is openly published at a time where a feature is modified which during developing would have clearly called for logging the actions to file for debugging purposes it shows quite a different level of intent.
You can still assume the worst, but if you do in this case we'll just assume your tinfoil hat would need to be retuned.
Or you have a program running on it that is looking for that information and sending it to you via the cellular data channel.
Imagine what the criminals of the world will do with a database of android unlock codes and gestures!
Do not look at laser with remaining good eye.
What protection can you really expect from the screen lock? Someone who is determined enough can usually use the android debugging bridge to do whatever the hell they want with it anyway (either in recovery or when booted up). As the saying goes: if you have physical access to a device... all bets are off anyway.
The screen lock is simply to protect against most "attackers".
You can bypass the lockscreen on any phone that has CM installed. Just hook it up to a PC with a USB cable, up pops the "Turn on USB storage" screen, hit Home, bam, you're in.
I don't use any lockscreen gesture or password, because I find them a PITA, and I want my gf to be able to use it without hassles. On the other hand, I try to treat my phone as I treat my wallet. I look around me when I pull it out of my pocket. I wait until the subway doors are closed. Etc.
Oh, it's open source so it's all good?
Open source is so fast to get a pass on being Evil(tm) around here. More people who own an Android phone have the skills to rebuild an engine than to properly interpret the source code of their phone. Open source only matters if you have the skills to understand the code. The vast majority of people running CyanogenMod don't have this skill set.
What am I missing? What good is the gesture and unlock code without the phone?
You are welcome on my lawn.
And it's a nightly build! Not a stable release!
Wait, was that sarcasm?
I have a condition where I cannot determine sarcasm before 7am.
You are welcome on my lawn.
The difference is that I trust CyanogenMod more than I do the big corporations. I have seen them "do no evil". This makes it seem like a more honest mistake, in a nightly build no less. The other large corporations, have given us reason to have trepidation.
Basically, the story is that:
It is debugging code left in a development build, that happens to be used by many persons as nightlies.
It does not write to a file. It is debug information written to a ring buffer in RAM. You would need to have an app installed with permission on the logs, or connect a cable in debug mode and trace the log to even get these messages.
It was found in a code review, and removed.
So much a non-issue that it is a wonder that Ars even reported it. Seems Ars misread a mailing list heads-up. We are waiting for Ars to publish the correction to their article.
Prediction for end of Universe #42: Fencepost error in Quantum_bogosort.cpp
A issue in a nightly build! OMG!
Ahh, you miss the point. The vast majority do not need to understand the code.
Open source's strength is not that everyone has to read/understand the code -- it is that everyone can. It takes only one person to find an issue, then others can see for themselves and confirm/fix. If the vendor not fixing it fast enough, a fork or patch can be done without vendor's approval. On the other hand when Apple logged your location, it was only found by accident because they left data laying around. Then you had to wait for Apple to fix it, which, for all we know, they did by not leaving the data easily findable.
Of course that is not perfect and plenty of bugs and issues do not get found quickly in Open Source - but if it is popular enough, it is much harder to be evil on purpose and hide it.
Oh, it's open source so it's all good?
Open source is so fast to get a pass on being Evil(tm) around here. More people who own an Android phone have the skills to rebuild an engine than to properly interpret the source code of their phone. Open source only matters if you have the skills to understand the code. The vast majority of people running CyanogenMod don't have this skill set.
RelevantElephants: A Somatic WebComic...
I disagree with that. No matter the intentions harm is still possible. So are you saying that if it were a company somehow they are only capable of malicious capitalistic greed, and do not possess the ability to make a mistake? That seems a bit over the top (speaking of tinfoil hats...). In this case it requires physical access to the device, and is therefore less of an issue than if it could be accessed remotely, or worse uploaded and stored on some centralized server. Rest assured that open or closed source is not the issue here.
What am I missing? What good is the gesture and unlock code without the phone?
Just imagine what the criminals will do!!! IMAGINE!
Do you Gentoo!?
Nope. Log access is restricted with Jelly Bean onwards to the app's own logs only. You need root access to circumvent that. See http://android.stackexchange.com/questions/28857/how-can-i-access-android-log-files-on-my-nexus-7-without-root-access
I disagree with that. No matter the intentions harm is still possible. So are you saying that if it were a company somehow they are only capable of malicious capitalistic greed, and do not possess the ability to make a mistake? That seems a bit over the top (speaking of tinfoil hats...). In this case it requires physical access to the device, and is therefore less of an issue than if it could be accessed remotely, or worse uploaded and stored on some centralized server. Rest assured that open or closed source is not the issue here.
It's a matter of means, motive, and opportunity.
On one side, you have a company. It's sole purpose for existence is the creation of profit for its shareholders. Because their products are closed, they can introduce a security flaw under cover of closed source ("opportunity"). Because they make the product, they the only ones who can introduce the security flaw ("means"). Security flaws are potentially lucrative and the only reason a company exists is to make money ("motive").
On the other side, you have an open-source ROM project. They create the project, so they have the ability to introduce a security flaw ("means"). The code is open, so creating a security flaw that can't be spotted is very difficult to impossible (lack of "opportunity"). Because the ROM project is not for sale, a security flaw is not lucrative for the maintainers (lack of "motive").
You can rest assured that open or closed source is precisely the issue here.
by PopeRatzo (965947) on Wednesday October 24, @07:52AM
I have a condition where I cannot determine sarcasm before 7am.
Whew, dodged that one!
As a curious Cyanogenmod user, does anyone know specifically what builds are affected? I'm assuming all of the nightly builds since this was committed include it, but since I now stick to the M-builds I'm wondering if it's in those too.
The thread following TFA mentions that this is for CM10 nightlies, so if you're tracking the development branch, you just need to upgrade to the latest nightly to ensure you have the fix.
We are the music makers. We are the dreamers of the dreams.
"An alternative to removing the line is adding a character to the code so it's treated as a comment and isn't executed." What is this wizardry?
Run for Office?
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
The fix was in the nightly, not the bug. The bug has been there for months.
For whatever it's worth this is sloppy coding. As of ADT 20 there is an automatically generated java file called BuildConfig with a single constant DEBUGGING.
So the way this line of code should have been written is something like this:
if (BuildConfig.DEBUGGING) Log.v (TAG, "some logging info");
That said, this isn't exactly leaking bank details, it's a swipe gesture. It's good they caught it, but it's not a huge security risk unless you lose your device.
PocketPermissions Android Permission Guide
Or law enforcement - imagine what they can do with the data - they sieze your phone, plug it in to see if it'll spew data out the USB port while locked. If you have USB debugging on, they could look at the logcat and see the unlock code and use it to legitimately snoop around (it "wasn't locked - it just had a very fancy "slide to unlock" function).
Given how cellphone's legal status as a container is in doubt, this could be potentially troubling. (And face it - those who use CM nightlies probably HAVE USB debugging on.
And on my non-CM JB phone, you can access adb and the logcat while it's still locked.
Never heard of "time zones"? I posted it at 06:52 CST.
You are welcome on my lawn.
Android flavor messes up security and Apple gets dissed. Standard day on /. :)
Move along people, nothing to see here
...if the results were uploaded to a central location for data mining. I wonder what patterns are the most popular...
No what I am saying is that without context we can assume the worst. Companies can and often do make mistakes, and if those mistakes are found through a process of auditing rather that security researchers finding locally stored sensitive information as is usually the case, then they would be forgiven.
The issue here is that the open source provides context into what happened. Could it have been nefarious? Possibly, but given the incident, the full code review provided and the timetable it is quite unlikely.