32 ms·

Accidental Google Pixel Lock Screen Bypass

• varjag 4y ago
  Bottomline: have buddies at Google if you want anything ever get fixed.
  • DonHopkins 4y ago
    Well there just went my chances of getting anything fixed at Twitter or Facebook...
    • saagarjha 4y ago
      I doubt Twitter would be fixing much of anything even if you knew someone still there.
  • s4i 4y ago
    Applies to YouTube too.
    • MPSimmons 4y ago
      which is also Google
      • phist_mcgee 4y ago
        Technically Alphabet.
        • jonny_eh 4y ago
          YouTube is a part of Google. It's not a separate "bet" like Waymo.
  • htrp 4y ago
    and Facebook... and every other company too cheap to pay for support.
• lizardactivist 4y ago
  Pretty alarming, and there's a ton of other complex security implications arising from this.
• intrasight 4y ago
  A fun and interesting read. But it is frustrating to hear that such a major security bug was ignored until a happenstance meeting with Google engineers.
• 2OEH8eoCRo0 4y ago
  > The bug just got fixed in the November 5, 2022 security update. Lovely. My Pixel 4 got it's last update in Oct.
  • EspadaV9 4y ago
    Could try checking out https://grapheneos.org/ https://grapheneos.org/, it looks like they are supporting the Pixel 4 for a little longer. In this case though, you would hope Google release an extra patch for the Pixel 4, they knew this bug was there and a fix was in the pipeline.
  • x0x0 4y ago
    Same. Absolutely unbelievable that they sat on this to avoid having to fix it.
  • lupire 4y ago
    Don't worry, your phone has already has other vulns.
  • deleted 4y ago
    [deleted]
• itsthecourier 4y ago
  Have you tested this on other brands?
• Waterluvian 4y ago
  Given the bug was already reported (and even more ignored) it seems like the $70,000 was really a “you made us do our jobs” fee.
  • tyingq 4y ago
    It read like the payment came only when disclosure was imminent. Google basically extorted themselves into paying it to encourage pushing disclosure out a couple months.
    • not1ofU 4y ago
      Security through ̶o̶b̶s̶c̶u̶r̶i̶t̶y̶ bribery *Edit: ̶H̶o̶w̶ ̶t̶o̶ ̶s̶t̶r̶i̶k̶e̶t̶h̶r̶o̶u̶g̶h̶?̶ - cheers
      • kuroguro 4y ago
        Not sure if they have that https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc
      • auxermen 4y ago
        As far as I'm aware you can't, maybe this works though https://unicode-table.com/en/tools/strikethrough-text/ https://unicode-table.com/en/tools/strikethrough-text/ ̶t̶e̶s̶t̶
    • titaniczero 4y ago
      Yeah, they tried to set up a call to dissuade him but he stood by his decision. Then only 3 days before the disclosure deadline they decided to pay out.
• notRobot 4y ago
  Seems to me like this impacts not only Pixel devices but all Android devices? Patch was to AOSP: https://github.com/aosp-mirror/platform_frameworks_base/commit/ecbed81c3a331f2f0458923cc7e744c85ece96da https://github.com/aosp-mirror/platform_frameworks_base/comm... I don't have a locked SIM handy, but can someone please test on their non-Pixel device and confirm?
  • Semaphor 4y ago
    Not testing it right now, but my understanding is, that the issue is technically for every device, but the specific condition (putting the lockscreen on top of the secure screen stack right before `.dismiss()`-ing) is a Pixel software bug.
  • izacus 4y ago
    Thing is, most phone manufacturers will customize the lockscreen quite a bit, so it's possible (but not necessary!) it affects others.
    • notRobot 4y ago
      Yeah, agreed. I wonder if it affects LineageOS, which I run.
      • rex_lupi 4y ago
        It does.
        • notRobot 4y ago
          Oh no. Do you have a source?
          • rex_lupi 4y ago
            Tried
    • octagonal 4y ago
• feintruled 4y ago
  Very interesting. To summarise, I think the issue is that the phone gets itself into a state of waiting for a locked SIM to release itself before it unlocks the phone - the problem being the attacker could have their own pre-locked SIM they can hotswap in that of course they know the code for, and this will erroneously also unlock the phone.
• bluocms 4y ago
  How come the security model is so basic? I even think they should dismiss modal by id instead of type. As this is a highly sensitive part, I think stacking lock screens on top of the unlocked menu leaves the door open for many bugs that could unlock your device. The unlocked menu should be locked at all times, and use a flag to monitor if it’s locked/unlocked, and only flip the flag when you unlock with biometrics or with password. If the flag is locked, then the whole screen is black and can’t have any interactivity via touch, mouse, kw… This way is more robust, so even if you manage to bypass the stack of lock screens, you end up with main menu locked.
  • Apreche 4y ago
    I was also thinking they should only dismiss by ID instead of type. The other question is, why would background tasks be permitted to call dismiss at all? I can imagine a scenario where you get a malware app installed using whatever method. Then when you get physical access to the phone, you send a notification to the malware app. The malware app in the background calls dismiss on every possible type several times to unlock any possible security screens. There should be some sort of lock/flag/semaphore that is held by the current top level security screen. Dismiss should only be callable by whatever process has a hold of that. Dismiss calls from anyone else should not only be denied, but processes that make such calls should be blocked, quarantined, marked as suspicious, etc.
    • lupire 4y ago
      If an non-system app can call dismiss at all, it's already game over.
      • Apreche 4y ago
        Oh, of course.
  • ballenf 4y ago
    I think an even better approach would be to have the concept of fixed tiers of locking combined with evicting the decryption key for any Lock Screen above the basic PIN. And you can only move down one tier of unlocking at a time. Unlocking SIM PIN moves you down one tier to phone PIN screen.
• deleted 4y ago
  [deleted]
• sunaurus 4y ago
  I was under the impression that decrypting storage actually requires the passcode of the phone, but this bug makes it look like the device is able to decrypt itself without any external input. Does anybody know more context about this? What's the point of encryption if the device can just essentially backdoor decrypt itself?
  • deleted 4y ago
    [deleted]
  • dgl 4y ago
    In the write-up search for the bit that says "and one time I forgot to reboot the phone". tl;dr: It's not an encryption bypass, it bypasses the lock screen once the phone has been unlocked once.
    • skydhash 4y ago
      Which is equally important. Most people have their phone in that state than powered down.
    • ashleyn 4y ago
      I wonder if this can bypass the "Lockdown" mode. I always recommended people switch the phone fully off in lieu of using Lockdown.
  • perlgeek 4y ago
    It seems to me this bug appears when a phone is booted, unlocked (and decrypted) once, and then locked again, but the decryption key still stays in memory.
    • Gilboboy 4y ago
      This is virtually always the case with these kinds of vulnerabilities on smartphones. Security researchers often say whether an attack or vulnerability is possible "before/after first unlock" in reference to the fact that the security is a totally different story if the phone has been unlocked/decrypted since last boot.
