Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Android Security

Android Lollipop Can Be Hacked With Very Long Password 170

Posted by timothy from the ipso-facto-presto dept.
Complex passwords are the way to beat some attacks, but for phones running the latest version of Android, that's not necessarily so: puddingebola writes with an excerpt from an article at CNN: Locked phones require a passcode. But there's a way to get around that. Just type in an insanely long password. That overloads the computer, which redirects you to the phone's home screen. It's a time-consuming hack, but it's actually easy to pull off. In a report published Tuesday, computer security researcher John Gordon documented the vulnerability and posted a video of the hack. It only affects smartphones using the latest version of the Android operating system, Lollipop.
This discussion has been archived. No new comments can be posted.

Android Lollipop Can Be Hacked With Very Long Password More

Android Lollipop Can Be Hacked With Very Long Password

Comments Filter:

  • Article is bullshit (Score:5, Funny)

    by bluefoxlucid ( 723572 ) on Thursday September 17, 2015 @10:28AM (#50540499) Homepage Journal

    That's impossible. It's Java! Java can't have security holes! Everyone knows you don't write C because C has buffer overflows and can cause security problems when you paste in very long strings, and that NEVER happens with Java! Java is perfect! Everything you write in Java is perfectly secure! Ask any Java programmer!

    • What is old is new (Score:5, Informative)

      by goombah99 ( 560566 ) on Thursday September 17, 2015 @10:33AM (#50540535)

      early versions of mac OSX had a similar problem. 10,000 character password entries would unlock the system. Entering these was aided because the password field accepted emacs key commands (like every other field on a mac) so repeated ctrl-a ctrl-k ctrl-y ctrl-y ctrl-y quickly got you to the passwrd field overload point.

      • Re:What is old is new (Score:4, Interesting)

        by Tough Love ( 215404 ) on Thursday September 17, 2015 @12:12PM (#50541277)

        The metaproblem here is that Google is less competent than they imagine to develop Android by themselves as they do. The short form of that is one word: hubris.

        • Hear, hear!

        • If you want proof of googles incompetence then look no further than the incomprehensible labyrinth of android studio, especially when you compare it to alternatives. Oracle makes things hard enough with for less than dedicated users with netbeans. Eclipse is really nice for dilettante users. Xcode for all its complexities is really a marvel since it handles so many different development needs with uniformity and great consistency over years.

          • I don't need further proof of Google's incompetence but apparently some people do.

            • Well, here's further proof from just this morning: Google device manager was changed so that it now won't set a new Android device password remotely if the screen is locked, so if your wife forget her password your choices are 1) Factory reset or 2) Kill yourself. I wonder how much Jolt it took to come up with that one.

              Google's new motto: We're too smart to think.

        • Re: (Score:2)

          by gweihir ( 88907 )

          Google is a lot less competent in many areas than they think they are. For example, their research papers suck badly. That they do not really know how to handle Android is no surprise. Maybe if they had hired some people with experience and maturity instead of highly-intelligent but otherwise retarded ones.

      • early versions of mac OSX had a similar problem. 10,000 character password entries would unlock the system. Entering these was aided because the password field accepted emacs key commands (like every other field on a mac) so repeated ctrl-a ctrl-k ctrl-y ctrl-y ctrl-y quickly got you to the passwrd field overload point.

        What versions? One of the Developer Previews?

        Honestly, not only have I never heard of this vulnerability in OS X; but I couldn't find it on Google, nor, more importantly, could I find a "CVE" Reference to that alleged vulnerability, either. In fact, the CVE list only shows 92 Vulnerabilities for OS X from 2001 to present (and the vast majority being ranked level "2.1" on a scale of 2.0 to 2.99), as compared to 481 for Windows 7, 221 for Windows 8, 169 for Windows 8.1, and (drumroll please) 29 already for

    • Comment removed (Score:5, Insightful)

      by account_deleted ( 4530225 ) on Thursday September 17, 2015 @10:36AM (#50540553)
      Comment removed based on user account deletion

      • Re:Article is bullshit (Score:5, Interesting)

        by benjymouse ( 756774 ) on Thursday September 17, 2015 @10:56AM (#50540699)

        Nothing to do with java. Buffer overflows are quite possible with java, but this problem has everything to do with shitty coding, not the implementation language.

        No, but this problem has everything to do with shitty operating system design. The login "screen" should not just be an application that maximizes it's screen to cover the UIs of all other application. That is a naïve implementation, and it opens the supposed security feature up to all kinds of attacks, including shatter attacks and more. Not to mention that an application crash will cause the OS to clean up and close the "blocking" window.

        Google should take a cue from Windows and make the login screen a totally separate "desktop" which is completely isolated from the "user" desktop. Switching between the two should be a privileged operation, one that can only be executed by trusted login applications. This way a mere exception will not cause the "login" program to crash, close and reveal the user desktop.

        • Re:Article is bullshit (Score:5, Interesting)

          by Anonymous Coward on Thursday September 17, 2015 @11:57AM (#50541139)

          Windows' login screen isn't on a separate desktop. It's the only desktop.

          The boot process hands control to the kernel loader (ntldr), which starts the kernel (ntoskrnl and kernel32), which starts the service control manager (scm), which starts winlogon.exe, which calls security account manager (sam) to authenticate and then spawns instances of the local security authority (lsass) for each user that logs on. The lsass process, in turn, hosts virtual desktops for the user. Usually there are 2 virtual desktops per user: the regular visible one and the "secure" one that is only used for UAC prompts. Everything within those virtual desktops runs at the mercy of lsass.

          So you basically have the right idea, but described it the way Unix-based systems do it. Instead, Windows' nested/hosted startup process requires less plumbing than the method you describe. You don't need to protect the log-in program from "untrusted" execution if it's only allowed to run once (a simple mutex can handle enforcement) and it runs from boot and hosts everything in userspace. It's basically the kernel's userspace process supervisor.

          • So you basically have the right idea, but described it the way Unix-based systems do it.

            On any Unix desktop environment that I know, the login screen runs before the user desktop is even started. Actually, after logging in you can see how the user desktop starts up, complete with this progress-bar like thingy in the middle of the screen.

            What you might think is the lock screen, which is indeed a kind of window which entirely covers the normal desktop, and which can be "shattered".

        • No, but this problem has everything to do with shitty operating system design. The login "screen" should not just be an application that maximizes it's screen to cover the UIs of all other application.

          You're thinking from a security point of view. In reality the lockscreen is a function of the device that interacts with many running programs, widgets, allows apps to draw on it, modify it, still provides access to a whole host of phone functions such as adjusting brightness, volume, putting the phone on silent, dialing emergency numbers, accessing and dialing specific contacts in the contact list, even starting up certain applications in a limited functionality like the camera.

          Your limited lockscreen woul

      • Re:Article is bullshit (Score:4, Interesting)

        by Greyfox ( 87712 ) on Thursday September 17, 2015 @11:09AM (#50540801) Homepage Journal
        Java was supposed to protect you from shitty coding. "Oh, use Java," they said, "and you'll never have to worry about memory management or buffer overflows again!" It's true. They said that. They said you could write your program once and run it everywhere. They said you could use Java and hire chimpanzees to do you programming for you.

        All those promises only turned out to be true-ish. The chimpanzee quota for most teams actually remained fairly consistent. Turns out a lot of companies were hiring chimpanzees before Java came along. Some of the chimpanzees tried to use Java for system-level programming, and it turned out to not be very good at that. While it was technically true that you didn't have to worry about memory management anymore, if you didn't, you mostly handled your server running out of memory and crashing every few days by rebooting it every couple of days. Logs became a morass of unhandled and permanently ignored exceptions. I often start a new job, look in their logs directory and find gigabytes of exceptions that no one ever looked at.

        But you know, it's still better! Because now instead of most programs being giant masses of functions that reimplement system API commands and never take responsibility for any action, they're now giant masses of objects that reimplement system API commands and never take responsibility for any action. Some of them just pass messages around from service to service, none of which anyone truly understands since the system designer was laid off years earlier.

        Arguably yeah, implementation language doesn't make a difference. All those teams could have written shitty code and poorly designed systems no matter what language they were using. The implementation language just makes it easier to operate without any discipline and maintain the illusion that they're competent at what they're doing.

        • Java was supposed to protect you from shitty coding

          No, it wasn't. Remember, it's much better to sit quietly in the corner and let everyone think you are a moron, than to post on /. and remove all doubt.

      • ...this problem has everything to do with shitty coding...

        Understandable when you consider that most programming at Google is done by oversexed, overpaid interns still wet behind the ears. The name of the game at Google is to make it from intern to FTE so that your main duties become emailing, facetime and offsites, and your interns will do the coding.

    • Re: (Score:2)

      by Kkloe ( 2751395 )
      maybe they are trying to enter the weight of your mom

      still not having to worry about memory management beats any language nowadays, we are making enough powerful computers nowadays to run a machine in a machine in a machine

    • Re: (Score:2)

      by gnupun ( 752725 )

      It's Java! Java can't have security holes!

      Java is just a middle layer. Ultimately, the Java code will have to call native C code, where a buffer overflow is most likely occurring. So the flaw is still in C. Or it could be a poor implementation of Java. Either way, it's not Java's (the language, not implementation) fault.

      • Re: (Score:3)

        by tnk1 ( 899206 )

        I'm not totally against Java, but having worked with it since it was released 20 or so years ago, I note that Java was touted as a language/VM/bytecode/whatever where you didn't need to worry about memory management aside from some tuning.

        The reality is that Java saves you from having to write your own MM, but that's only helpful if their memory manager is actually better than something you could have written for yourself. Initially, the MM was nowhere near as good as it is today, although it was clearly "

    • Re: (Score:3)

      by AC-x ( 735297 )

      Ah but you see Java has saved the day, for instead of a dangerous code execution buffer overflow condition the program simply quits out with a safe exception! :)

    • Re: (Score:2)

      by glwtta ( 532858 )
      Are... are you OK? Anything we can do to help?

    • Re: (Score:2)

      by znrt ( 2424692 )

      (pssst. it's dalvik, actually)

    • That's impossible. It's Java! Java can't have security holes! Everyone knows you don't write C because C has buffer overflows and can cause security problems when you paste in very long strings, and that NEVER happens with Java! Java is perfect! Everything you write in Java is perfectly secure! Ask any Java programmer!

      I am a java programmer and I wholeheartedly agree with you. Java can't let you down, though the hardware could!

  • Hardware Access (Score:3, Insightful)

    by Barny ( 103770 ) on Thursday September 17, 2015 @10:29AM (#50540501) Journal

    Yeah, if you have hardware access to a device you own it. Nothing new to see.

    • Re:Hardware Access (Score:5, Interesting)

      by bill_mcgonigle ( 4333 ) * on Thursday September 17, 2015 @10:39AM (#50540583) Homepage Journal

      Yeah, if you have hardware access to a device you own it. Nothing new to see.

      Really? I'd love to bypass the bootloader on MY Verizon-compatible Kitkat GS4. Please post links.

      • Re: (Score:2)

        by ichthus ( 72442 )
        I wonder how many people here, like me, went to this page [cyanogenmod.org] thinking they'd be able to respond to your challenge, only to see the warning about bricking the phone. I feel bad for you -- my T-mo GS4 is so much better with Cyanogenmod installed.

      • Really? I'd love to bypass the bootloader on MY Verizon-compatible Kitkat GS4. Please post links.

        It can be done, it's just a matter of how much money you are willing to spend to get that result. It's not like Samsung suddenly stopped putting bugs in their bootloader.

      • Locked bootloader on my Verizon S5 as well. Cocksuckers.

      • Re: (Score:2)

        by rastos1 ( 601318 )

        Yeah, if you have hardware access to a device you own it. Nothing new to see.

        Really? I'd love to bypass the bootloader on MY Verizon-compatible Kitkat GS4. Please post links.

        Obviously the corollary is that you do not really own the device. Sorry if you thought otherwise.

    • Yeah, if you have hardware access to a device you own it. Nothing new to see.

      That's actually not true on iOS where the unlock code actually forms part of the master key [apple.com] from which filesystem keys are derived. So hardware access without the unlock code nets you nothing. Of course, with a 4-digit code it's only a few days to try all 10000 of them, but users can a complex passcode with sufficient entropy to make brute force impractical.

    • Re: (Score:2)

      by mackil ( 668039 )
      You're right, but I was rather counting on the lock screen to keep my kids out of my phone. Now nothing can stop them from installing Angry Birds.

    • Yeah, if you have hardware access to a device you own it. Nothing new to see.

      My BlackBerry Z10 says otherwise.

    • Yeah, if you have hardware access to a device you own it. Nothing new to see.

      A system that lets you bypass the password easily is a system with plenty of remote vulnerabilities.
      People weren't thinking about security while they were programming.

  • is nothing but a matter of time and effort. Nothing is secure. Anyone who touts how secure their software product is is in for a fall.

    Software security will be a game of whack-a-mole forever.

    • Ehn, this is particularly weak. This isn't a matter of a few hours, it's short enough to fit into a quick youtube video. :/

      • good response. there is indeed obscure, difficult, fleeting, technically sophisticated, damage limited security breaches, and "oh my fucking god how could you screw up so badly" security breaches that any idiot can perform to get full access

        getting the home screen after punching in a crazy long password is a really embarrassing fail on google's part

        reminds me of "hacking" windows 98 security:

        http://imgur.com/gallery/fqjnK [imgur.com]

    • is nothing but a matter of time and effort.

      While you're technically correct (the best kind!), if it would take longer than the expected lifetime of the universe to crack an encryption key, I'm willing to accept that as good enough.

      • with today's technology

        as technology advances over the years, today's encryption key standard is going to be cracked in a scary short time

        regardless, the topic is security exploits, back doors, hacks. not the brute forcing of a solid security implementation

  • I figured it was mostly for the corporate identity change and logo changes Google is has been doing recently. I could see this fix being in there.

    On another note I mourn the loss of the GPE edition. It was a good idea and should stay.

  • pin code not vulnerable (Score:5, Informative)

    by sociocapitalist ( 2471722 ) on Thursday September 17, 2015 @10:36AM (#50540559)

    Only works against passwords and only in certain cases.

    Does not work against pin codes or swipes.

    • Re: (Score:2, Insightful)

      by freeze128 ( 544774 )
      When I set up and unlock swipe pattern on my phone, I wanted to make sure it was not something simple that someone would guess. I was dismayed that:

      You can't swipe to a non-adjacent point
      and
      If you double-back on your swipe path, you don't need to enter that double-back part of the path when unlocking.

      I think using a swipe pattern is even LESS secure than using a pin with the same number of digits as swipe points.

      • Re: (Score:3)

        by asylumx ( 881307 )

        You can't swipe to a non-adjacent point

        Yes you can. My passcode has this on my android craplet at home. It's just difficult because if you pass over another point to get there it will add the other point too. Since it is similar to a keypad, all you do is go for example from the 9 position to the 4 position (corner on one side to middle on opposite side) without crossing the center point. They are not adjacent, yet you can use them.

        • I think that was the point being made: it's not about the physical motion of "swiping", the problem is that the pattern is forced to be a contiguous line at all.

          Whether I tap two corners and it adds the middle point automatically, or whether I swipe from one corner to the other, it doesn't matter because the problem is the same: this strategy reduces the total possible count of unique patterns.

          The better implementation would be for the pattern to be detected as a sequence of activated points, where those po

          • Re: (Score:2)

            by adolf ( 21054 )

            You already have this functionality on your device: A grid of symbols, which can be activated in any order, or perhaps repeated. The symbols even flash briefly as they're activated.

            It's called a PIN.

      • I think using a swipe pattern is even LESS secure than using a pin with the same number of digits as swipe points.

        Agreed completely

    • This seems to rely on the Camera app crashing which makes me wonder if any manufacturers who ship their own camera app (i.e. Samsung) are even exposed at all.

  • A long password? Fuck. Just fuck.

  • And it has been fixed (Score:4, Informative)

    by necro81 ( 917438 ) on Thursday September 17, 2015 @11:14AM (#50540835) Journal
    The vulnerability was disclosed to Google, who has developed a patch, which Google released last week. So, it makes for a funny story, and a teachable moment, but does not necessarily mean OMG-We'z-Been-Hax0red!

    • This is especially true of us folks not using the password feature. Patterns and PINs are not included in this attack. I'm going to go out on a sturdy limb here and say my fingerprint scan isn't either.

      • Re: (Score:2, Funny)

        by Anonymous Coward

        The hack works for extremely large thumbs.

    • Re:And it has been fixed (Score:5, Insightful)

      by ITRambo ( 1467509 ) on Thursday September 17, 2015 @11:33AM (#50540957)
      I'm pretty sure that most users will not get the patch for a very long time, if ever, due to carriers not caring one bit about updating in a timely manner.

      • I'm pretty sure that most users will not get the patch for a very long time, if ever, due to carriers not caring one bit about updating in a timely manner.

        This. It seems that the US carriers rarely send out OS updates for the many security updates. This needs to change.

        • The simple fix would be to make them liable for any break-ins for known security issues not patched within 30 days of availability for phones sold in the last 3 years.

          Shipping already orphaned phones is awful. Shipping a phone with vulnerabilities that will never get fixed should be criminal.

          I'm in the market to replace my phone, and it is just a sea of crap to wade through. It is very hard as a consumer to figure out how much crapware there is on a phone, or what the odds of ever getting an update are, o

        • I'm pretty sure that most users will not get the patch for a very long time, if ever, due to carriers not caring one bit about updating in a timely manner.

          This. It seems that the US carriers rarely send out OS updates for the many security updates. This needs to change.

          That change can be had TODAY. [apple.com]

          • I'm pretty sure that most users will not get the patch for a very long time, if ever, due to carriers not caring one bit about updating in a timely manner.

            This. It seems that the US carriers rarely send out OS updates for the many security updates. This needs to change.

            That change can be had TODAY. [google.com]

            Fixed that link for you.

            • I'm pretty sure that most users will not get the patch for a very long time, if ever, due to carriers not caring one bit about updating in a timely manner.

              This. It seems that the US carriers rarely send out OS updates for the many security updates. This needs to change.

              That change can be had TODAY. [google.com]

              Fixed that link for you.

              Really? Looks like a broken link to me. ;-)

          • Can't find the model of iPhone with an SD slot, removable battery, 1080p screen that still fits in my pocket, that runs the apps I've already got. It seems like I'd also lose access to several of the app stores I'm accustomed to using =/

            Just go with a Nexus device. No crapware, longer support, and if you're already accustomed to Android, you've got access to your apps and a familiar UI.

      • If they have a carrier that doesn't care about updates they wouldn't have the very latest android version (the one affected) the first place.

      • Re: (Score:2)

        by wbr1 ( 2538558 )
        Nexus 6 babeeeeeeee

    • Re: (Score:2)

      by gsslay ( 807818 )

      If you RTFA you'll see that the problem is (and this is nothing new for Android) that patches take ages to percolate from Google down to the various distros managed by manufacturers and phone networks. And that's only if the end user allows updates.

      So this hack is likely to be live and exploitable for some while yet.

      • And that also assumes that the convenience-minded users of these devices use the less convenient (when compared to PIN or Pattern locks) Password lock. It's so rare I can honestly say I've never seen it used outside the 5 minutes I had my phone configured to use it about 4 years ago. I am security-conscious but it completely negated the very reason I carry a phone-capable pocket computer with me in the first place: to fetch information as quickly as possible.

        I can't help but think having a full QUERTY key

    • The vulnerability was disclosed to Google, who has developed a patch, which Google released last week. So, it makes for a funny story, and a teachable moment, but does not necessarily mean OMG-We'z-Been-Hax0red!

      The vulnerability was disclosed to Google, who has developed a patch, which Google released last week, which very few end-users will ever see.

      FTFY.

      • The vulnerability was disclosed to Google, who has developed a patch, which Google released last week. So, it makes for a funny story, and a teachable moment, but does not necessarily mean OMG-We'z-Been-Hax0red!

        The vulnerability was disclosed to Google, who has developed a patch, which Google released last week, which very few end-users will ever see.

        FTFY.

        The vulnerability was disclosed to Google, who has developed a patch, which Google released last week, which very few end-users will ever see, and which affects very few people to begin with.

        FTFTFY

        • The vulnerability was disclosed to Google, who has developed a patch, which Google released last week, which very few end-users will ever see, and which affects very few people to begin with.

          FTFTFY

          Then why did it rate a Slashdot article to begin with? Or are you saying it will only affect a few people because Lollipop hasn't been out very long? That's small comfort.

          • Then why did it rate a Slashdot article to begin with?

            You're taking the piss right?

            Or are you saying it will only affect a few people because Lollipop hasn't been out very long? That's small comfort.

            No. It affects all previous versions of android. HOWEVER: It only affects a few people because of the specific setup required: Google's built in homescreen + Google's built in camera app + password combination. The typical unlock scenarios you see are by preference:
            1. Pattern unlock
            2. Pin unlock
            3. Swipe unlock (no security).
            4. Password
            followed by what ultimately is a rounding error compared to the above:
            5. Fingerprint unlock
            6. Face unlock.

            i.e. straight off the bat every Samsung

  • I don't use a password. Why is my url mobile.slashdot.com when I'm on a desktop?

  • Progress in computing (Score:3)

    by thrig ( 36791 ) on Thursday September 17, 2015 @11:54AM (#50541109)

    It's like gets(3), only different!

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close