• phreack 4y ago
  I can't believe this is not a "drop everything and get it fixed ASAP" bug. This makes me think there's probably tons of other similar bugs out there being exploited right now even with disclosure.
  • urthor 4y ago
    I forget which Pixel generation. For one generation Google I believe never shipped the ability to unlock your phone with your face. Despite having all the hardware on the phone, it just didn't have the feature. This was a serious feature deficit viz a viz the relevant iPhone at the time. The gossip was, the feature was finished, completely. Had to be ripped out after external pen-testing bypassed it with Facebook photos. They have many, big, problems.
    • mschuster91 4y ago
      > This was a serious feature deficit viz a viz the relevant iPhone at the time. IIRC, the iPhone uses not just a photo from the selfie cam, but adds infrared to construct a sort-of-3d-ish depth map of your face as well - that is what defeats a simple attempt at unlocking with photos. Now, the really interesting thing to research is if a silicone molded face mask could be used to fool the iPhone into unlocking. Photos or videos of the subject in multiple angles should be enough to create a decent enough 3D face copy.
      • jerpint 4y ago
        A video rotating around a subject + nerfs could maybe get you the 3D face copy pretty easily
      • endisneigh 4y ago
        Won’t work - https://9to5mac.com/2019/12/16/3d-mask/amp/ https://9to5mac.com/2019/12/16/3d-mask/amp/ Muscle movement is also now necessary so it’s pretty difficult to circumvent
        • 4y ago
• feintruled 4y ago
  Glad he got rewarded. Feels like this could have played out differently, if it had hit his disclosure deadline we might have been reading about him going to prison, such is the febrile nature of the legal situation around vulnerabilities.
  • lrvick 4y ago
    I tell companies 90 days. When they ignore me I go public at 90 days, consequences be damned. No jail time for simply telling the truth about a discovery I made on my own time. https://www.vice.com/en/article/3kxy4k/high-tech-japanese-hotel-service-robots-easily-hackable https://www.vice.com/en/article/3kxy4k/high-tech-japanese-ho...
• skar3 4y ago
  It would be interesting to understand if it is also reproducible in other brands
• endisneigh 4y ago
  This is a great example of why you should use iOS. Most android devices do not receive security updates long enough to get this update. Since the author effectively tells you how to do it, all you need to do is find a pixel 4 or older and you’re golden.
  • ApolloFortyNine 4y ago
    Who knows how many bugs live in iOS as well. Security through obscurity (iOS is closed source) isn't usually considered that great a strategy. Besides the whole "can't install user software" issue.
    • endisneigh 4y ago
      The number of bugs is not the issue. The issue is that apple supports their devices longer than all android vendors. Bugs are inevitable and so the difference is support duration and speed.
      • Gasp0de 4y ago
        Really, how long?
    • acdha 4y ago
      The number of long-running bugs which have been found in popular open source projects suggests that “many eyes make all bugs shallow” should be remembered as an amusing bit of 90s trivia like Swatch Internet Time. What seems to matter more is how many auditors are actually digging in and how aggressively secure coding practices are applied. It certainly doesn’t seem like there’s a big difference between the two in terms of security but Android has more people using old software because their manufacturer didn’t want to ship an update.
      • mrguyorama 4y ago
        If something isn't being actively attacked, penetrated, scoured over, delved into, fuzzed, and poked at by MULTIPLE EXPERTS IN THE FIELD, you should assume it has several completely bypassing security vulnerabilities. “many eyes make all bugs shallow” should have always been seen as horse shit. It has the same level of evidence as other linuxy "truisms" like "worse is better" and "everything as text or a file is best" Heartbleed and shellshock sat right in public eye for quite some time, but it turns out nobody was watching.
• eterm 4y ago
  I wish closing things as "this is a duplicate" essentially required disclosure of the original (dupe) report. It may well be that it's a dupe, or it may be something that looks similar but not actually the same. And indeed as in this case it's only the follow up report that got the bug fixed. In this case it seems that contacts at google allowed them to escalate anyway and get it fixed. But so often and especially with other programs almost everything gets closed as "dupe" which is just dispiriting. In any case, if something this serious is a duplicate then there's the suspicion it went unfixed for long enough to be independently discovered and reported which is worrying.
  • j0hnyl 4y ago
    I've reported some bugs to programs on Hackerone before that were flagged as dupe and the triager did reference the original report. Chrome team does this too.
  • Cthulhu_ 4y ago
    > I wish closing things as "this is a duplicate" essentially required disclosure of the original (dupe) report. Only if it has been fixed and is allowed to be talked about, else malicious actors will submit speculative bugs to see if they catch anything.
    • lupire 4y ago
      Speculative bug reports are irrelevant, since they don't have a repro/proof of concept.
  • acdha 4y ago
    I’ve run into this with other vendors and really wished it’d get you CCed on updates so you didn’t have to ask for status periodically. It definitely doesn’t give a good impression when things drag out for aeons.
    • lupire 4y ago
      What's crazy is that it's 100% in the vendor's interest to keep this person happy, who they know can cause massive damage to their system, completely legally. The only leverage they have is the reporter's greed to get a bounty.
• MauranKilom 4y ago
  > The same issue was submitted to our program earlier this year, but we were not able to reproduce the vulnerability. When you submitted your report, we were able to identify and reproduce the issue and began developing a fix. > We typically do not reward duplicate reports; however, because your report resulted in us taking action to fix this issue, we are happy to reward you the full amount of $70,000 USD for this LockScreen Bypass exploit! Lots of mixed feelings just reading this, but at least in the end it seems like a positive outcome for everyone.
  • thrtythreeforty 4y ago
    Ah, that's a nice hack to avoid having to pay your bounties! First report: "can't reproduce, sorry." Subsequent reports: "duplicate, sorry." Then fix on whatever schedule you feel isn't too blatant.
    • djmips 4y ago
      And they stiffed him $30K
• kaimalcolm 4y ago
  Appalling handling on Google’s end here. The duplicate issue part I can understand, but why should it take two reports of a critical vulnerability to take action? Surely when the first one comes through it’s something you jump on, fix and push out ASAP, not give delay to the point where a second user can come along, find the bug, and report it. The refactor that’s mentioned towards the end of the article is great, but would you not just get a fix out there as soon as possible, then work on a good fix after that? For a company that claims to lead the way in bug bounty programs this is a pretty disappointing story.
  • whizzter 4y ago
    Reporting and investigation matters. Perhaps the initial report was only on the bypass of the lock-screen but the initial report only ran into the decrypted phone state so it was dismissed as not being exploitable (see other comments), whilst the second report actually got inside an active phone (And then was also written up in a simple, concise and reproducible way).
  • CapsAdmin 4y ago
    Just trying to rationalize, but if the "external researcher" was hired by Google to find security issues, google might have a requirement to fix the bug at its own pace. I would personally be highly suspicious of a security flaw being a duplicate though. It's can be a very convenient excuse not to pay the bounty.
  • albertzeyer 4y ago
    You can read in the conversation that Google was not able to reproduce it the first time the bug was submitted: > The same issue was submitted to our program earlier this year, but we were not able to reproduce the vulnerability. When you submitted your report, we were able to identify and reproduce the issue and began developing a fix. I wonder if it really was the same bug or what they did wrong to reproduce it. Or maybe they just made some mistake in reproducing it.
    • SamBam 4y ago
      Agreed. If the first bug was > I did something weird after putting in a new PIN, and I was able to access my home screen without my password, but I'm not sure of the exact steps I did then that's not really a duplicate. If the original bug report doesn't have enough information to recreate the steps, the second one is the only real bug report.
• jnk345u8dfg9hjk 4y ago
  Are older Pixel phones or other unpatched Android devices vulnerable to this?
  • mschuster91 4y ago
    Yes, that is the entire point why this is so nasty.
• twobitshifter 4y ago
  It’s odd that dismiss can even be called like that from a lock screen. I did not expect android to not have the lockscreen be just another activity.
• someweirdperson 4y ago
  But for sure the instruction manual says that the sim can only be inserted/removed while the device is off? Security is ensured!
  • Tepix 4y ago
    Why do you think so?
    • someweirdperson 4y ago
      Think? Ok, I checked. And it IS in the manual. From the google pixel help [0]: > "Insert a SIM card > With your phone off:" [0] https://support.google.com/pixelphone/answer/7086887?hl=en https://support.google.com/pixelphone/answer/7086887?hl=en
  • Liquid_Fire 4y ago
    I was surprised that hotswapping SIMs works, I thought it was not supported. Many phones used to have the SIM under the battery (back when it was commonly removable), ensuring you couldn't remove it without powering the device off first.
• alexmolas 4y ago
  > I mentally noted that this was weird and that this might have some security implications so I should look at it later. If I had experienced the same situation I'm sure I wouldn't have noticed that something was wrong. Kudos for noticing that and thank you for documenting it for everyone to understand :)
• drfuchs 4y ago
  If it was really a duplicate report, then where’s the HN article “I just got $100k for a security bug I reported a year ago!?”
• Jamie9912 4y ago
  Lol this reminds me of those windows login bypasses by navigating some convoluted menus
• daneel_w 4y ago
  Every once in a blue moon when I pick up my locked iPhone (which auto-locks in just 30 seconds) and engage the home button just as the screen comes alive from the gyro sensing movement, it unlocks on its own. It just flashes the PIN dialog and slides right onto the home screen. I don't use Touch ID, and never stored my print with it even once to test the feature/hardware. It's been happening ever since iOS 11, with both my 1st gen. iPhone SE and my current iPhone 8.
  • MPSimmons 4y ago
    Do you have an Apple Watch? My phone unlocks as long as I'm nearby, wearing the watch and have it unlocked.
    • macintux 4y ago
      But the Watch tells you it’s unlocking the phone.
      • snazz 4y ago
        And unlocking with the watch only works on Face ID iPhones to make it more convenient when you're wearing a mask.
        • anonomousename 4y ago
          And it doesn’t do a super great job at it - often times the underside of a table, or sofa cushions will trigger it
    • daneel_w 4y ago
      No Apple watch, and it can happen without the phone being connected to anything Bluetooth/Wi-Fi.
      • system2 4y ago
        You better record and show it to people if possible.
• coldcode 4y ago
  Given how much engineers make at Google after a long interview process to supposedly only get the best people, how significant the login system is to security, how "industry standard" the Google process is, it's not a bug that should have ever made it live. The bug fix show that the issue was clearly a case of a set of people not communicating well, code reviews being lax, and a general lack of understanding of how Android works. It's also possible that the code is too complex to understand fully which is a requirement for a correct operation. Bugs happen, but I've seen way too many cases where complexity and lack of understanding led to surprisingly bad outcomes. The login process should have the highest amount of scrutiny.
  • GiorgioG 4y ago
    I can't tell you how often I still see operating system level rotation bugs from iOS on my iPhone/iPad. Complexity kills.
  • pfortuny 4y ago
    It looks like (not an expert) they did not use a state machine there. Those kind of behaviors are better detected with them. But I am just thinking out loud.
  • deleted 4y ago
    [deleted]
  • deleted 4y ago
    [deleted]
  • lrvick 4y ago
    I have spent a lot of time in the Android codebase building security/privacy focused ROMs. It was a very dark rabbit hole and in the end I realized the 240GB of messy blobs and source code can never be understood or audited by anyone. Even if you did somehow get that much code regularly externally audited, there are piles of random binary blobs with root access supplied by cell carriers and chip vendors Google blindly includes in the vendor partition and a backdoor or bug in any one of them can burn it all down. I abandoned the project, and stopped using smartphones entirely. The only sane engineering effort that gives me hope for a trustworthy mobile device at this point is Betrusted. https://betrusted.io/ https://betrusted.io/
• btown 4y ago
  The discussion on race conditions at the end is an important one, and IMO the bugfix is a bandage at best: the notion of anything accessing the “current” object after any kind of delay, especially in an event handler, when there is any chance the thing is not a singleton, is a recipe for disaster. In this case, dismissing the “current” security code screen was a supported API surface and that should set off all the red flags. Of course it’s annoying to have to track the identity of “our screen” and bind that identity to event handlers, or make it accessible with context etc. But it’s necessary in anything remotely security-adjacent. (And never assume anything is a singleton unless you add a breadcrumb comment for someone who might change that assumption on a different team!)
  • dshpala 4y ago
    And of course fix includes magic SecurityMode.Invalid value, which makes dismiss() behave like it did before. I'd look very hard at places that use SecurityMode.Invalid.
  • krajzeg 4y ago
    Agreed. The fixed logic, at least judging by the commit message, still feels very shaky on correctness grounds ("if we are dismissing something that doesn't seem to be right, ignore it"). Since they're rewriting code and changing method signatures anyway, I would prefer they got rid of the notion of "currently visible screen" and made sure that all dismiss() calls have a unique pointer or token pointing to what exactly is being dismissed. If this was my codebase, their approach would give me all sorts of bad vibes about additional problems lurking deeper. The whole process and the nature of the fix doesn't inspire a lot of confidence in the security of Pixel/Android in general.
    • izacus 4y ago
      So you'd go out and refactor a major security sensitive component (which dates to time before your career most likely) in a span of a single month for an emergency security patch deadline? That doesn't inspire a lot of confidence in your risk assesment and decision making. I'd do what Google did: rollout a patch that addresses the immediate danger and then backlog proper refactors over time.
• deleted 4y ago
  [deleted]
• vitiral 4y ago
  > When the SIM PUK was reset successfully, a .dismiss() function was called by the PUK resetting component on the “security screen stack”, causing the device to dismiss the current one and show the security screen that was “under” it in the stack Oh, the exceptional safety of object oriented programming!
  • lupire 4y ago
    There's nothing OOP-specific about this bug. The bug is in too-wide variable scoping, insufficient OO really.
    • vitiral 4y ago
      It calls .dismiss() expecting the PUK screen but it's a different object instead. This is the kind of thing that OOP rely on.
      • roflc0ptic 4y ago
        Sure, but it’s a race condition that could happen in a functional language, too. FP has an analogue to a class called ADTs, and you could have the same bug using those
      • tuyiown 4y ago
        Again not really, somewhere, something send a signals, and outcome of that signal depends on UI state. The problem is a lack of qualified signals and validated state changes, whatever the programming model used, if the logic is «remove topmost screen without any context check», you'll end up with this issue.
      • Someone1234 4y ago
        It has nothing to do with OOP. The design we're talking about is blind firing events at the in-focus window, and the in-focus window is being changed unexpectedly. The problem is loose coupling between the parent<->child. If the child window (PUK entry/pin reset window) knew the parent's ID and fired the dismiss event at that ID this wouldn't be possible. Even the fix they implemented is poor: The child is STILL blind-firing a dismiss event, but they just told the lock screen to ignore dismiss events from the PUK entry window. Instead, the fix should have been to stop blind-firing events at whatever happens to be in-focus. They've added more complexity rather than fixing the poor design.
• noasaservice 4y ago
  Good reason to not disclose to Google. Instead, you should sell the exploit on the exploit dealers sites. This is easily worth $300-500k But not now. And you have the 'privilege' of being dicked around with people googling you.
  • deleted 4y ago
    [deleted]
  • onychomys 4y ago
    Maybe having morals is worth $230k to the author.
    • noasaservice 4y ago
      You can say that, but he was going to get $0 if he already didn't have internal connections to google. If these companies try to cheap people out of what bounties they offer, then they need reminded that they're not the only game in town that'll pay for exploits.
      • joecool1029 4y ago
        This is the correct takeaway. It's damaging to their reputation to not admit the error and cheap out like this. I would hope they at least split the bounty between the two researchers, the one who initially raised it (but didn't complete their report?) and this one that had a fully documented chain.
• keewee7 4y ago
  What is up with the Pixel specific bugs lately? One would think Google did more QA on their own products than on stock Android but the opposite seems to be the case.
  • lupire 4y ago
    Why? Pixel is stock android and also customization, so it needs attention to both.
  • Gasp0de 4y ago
    As it says in the blog post (and is confirmed somewhere in the comments here) this is not pixel specific.
• jnk345u8dfg9hjk 4y ago
  My next party trick
  • deleted 4y ago
    [deleted]
• martinclayton 4y ago
  My daughter wears earrings, so she never needs a SIM ejection tool. But I keep one on my keyring - amazing how handy it is. (I don't carry a PIN-locked SIM card!)
  • jonpalmisc 4y ago
    I also keep one on my keyring and I get poked in the finger/thigh by it all the time; it’s super annoying! Still keep it though since I regularly have to pop my SIM in and out..
  • jaywalk 4y ago
    Why do you need to pop out your SIM so often? Is that an Android thing, or are you actually swapping your SIM all the time?
    • martinclayton 4y ago
      No, big family, frequent SIMs moving between phones. But it comes in handy for other things that need a similar pointy end too.
• deleted 4y ago
  [deleted]
• kgbcia 4y ago
  any other android version vulnerable?
• openplatypus 4y ago
  I dislike Google like the next guy. And this is problem of monumental proportions. But if you came here to piss on Android and praise Apple's security, let me remind you of this: https://www.howtogeek.com/334611/huge-macos-bug-allows-root-login-without-a-password.-heres-the-fix/ https://www.howtogeek.com/334611/huge-macos-bug-allows-root-...
  • jagged-chisel 4y ago
    Surely you can find something more recent than five years.
    • hu3 4y ago
      I don't see how the timing is relevant here.
      • jagged-chisel 4y ago
        Let’s take it to the extreme. Suppose this becomes the last bug Google exhibits in the next fifty years. Forty nine years in the future Apple makes a major security faux pas. Do we need to remind everyone that Google made a bug fifty years ago, too?
        • hu3 4y ago
          Or we can be realistic and agree that neither Apple nor Google are immune to future bugs.
    • izacus 4y ago
      Like Apple not patching macOS security holes on older versions: https://arstechnica.com/gadgets/2021/11/psa-apple-isnt-actually-patching-all-the-security-holes-in-older-versions-of-macos/ https://arstechnica.com/gadgets/2021/11/psa-apple-isnt-actua... ? (This happened again with Ventura).
      • jagged-chisel 4y ago
• tyingq 4y ago
  I wonder how many LEO agencies are now digging androids out of the evidence closet.
  • _kbh_ 4y ago
    LEO already have access to locked phones via stuff like GrayKey. https://www.grayshift.com/graykey/ https://www.grayshift.com/graykey/
    • tyingq 4y ago
      I think it has problems in some cases, pin codes longer than 6 digits.
    • 2OEH8eoCRo0 4y ago
      Android disabling USB data by default has been a thorn.
    • staringback 4y ago
      I am always skeptical of these "lawtech" companies that sell magic unlocking devices. Are we really to believe that there are unpatched security holes in all major devices (both Android and iOS) that allow this kind of backdoor access? I find it rather convenient that the "detailed support matrix" is only available for current customers only, seems to me like the actual amount of supported devices/operating systems would be limited to things such as outdated Samsung Galaxy phones and similar.
      • vvilliamperez 4y ago
        It works. It's basically a software brute force that works great for 4 digit pins, takes longer for longer passcodes. Other offerings are a keylogger for the pin/passwords after they "return" the device to the suspect.
        • Gasp0de 4y ago
          How would you install a keylogger on an encrypted device without rooting it or deleting user data?
• johndfsgdgdfg 4y ago
  I wonder if this bugs exists on FireOS. It's obvious that bugs like this will happen in a spyware company product like Google.
• stewx 4y ago
  Re: the title of this post, $70k is the bounty paid to the researcher, and "accidental" refers to the fact he came across the bug during personal use of his Pixel phone, not during testing.
  • deleted 4y ago
    [deleted]
• photochemsyn 4y ago
  It's somewhat interesting that there was never a major public pressure campaign by the FBI to force Android phones to be backdoored, as there was with Apple. Maybe this was the tactic used by law enforcement (and others most likely) to unlock Android phones? Maybe Google knew about it and that accounts for their stalling on providing a fix? Yes, that's how you start thinking after reading Yasha Levine's Surveillance Valley. https://yashalevine.com/surveillance-valley https://yashalevine.com/surveillance-valley
  • Semaphor 4y ago
    That actually sounds plausible. It’s a pretty simple explanation that would explain all the issues in the post.
  • deleted 4y ago
    [deleted]
  • sofixa 4y ago
    For what it's worth, all the famous either unlocking or remote hacking sagas (like Pegasus) have mostly been around iPhones. Which either indicates that Androids are so trivially hacked that nobody is even talking about it (sounds a bit doubtful, IMO, hopefully), or that the majority of "targets" have been using iPhones. It has certainly been the case with all the hacked journalists I remember. Also the Android landscape is much more fragmented, so maybe a vanilla Android exploit might not work on MIUI, so hackers don't bother when it's "easier" to develop for iOS, which has the majority of juicy targets anyways?
  • duxup 4y ago
    I suspect pressure to backdoor something or similar requests in the US are often (not always) one off adventures that collectively look like something larger, rather than say a policy where someone goes to companies and make general requests continuously like some regulator going about his business. The effect may end up being widespread, but the actual access and details are more uneven / look strange to us because of how spotty it is at times. At least in the us I suspect that law enforcement, the typical surveillance organizations may even try to cast a wide net at times, but I think they're more transactional in their intent / look for what they need for a given person, people, case and less so to keep an eye on where a random citizen comes and goes. That's not a justification for any of it, but I think it might explain why folks don't always find the 1984 they're looking for / expect in the end result.
• gausswho 4y ago
  Can we expect a fix for Pixels outside of the official service window? So 4 or older?
  • Gasp0de 4y ago
    No. "No security updates after X" means no security updates after X. Of course you can install an up-to-date OS, e.g. LineageOS works on the Pixel 4.
    • 2OEH8eoCRo0 4y ago
      "Guaranteed security updates until at least: X" is their actual phrasing. https://support.google.com/nexus/answer/4457705?hl=en#zippy=%2Cpixel-xl-a-a-g-a-g https://support.google.com/nexus/answer/4457705?hl=en#zippy=...
• nashashmi 4y ago
  I came across this so called bug. I thought it was a feature. I never realized how it could be used maliciously. Security is still such a weird concept. Some times it feels like a paralyzing debilitating effort. Similar to how parents yell at you for things you should not be doing, even though it is exciting and useful .
• khaki54 4y ago
  Hahaha I can just imagine finally getting in front of the Google security team in the office, then realize that you don't have a sim ejector. You try a few things like a mechanical pencil, dental pick, jumbo paperclip, etc. that don't quite work. Then asking around, no one has one but someone fortunately has a sewing kit. Meanwhile, the Google engineers, who were skeptical to begin with, show some signs of impatience, which you become acutely aware of, and get even more nervous. While you're shaking and pressing too hard, you ultimately stab through your hand and now there is blood everywhere. You try to hide it at first and play it off but blood is getting all over everything and a few drops hit the floor. You try with the needle some more but the blood is too slippery and you accidentally wipe some across your forehead to top it off. It's been 25 minutes at this point and 2 of them decide it's not worth their time any more and leave, which you also notice, and begin to realize your chance is slipping away and you're spiraling internally. Eventually, someone produces a bandaid, but your hands are shaking too much and they have to pitifully put it on for you. While contemplating if you are actually a grownup or just a large child, you realize you started sweating a lot and you forgot to put on deodorant because you're traveling and left it at home. You smell your own awful fear creeping up through the neck of your hoodie, hoping that the guy who is fixing you up doesn't notice. Crazy intrusive thoughts start to cross your mind as you pick up the needle again, but a woman snaps you out of it with "would this work?" holding up an earring. You kick yourself for not thinking of it earlier when you actually noticed her earrings during earlier chit chat. "I'll try not to get blood on it," you chuckle, but no one really laughs beyond a murmur. In seconds, you pop the sim out and swap it, quickly demo the vulnerability speaking faster than Eminem spitting Rap God. Everyone is quiet for an eternity (1.5) seconds as pressure builds, until the engineer who handed you the earring says "holy shit" and runs off without her earring. Those in the small crowd turn to each other to discuss, taking the pressure off you as you go totally cold from the sweat that you now realize has trickled all the way down your leg. The rest of the day you are high as ever, like the feeling of headiness after eating an extremely spicy order of hot wings or curry.
  • davidmurdoch 4y ago
    Please publish a blog full of these based-on-a-true-story behind-the scenes tech-drama fiction stories!
• tedivm 4y ago
  I think what really gets me about this is how differently Google treats its own security issues than the ones it finds in Project Zero. They have absolutely no problem enforcing deadlines around disclosures for the vendors they find vulnerabilities for, but when it comes to their own systems they seem to have no sense of urgency while also expecting security researchers to sit on their bugs for a much longer period of time than Project Zero does. For context Project Zero used to have a strict 90 day disclosure policy, but updated it to "90+30" a year or so ago to give people more time to patch. Google took at least five months to resolve this issue, and it's possible they took longer than that because we don't know when the first report was actually made.
  • deleted 4y ago
    [deleted]
• whatsakandr 4y ago
  It almost sounds like Google had an incentive to leave the bug in.
• WaitWaitWha 4y ago
  > I decided to stick with my October deadline. [...] > I also decided (even before the bounty) that I am too scared to actually put out the live bug and since the fix was less than a month away, it was not really worth it anyway. I decided to wait for the fix. I have gone through similar trepidation. What were you scared of?
  • michaelbuckbee 4y ago
    Security researchers (like the one here) don't want harm to come to people from their actions. If they announced the live bug before it was patched a lot of people and organizations might have been adversely by this before the fix was applied.
    • WaitWaitWha 4y ago
      Right. I should have asked "at what point did you decide that the wait outweighs the risk?" That is, at what point wait becomes too long, and is worse?
• wtk 4y ago
  When chosing a phone there should be a security metric reflecting how much time and money has been spent on security, researches and bug bounty programs. This error looks so trivial! As a long time Google Pixel user, I honestly don't feel the company did a good work protecting me.
  • deleted 4y ago
    [deleted]
• matchbok 4y ago
  It's quite amazing how poorly designed Android really is. Every single part of that OS is poorly architected and have horrible APIs. What a shame.
  • 2OEH8eoCRo0 4y ago
    Linux?
  • chimprich 4y ago
    Considering it's probably the world's most used OS, it's laughable. They churn out new recommendations constantly only to deprecate it again and think of some new tedious convoluted approaches a short time later. I think it's a combination of poor judgment and Google's toxic internal incentives to design crazy new stuff.
• dotBen 4y ago
  So, did someone else get the full $100k for reporting the vuln already or was that BS?
  • beeboop 4y ago
    It's entirely possible it came from a channel that wasn't eligible, or from a google employee, or own of their own security testers, etc.
  • IceWreck 4y ago
    Google could not reproduce it the first time so presumably they didnt pay up.
• openplatypus 4y ago
  Btw, I would love if Smasung comment if this also affects Knox.
• rex_lupi 4y ago
  THIS IS ABSOLUTELY CRAZY! I have personally tested this on my Non-pixel Android 12 device and it works. My findings: - The exploit works even on first pwd input screen on boot. however, the filesystem is still encrypted and cannot be accessed by any means (ADB/MTP). launcher does not load fully. but settings and other things accesible from notification panel can be launched (BT/Hotspot etc). you can get list of installed apps and many other sensitive informations that are not stored in /data/media/0/. - adb can be connected. shell can be launched but data partition is not accesible. - mtp initializes but does not load. I guess although one cannot access the user data, the ability to access/control other parts of system potentially exposes a huge attack surface.
  • deleted 4y ago
    [deleted]
  • Daniel_sk 4y ago
    What specific device do you have?
    • rex_lupi 4y ago
      The device I tested this on runs a moderately modified AOSP based os. I cannot specify the device model etc. I have also tested this on another LineageOS device and that is also affected. So I suppose any aosp-based rom that isn't heavily modified (like Samsung/MiUI) are affected.
  • jascination 4y ago
    Are you able to set a new pin or fingerprint from that state?
• mavu 4y ago
  And what do we learn from this? Pressure on disclosure date until Bug bounty, then relent.
• Edman274 4y ago
  I went to buy a phone maybe two months ago. Before I had my current Google Pixel 6, I used a OnePlus 3T for six years, and even then I only stopped because I sat in a hot tub with it on. At the T-Mobile store, I announced to the salesman that I would be back to buy a Pixel 6 when they had it in stock, and a man pulled me aside and privately asked me why I wanted to buy a Pixel. He explained to me that he was actually working in the hardware division at Google and that the team that he was managing was responsible for some parts of the Pixel's design. But he added that he had never actually talked with anyone out "in the wild" who owned a Pixel or made a positive attempt to buy one. He went on to explain that most of his team didn't use a Pixel either - they were all pretty much using iPhones, but some were even using Samsung devices. I understand that this was someone from the hardware team and it doesn't necessarily reflect on the people who work on the Android OS, but I feel silly for not having taken what he said into consideration when I finally bought a phone. If the people working on a device don't even want to use it themselves and can't figure out a compelling reason for anyone else to use it, shouldn't that have been a strong signal to me that I shouldn't have selected it? But I did, and I've been regretting it since. Great camera though.
  • Anderkent 4y ago
    roll to disbelieve. i think someone was pulling your leg especially the bit with samsung devices, i've had the misfortune of setting up a samsung phone for a family member and the amount of crap on those is just unbelievable
  • rippercushions 4y ago
    Out of curiosity, why have you been regretting it? I've been using Pixels for quite a while now and generally been quite happy.
    • julianlam 4y ago
      There are plenty of reasons that people how to spell it over the years, but none are actual red flags. For example, I think people give Google grief over making it difficult to unlock the bootloader, but the same can be said of every other vendor. In my experience, using the Pixel is good enough that I don't miss my Nokia 6.1 running LineageOS too much.
• deleted 4y ago
  [deleted]
• h43z 4y ago
  So basically google wanted to give this guy nothing. Then he set a hard deadline for disclosure and google managed to buy him for 70k so they could stick with their own deadline.
  • advisedwang 4y ago
    Or more charitably, by the terms of the program he wasn't eligable for anything, but they gave him seventy thousand dollars out of goodwill and the spirit of the program.
    • beeboop 4y ago
      Then they would have done this before the sorta-threat of his own disclosure date.
  • tempestn 4y ago
    I agree that it appears to have been the disclosure threat that resulted in the bounty, but I don't agree (if I'm reading you correctly) that the OP acted unethically. It sounds credible to me that he was just doing everything he could to get the bug fixed.
  • Sophira 4y ago
    According to the article, the reporter had already decided before the bounty had been set that they would wait for the fix: > I also decided (even before the bounty) that I am too scared to actually put out the live bug and since the fix was less than a month away, it was not really worth it anyway.
    • yreg 4y ago
      According to the bug thread transcript Google have not yet known he's not going to disclose in October when they offered the 70k. https://feed.bugs.xdavidhu.me/bugs/0016 https://feed.bugs.xdavidhu.me/bugs/0016
  • hadlock 4y ago
    It would not surprise me if in some cases, google runs the exploit up the tree to the NSA to see if they're actively using this for matters of national security, then slow-walk the patch to release. Given how easy the exploit is (no software needed, no special equipment beyond a paper-clip), would not surprise me if this has been in wide use for several years now by various groups.
• pookeh 4y ago
  How do you declare 70k bounty on your taxes?
  • saalweachter 4y ago
    "Miscellaneous income".
• idk1 4y ago
  I don't know anything about Android or iOS coding but... I'm actually very suprised it's coded the way it is, a stack of screens that are dismissed over the top of each other. I would expect one very specific boolean/flag bottleneck that says if the device is locked or unlocked. Then a list of actions that can be taken when locked (such as sim pins, emergency calls etc) and then unlocked (such as everything else). And that flag can only be flipped by unlocking the phone. This set of screens on top of the phone that can be dismissed is very surprising to me. Does anyone know how the iOS lock screen works? Is it the same way?
• maerF0x0 4y ago
  > During the life of this bug, since the official bug ticket was not too responsive, I sometimes got some semi-official information from Googlers. I actually prefer to only get updates on the official channel, which is the bug ticket and which I can disclose, but since I was talking with some employees, I picked up on bits and pieces. This is going to be one if the uncounted casualties of a downturn in tech and layoffs. When the organization is in turmoil, and the tenured folks have left out the backdoor, security flaws are going to remain open for a lot longer
  • scarmig 4y ago
    Turmoil isn't a good description of Google right now, though. It's far from healthy, but it has avoided mass layoffs so far, and the bug was filed in June.
    • maerF0x0 4y ago
      > of Google right now, though. I agree, my commentary is more on tech as a whole, which is in turmoil rn.
• silon42 4y ago
  jwz approves
• varispeed 4y ago
  I wonder if reluctance to fix this was because this "backdoor" was being used by security services. They now have to figure out the new one...
  • djmips 4y ago
    Maybe the new one was encoded in the fix.
• jacooper 4y ago
  Wait, this bug affects unsupported pixels now right? A Pixel 4 won't have this fixed ?
  • ruined 4y ago
    if your patch level is less than 2022-11-05 you are affected :D
    • jacooper 4y ago
      Luckily if you use a custom ROM, that is going to get updated after the official EOL, this should get fixed.
  • stardenburden 4y ago
    On my pixel 4a there's a "critical security" update available for download. (Current patch level is one month old) I will try to exploit before and after downloading.
    • jacooper 4y ago
      The 4A is still supported.
• owenpalmer 4y ago
  Very well written, thank you.
• tmd83 4y ago
  Very weird implementation with UI stacks and dismiss. The way we designed a multi step flow for a web app was basically having a sort of state machine/flow which says what are possible transitions say password > mfa1 > mfa2 > done and as each steps complete what's the next security steps for this particular user's configuration and simply allow just that transition. Once we are at the done state the authentication is marked as successful. Not storing auth state in UI (regardless of any MVC concern) and allowing only a very narrow allowed state of transition seems like a trivial design choice. I assume google has no shortage of people for security focused design. The UI stack being created together and dismissed rather than created/called on demand as state transition happens also seem a very wired design. Perhaps I don't understand the reason cause I'm not an android programmer.
• kelnos 4y ago
  This is pretty terrible. * The security screen "system" works as a stack, and the individual handlers for them don't actually have a reference to their own security screen. That seems like a terrible design; this design caused this bug, and the fix for it feels like a band-aid that could have unintended consequences (and thus new security implications) in the future. The handler for the security screen should have a reference to the security screen itself (or an opaque token or something like that), so it can be sure it is only dismissing its own screen. Passing a "security screen type", as the new, "fixed" code does, is not specific enough for this kind of code, and still seems unsafe to me. * I'm a bit confused as to how this could unlock a newly-rebooted phone. Isn't the user data partition unmounted and encrypted? How could this partition get decrypted if the user doesn't get the opportunity to enter their device PIN, which should be needed to gain access to the partition's encryption key? I guess maybe it isn't decrypted, and that's why the system got stuck on the "Pixel is Starting" screen. Still, pretty concerning. Meanwhile, my Pixel 4 still only has the October 2022 security update, claims there is no update waiting, and is presumably still vulnerable.
  • stardenburden 4y ago
    It doesn't get decrypted. The data is still safe after a reboot. That's presumably why the phone hangs for the author after a reboot. Although some comments have said Android itself loads (and I guess also the launcher) but they can't really do anything
• 1wsk 4y ago
  Just tried it myself, works on Android 12, doesn't work on Android 11. Both LineageOS, so the bug was introduced somwhere in AOSP 12.
• gunapologist99 4y ago
  > "Hopefully they treated the original reporter(s) fairly as well." Perhaps they should have reconsidered a bounty payment of some sort for the first bug reporter as well. Perhaps that's where the other $30k of the $100k went. This actually says something interesting about bug bounty programs in general: Given a high level of false positives, it's probably not uncommon AT ALL that sometimes it takes a couple of bug reports before something is reproducible or generates a high enough alert/credibility status, as seemed to have happened here. What's the correct protocol to be fair to all of the original bug reporters in those situations? Split the bounty? Reward all of them with the full amount?
  • capableweb 4y ago
    > Given a high level of false positives, it's probably not uncommon AT ALL that sometimes it takes a couple of bug reports before something is reproducible or generates a high enough alert/credibility status, as seemed to have happened here. This case was not the case of eventually the same reports being taken seriously. None of them were, until the author met people working at Google in person at some event, and him showing them the issue and then persisting. Different than "Ops, we received a couple of requests, better look into it" and more like "this guy won't stop bothering us about it, probably should look into it". Security reports from proper pentesters tend to include easy to reproduce steps and if you can't reproduce it yourself from that, you can ask them to expand, since it's in their interest for you to be able to understand them, since that's how they get paid.
    • gunapologist99 4y ago
      > Security reports from proper pentesters tend to include easy to reproduce steps and if you can't reproduce it yourself from that, you can ask them to expand, since it's in their interest for you to be able to understand them, since that's how they get paid. Fair point, but it's also in their interest to overestimate the impact of the bug they found. And, even if the reports are well written, many reports that I've seen (mostly from new gray hats) were not actually exploitable, even with aggressive poc code.
    • jokethrowaway 4y ago
• jokowueu 4y ago
  >Two weeks after our call, I got a new message that confirmed the original info I had. They said that even though my report was a duplicate, it was only because of my report that they started working on the fix. Google engineers don't seem to care much or am I being too harsh here ?
  • vanderZwan 4y ago
    If you are that makes two of us, my partner just asked me why I shouted "what the hell?!" when I read that.
• sn_master 4y ago
  This is very worrying. I have two old Pixels (2 and 4) with plenty of personal data, and none have been updated for years now. I am sure other people too keep their old phones around and won't be getting updated either.
  • hadlock 4y ago
    This only applies to phones who remain continuously powered on and still retain the decryption key in memory. It's possible you turn on your old, unused phone, unlock it (putting the key in memory), and plug it in for years but the number of phones in this state are probably vanishingly small.
• jbverschoor 4y ago
  This kind of response makes it real tempting to just sell it on the market instead...
• Sugimot0 4y ago
  Add to that the fact that the pixel 6 left audiophiles SOL for almost a year with no 3.5mm jack and broken USB-C DAC compatibility. Ontop of that Display Port Alt Mode is still disabled on every pixel for no good reason, despite many pixel owners reaching out to them, leaving us SOL for an alternative to samsung dex, or compaitibility with devices like the Nreal Air AR glasses. Google's hardware support IME is a shit show. They need to stop spending all their time playing with ML tricks that nobody uses outside of ads and keynotes (aside from normal camera stuff), and start listening to customers and addressing bugs and missing features that even the mid-tier chinese phones have rolled out. I'm buying a oneplus next time around and never looking back, idc if google's new chip gives me 2x battery life at the same price, it's not worth the frustration.
  • quantumsequoia 4y ago
    If you want a stable bug-free phone, oneplus is not the phone for you. Ever since they merged oxygenos and color os, oneplus phones are laden with bugs. I was planning to switch from oneplus to pixel for this reason.
  • Miraste 4y ago
    I wouldn't worry about missing out on battery life. Every Google phone has had pretty sad runtime since the very first Nexus. It would seem they don't care.
  • hojjat12000 4y ago
    Oneplus used to be good. But the experience and the OS is not the same. If you want Dex. Why not Samsung? I have a Pixel 6 (which I regret trading my Onplus6t for) and my next phone probably will be a samsung. The new ones are pretty stable and not as bloated as they used to be.
    • hnburnsy 4y ago
      Was a loyal OnePlus customer, but jumped to a used Samsung Note 10+. The Note has an amazing screen and much better camera. Be sure to use the Android Universal Debloater[1] and your favorite launcher, and it will feel like stock Android, just like OnePlus used to deliver. [1] https://github.com/0x192/universal-android-debloater https://github.com/0x192/universal-android-debloater
• akdor1154 4y ago
  Incredibly good writeup, author seems like a great bloke.
• djmips 4y ago
  Do you think there was an previous report for which this was a duplicate or were they just trying to get away without paying?
  • bredren 4y ago
    This may be a stretch but I could see the original report coming from an intelligence service. The report might be accompanied by a request to hold off on patching it due to active use. This would explain the desire to wait on G's side, and why it would not explain the prior report.
    • bornfreddy 4y ago
      And also why they patched it only when faced with exposure.
• lars_francke 4y ago
  The last scheduled security update for the Pixel 4 was the October 2022 one. So this might stay unfixed on those phones. https://support.google.com/pixelphone/answer/4457705?hl=en#zippy=%2Cpixel-xl-a-a-g-a-g https://support.google.com/pixelphone/answer/4457705?hl=en#z...
  • alphabettsy 4y ago
    That’s pretty frustrating, I have a Pixel 4 that I quite like. This is one of the reasons I recommend the most recent lowest-priced iOS device you can afford to family and friends who don’t upgrade often. My grandfathers iPhone 6s is just now going EOL after 7 years. Apple is a little inconsistent with updates for prior iOS versions but it still received the iOS 15 security update. It wonder if iPhones end up being cheaper because of the extended support?
• dicknuckle 4y ago
  Reminds me of how my daughter can unlock my Asus phone. My code is 8 digits long, policy set by work, and a fingerprint reader in the screen. She definitely doesn't know my code but somehow can still get into my phone if I leave it on the couch.
• jwr 4y ago
  I have an obsession with classifying software bugs into general categories, looking for the "root cause", or more constructively, for a way to avoid entire classes of bugs altogether. I've been doing that for more than 20 years now. This bug, if you look into the fix, falls into my "state transition" category. You can (and should) model large parts of your software as a state machine, with explicit transitions and invariant checks. If you do not, you still end up with states, just implemented haphazardly, and sooner or later someone will forget to perform a task or set a variable when transitioning from state to state. This category is my strong contender for #1 problem area in all devices that have a user interface.
  • gwillen 4y ago
    Do you have any writing I can read about your classification? This sounds extremely interesting and useful. (I have some related thoughts, but not 20 years' worth and largely not recorded.)
    • ak_111 4y ago
      I second this comment. It will be very interesting to see a rough sketch.
    • Lutzb 4y ago
      Reminds me of Orthogonal Defect Classification. Analyze defects for when they were introduced (during development, architectural design and so on) and what caused the introduction of the defect into the system in the first place.
    • jwr 4y ago
      Hmm. Perhaps I should get my notes into shape and publish them… I'll think about it. I would need to force myself to post them to HN without looking at the discussion, though.
  • woojoo666 4y ago
    Another way to look at it is, since the bug is from a race condition, modeling your program after functional programming would minimize these bugs
• system2 4y ago
  iPhone fanboy here. Here is another reason why I use iPhone. I feel like I left this comment way too many times.
• metacritic12 4y ago
  Terrible response by Google to this. Basically it seems like their bureaucracy is structured so that no one has an incentive to actually address this. Everyone at the company acted like they would rather this issue not even exist, rather that address a critical flaw that makes locking essentially not work on the Pixel. This gives us a look under the cover of what's important at Google, and it seems like security is a clear subdivision of marketing in this case.
  • deleted 4y ago
    [deleted]
• AtNightWeCode 4y ago
  Nicely written. I have found my Samsung phone unlocked for no reason so many times I can't remember anymore. I am sure there is some way to use the emergency call or the ICE feature to bypass the lock screen. There seems like these features randomly gets activated while the phone is in the pocket as well.
• SCdF 4y ago
  This is where I find out my otherwise completely functioning Pixel 3a no longer gets security updates, as of May. I knew and accepted that it wouldn't get new features and major android versions, but to not even get security updates, after only three years? So my options are: live with the piece of technology in my life that is both the most vunerable to physical security issues and has the widest access to my critical information no longer getting active security updates, attempt to root it and install my own build (is cyanogenmod still a thing?), or throw a working piece of complex technology in the trash? Amazing
  • jbverschoor 4y ago
    So you migrate to Apple
    • SCdF 4y ago
      That would be the "throw a working piece of complex technology in the trash" option, yes
  • rerx 4y ago
    There is LineageOS now, https://wiki.lineageos.org/devices/sargo/ https://wiki.lineageos.org/devices/sargo/ The most recent Pixels get a few extra years of only security updates after regular updates run out. So at least they have improved the policy somewhat now. It would be great if Google went ahead and fixed this problem in particular for more devices, though.
  • codethief 4y ago
    Or install GrapheneOS? Pixel 3a support is being phased out slowly but surely but currently it's still getting all security patches. EDIT: I stand corrected, they stopped support in September. :(
    • derkades 4y ago
      GrapheneOS has just patched this vulnerability for the Pixel 3a!
• woojoo666 4y ago
  The code quality is a bit concerning but then again, we have no idea what iOS looks like so it's hard to judge fairly
• jokethrowaway 4y ago
  That architecture is scarily coupled with UI and it doesn't inspire a lot of confidence in Android. Ship it mentality much?
• zmmmmm 4y ago
  Wow, this is very serious - it pretty much turns every "left my phone on the bus" incident from "oh well" into "all your data was compromised". I don't know how Google couldn't take this seriously. Even after the poster physically demonstrated it they took months to fix it. For sensitive data with legal disclosure requirements this is a game changer. Very disappointed with Google here - even though I lost a lot of trust in them in other areas, I still rated their security stance as excellent, especially on their own phones.
• pmontra 4y ago
  > We didn’t have a SIM ejection tool. I didn't have one yesterday night. Things that work: the classic paper clip, a small staple for paper sheets, the inner metallic wire of twist ties (or whatever they are named.) I discovered the latter yesterday.
• hnburnsy 4y ago
  #0016 VENDOR: GOOGLE STATUS: FIXED (NOVEMBER 2022 UPDATE) REPORTED: JUN 13, 2022 DISCLOSED: NOV 10, 2022 (150 DAYS) Project Zero only gives vendors 7 or 90 days before disclosure... The short version: Project Zero won't share technical details of a vulnerability for 30 days if a vendor patches it before the 90-day or 7-day deadline. The 30-day period is intended for user patch adoption. https://googleprojectzero.blogspot.com/2021/04/policy-and-disclosure-2021-edition.html https://googleprojectzero.blogspot.com/2021/04/policy-and-di... Google should have given Mr. Schütz $200,000 alone for not revealing it.
  • mqus 4y ago
    This is also the point that stands out to me the most. This is hypocritical and pretty close to negligent, if they set such high standards for other companies they investigate but can't own up to it themselves. I can only hope this is a singular case or else the argument "yeah we collect your data but we also keep it safe!" falls pretty quickly.
  • tamirzb 4y ago
    If you follow published reports of Android vulnerabilities you'll see that taking longer than 90 days for a fix is actually not that rare. I myself had a similar experience a couple of times.
  • zaphirplane 4y ago
    I am surprised there is an assumption that android fixes will get to users within 30 days
• KingMachiavelli 4y ago
  I think I triggered this a few times; I use a alarm clock that's dismissed via math equation which I frequently get mixed up with the lock screen when waking up. I have GrapheneOS set to auto-reboot every 8 hours so then there's also the SIM unlock screen. In the state of just waking up it's easy to PUK lock the SIM. I guess I just assumed the "Pixel is starting" message was some unrelated bug and just manually restarted. I think you can still continue to a normal boot if you manually lock or wait for the lock screen PIN timeout to expire.
• andirk 4y ago
  Kind of related: My new Samsung S8 c. 2017 has unlocked a few times without my finger or password. The first couple times I figured user error. By the 5th time, I'm pretty sure it's a software/hardware issue. Now my version of Android doesn't even get security updates any more. Maybe time for a new phone.
• matheomw 4y ago
  Hei