10 ms·

A mysterious bug in the firmware of Google's Titan M chip

238 points by alexbakker 7y ago

RedComet 7y ago
Another case of Google not following their own rules. But they're happy to hang others out to dry when they exceed 90 days.
- bArray 7y ago
  Yep I fully agree, you can't hold others to a standard you're not willing to hold yourself to. I specifically remember Microsoft begging for more time on a bug. Also if I understood it correctly, it seems as though some devices may require a factory reset to apply the new firmware? If so, for a lot of devices this still isn't fixed.
  - alexbakker 7y ago
    The big question is indeed how many devices got themselves into this 'bad state'. Your guess is as good as mine.
- pvg 7y ago
  In what way did they violate their own rules? Google didn't prevent the researcher from disclosing and the researcher could have disclosed - the timeline describes requests, not demands. For reference, Project Zero's disclosure FAQ: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html https://googleprojectzero.blogspot.com/p/vulnerability-discl... There are several cases in which deadlines were extended way beyond 90 days. And in the post itself, the researcher points out they could (and, in hindsight, feel they should) have imposed a hard 90 day deadline.
- izacus 7y ago
  Can you explain where you see that? In the post itself it says that Google offered coordinated disclosure at 90day mark?
- sneak 7y ago
  Disclosure doesn’t hang anyone out to dry. Any advance notice to a vendor before publication is a courtesy. You are not obligated to keep any secrets about your own research into a product that has been publicly released for everyone to do research on.
tpmx 7y ago
If I were an Android user: I'd feel good with how Google managed this one. Regarding NSA vs Google (seems like after I commented on a corona virus thread a few times, I was rate limited - editing existing comments still works though): @baybal2: "NSA infiltrates links to Yahoo, Google data centers worldwide" https://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html https://www.washingtonpost.com/world/national-security/nsa-i... "Googlers say “F* you” to NSA, company encrypts internal network" https://arstechnica.com/information-technology/2013/11/googlers-say-f-you-to-nsa-company-encrypts-internal-network/ https://arstechnica.com/information-technology/2013/11/googl... @monocasa: Got a credible source?
- monocasa 7y ago
  Google is part of PRISM and was (and probs still is) collaborating directly with the government.
  - imglorp 7y ago
    Except for the 2013 "Oh shit" slide from the Snowden dump. At least part of Google wasn't on board.
    - monocasa 7y ago
      That was MUSCULAR, not PRISM. It was to exceed the access that even PRISM gave them.
      - lern_too_spel 7y ago
        PRISM doesn't give the government additional access to anything. It simply ingests data that the FBI has already collected by wiretapping individuals under investigation. Edit (responding too fast): > It by default gives government access without anyone at Google or anywhere else granting that access at time of use. Where did you get that idea? All the documents show that it ingests data the FBI already has, for individuals the companies already manually approved after potentially fighting about it with a judge. You simply made up an illegal system out of whole cloth that wouldn't last a minute in court if anybody challenged it, unlike the phone metadata program, which went through two courts to conclude its illegality. Edit 2: > Page five lists the companies and page six lists the per company agreement date. Unless you're trying to argue that Google didn't respond to wiretapping requests from the FBI at all before 2009. The FBI has to set up a system for canonicalizing and routing data from each different company. Those dates list when the FBI did that for each company. Since almost nobody (including suspected terrorists, apparently) uses Apple's email service, their system was the lowest priority to support. This is well documented, both in Snowden's documents and in documents the government later declassified. Once again, if PRISM were as you described it, it would be flagrantly illegal and shut down long before the phone metadata program. Edit 3: iMessage was launched near the end of 2011, and FBI's DITU handles content collection via wiretaps. When are you going to address the fact that the program from your fever dreams is insanely illegal and that it doesn't match any of the documents? If you would like me to respond normally, upvote my comments, so I don't get rate-limited.
baybal2 7y ago
I remind you, Google was one of the companies caught collaborating with NSA as per NSA leak by Edward Snowden
- thefounder 7y ago
  Was/is there any US corp not cooperating?
  - stopads 7y ago
    Yes, Qwest (the telecom, formerly US West) resisted and fought tooth and nail to not cooperate. Their CEO was prosecuted to hell and back for daring to do this, and the company was forced to sell to a competitor. Nobody even remembers his name anymore, few people even remember Qwest.
    - shadowgovt 7y ago
      Feels like there's a lesson in this story.
      - perl4ever 7y ago
        I don't know what the lesson is after reading his wikipedia page. His refusal to cooperate with the NSA seems like a non-sequitur as a response to the whole insider trading and fraud thing. I mean, if the prosecution was revenge, well, ok, but I can't connect the dots to how that makes him not guilty.
    - ISL 7y ago
      His name is Joseph Nacchio. If this story is true (and it has been around for many years), he is a hero for standing up for transparent governance, and the privacy of Qwest's customers.
      - Inu 7y ago
        https://en.wikipedia.org/wiki/Joseph_Nacchio https://en.wikipedia.org/wiki/Joseph_Nacchio
monocasa 7y ago
Wow, I normally am all about how google handles security issues (they get dragged through the mud for some Project Zero stuff), but this def did not get handled well. Super unclear communication, starting with "you're just using it wrong", more than six month turn around, and even then at the end no clear explanation of what went wrong with someone who was collaborating with you? That's amateur hour security.
- ignoramous 7y ago
  I'd pay to see Bryan Cantrill's reaction [0][1] to this: A seemingly mysterious firmware bug of a secure element / trusted-execution-environment but there's no knowing if there are more bugs (or, shudder backdoors). Since the source code isn't available for scrutiny (though Google has promised firmware transparency [2]), it is kind of difficult to tell what really went wrong in the current reported case and what else possibly could go wrong given the use-cases for it are far-reaching and sensitive: Google has advocated StrongBox as a trustable companion that could be used to attest user actions on medical devices [3], for instance; or for use as an Identity verificafion for documents such as Driving Licenses and Passports. [0] https://www.youtube-nocookie.com/embed/30jNsCVLpAE https://www.youtube-nocookie.com/embed/30jNsCVLpAE [1] https://www.youtube-nocookie.com/embed/fE2KDzZaxvE https://www.youtube-nocookie.com/embed/fE2KDzZaxvE [2] https://www.youtube.com/watch?v=0uG_RKiDmQY?t=33m https://www.youtube.com/watch?v=0uG_RKiDmQY?t=33m [3] https://android-developers.googleblog.com/2018/10/android-protected-confirmation.html https://android-developers.googleblog.com/2018/10/android-pr...
  - sneak 7y ago
    More troubling to me than the closed source firmware is that the bug in TFA seems like something that the most basic of a test suite should be catching. It’s reminiscent of Apple’s “goto fail” lack of certificate checking - another easily testable case that simply wasn’t. The test authors don’t even need to be on the same team/manager. They can just write black box tests to the spec, like the author of this post did. I’m not even some big TDD guy. It just seems to me that in these core security-critical libraries/functions that should be pretty side-effect-free that you should have some basic “receive x, produce y” functional tests to make sure the API is doing what it claims to do on the tin.
_Microft 7y ago
Could it be that the first excerpt (https://github.com/beemdevelopment/Aegis/blob/def7c676148f261c1adf28bf1fc3d9fc03a25985/app/src/main/java/com/beemdevelopment/aegis/crypto/KeyStoreHandle.java#L47-L67 https://github.com/beemdevelopment/Aegis/blob/def7c676148f26... ) should not have included the line with .setIsStrongBoxBacked(true) yet? Edit: funny: 0dd0adde looks a lot like deadd00d (like "dead dude") with a reversed byte order. If this is a coincidence? Edit2: https://www.bing.com/search?q=deadd00d https://www.bing.com/search?q=deadd00d
- alexbakker 7y ago
  You're absolutely right about the excerpt. Fixed, thanks.
- v64 7y ago
  Very interesting observation! "Comments on a number of StackOverflow questions have pointed out that a fault address of deadd00d indicates a deliberate VM abort." That ending up in the ciphertext multiple times seems to point to some memory corruption issue. It's also a good argument for using magic numbers that stand out.
4cao 7y ago
The most important takeaway is to stick to the 90-day disclosure policy. The deadline is only credible when it's enforced, and on a number of occasions Google have stated they believe so themselves. [1] 1. https://www.google.com/search?q="deadline+exceeded"+"automatically+derestricting" https://www.google.com/search?q="deadline+exceeded"+"automat...
kemonocode 7y ago
The fact they still haven't gone around to open-sourcing the Titan M firmware is, honestly, what worries me the most about this. It's probably going through some heavy internal auditing now, which is not the best approach, all things considered.
m3kw9 7y ago
Maybe this mysterious “bug” is a backdoor
- jasonvorhe 7y ago
  Maybe you should refrain from spreading rumors? Hanlon's razor applies.
aasasd 7y ago
@alexbakker: could you please make code in the snippets wrap at least when viewed on a phone? I gain nothing from them being non-wrapping, while having to scroll back and forth to read. In each editor I've used, code soft-wraps at screen edge, so I don't even understand where this trend came from.
- aasasd 7y ago
  (Or rather, I guess it's inherited from ye olde ‘pre’ block, even though snippets are full of their own markup nowadays.)
- qu4z-2 7y ago
  As a counterpoint, I always disable wrapping in my editor, as I find it much less readable wrapped.
  - aasasd 7y ago
    Well, at least you're likely editing on the desktop. On a phone, reading code listings is PDF all over again.
alexbakker 7y ago
Author here. I should have made this clear in the blog post, but I'd be interested in seeing boot logs from Pixel 3 (or newer) devices. If the firmware update failed on more devices than just mine, it would be good to know about that. If you'd like to help, first make sure you're at least on the December 2019 security update. To capture the log plug your phone into a computer, run "adb reboot ; sleep 1 ; adb logcat | grep -i citadel" and turn the phone back on. Wait for it to boot, unlock the SIM card and unlock the screen. This should yield the version information of the firmware of Titan M.
- alexandrerond 7y ago
  Mine got updated it seems

238 points by alexbakker 7y ago

Another case of Google not following their own rules. But they're happy to hang others out to dry when they exceed 90 days.

bArray 7y ago
Yep I fully agree, you can't hold others to a standard you're not willing to hold yourself to. I specifically remember Microsoft begging for more time on a bug. Also if I understood it correctly, it seems as though some devices may require a factory reset to apply the new firmware? If so, for a lot of devices this still isn't fixed.
- alexbakker 7y ago
  The big question is indeed how many devices got themselves into this 'bad state'. Your guess is as good as mine.
pvg 7y ago
In what way did they violate their own rules? Google didn't prevent the researcher from disclosing and the researcher could have disclosed - the timeline describes requests, not demands. For reference, Project Zero's disclosure FAQ: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html https://googleprojectzero.blogspot.com/p/vulnerability-discl... There are several cases in which deadlines were extended way beyond 90 days. And in the post itself, the researcher points out they could (and, in hindsight, feel they should) have imposed a hard 90 day deadline.
izacus 7y ago
Can you explain where you see that? In the post itself it says that Google offered coordinated disclosure at 90day mark?
sneak 7y ago
Disclosure doesn’t hang anyone out to dry. Any advance notice to a vendor before publication is a courtesy. You are not obligated to keep any secrets about your own research into a product that has been publicly released for everyone to do research on.

tpmx 7y ago

If I were an Android user: I'd feel good with how Google managed this one. Regarding NSA vs Google (seems like after I commented on a corona virus thread a few times, I was rate limited - editing existing comments still works though): @baybal2: "NSA infiltrates links to Yahoo, Google data centers worldwide" https://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html https://www.washingtonpost.com/world/national-security/nsa-i... "Googlers say “F* you” to NSA, company encrypts internal network" https://arstechnica.com/information-technology/2013/11/googlers-say-f-you-to-nsa-company-encrypts-internal-network/ https://arstechnica.com/information-technology/2013/11/googl... @monocasa: Got a credible source?

monocasa 7y ago
Google is part of PRISM and was (and probs still is) collaborating directly with the government.
- imglorp 7y ago
  Except for the 2013 "Oh shit" slide from the Snowden dump. At least part of Google wasn't on board.
  - monocasa 7y ago
    That was MUSCULAR, not PRISM. It was to exceed the access that even PRISM gave them.
    - lern_too_spel 7y ago
      PRISM doesn't give the government additional access to anything. It simply ingests data that the FBI has already collected by wiretapping individuals under investigation. Edit (responding too fast): > It by default gives government access without anyone at Google or anywhere else granting that access at time of use. Where did you get that idea? All the documents show that it ingests data the FBI already has, for individuals the companies already manually approved after potentially fighting about it with a judge. You simply made up an illegal system out of whole cloth that wouldn't last a minute in court if anybody challenged it, unlike the phone metadata program, which went through two courts to conclude its illegality. Edit 2: > Page five lists the companies and page six lists the per company agreement date. Unless you're trying to argue that Google didn't respond to wiretapping requests from the FBI at all before 2009. The FBI has to set up a system for canonicalizing and routing data from each different company. Those dates list when the FBI did that for each company. Since almost nobody (including suspected terrorists, apparently) uses Apple's email service, their system was the lowest priority to support. This is well documented, both in Snowden's documents and in documents the government later declassified. Once again, if PRISM were as you described it, it would be flagrantly illegal and shut down long before the phone metadata program. Edit 3: iMessage was launched near the end of 2011, and FBI's DITU handles content collection via wiretaps. When are you going to address the fact that the program from your fever dreams is insanely illegal and that it doesn't match any of the documents? If you would like me to respond normally, upvote my comments, so I don't get rate-limited.

baybal2 7y ago

I remind you, Google was one of the companies caught collaborating with NSA as per NSA leak by Edward Snowden

thefounder 7y ago
Was/is there any US corp not cooperating?
- stopads 7y ago
  Yes, Qwest (the telecom, formerly US West) resisted and fought tooth and nail to not cooperate. Their CEO was prosecuted to hell and back for daring to do this, and the company was forced to sell to a competitor. Nobody even remembers his name anymore, few people even remember Qwest.
  - shadowgovt 7y ago
    Feels like there's a lesson in this story.
    - perl4ever 7y ago
      I don't know what the lesson is after reading his wikipedia page. His refusal to cooperate with the NSA seems like a non-sequitur as a response to the whole insider trading and fraud thing. I mean, if the prosecution was revenge, well, ok, but I can't connect the dots to how that makes him not guilty.
  - ISL 7y ago
    His name is Joseph Nacchio. If this story is true (and it has been around for many years), he is a hero for standing up for transparent governance, and the privacy of Qwest's customers.
    - Inu 7y ago
      https://en.wikipedia.org/wiki/Joseph_Nacchio https://en.wikipedia.org/wiki/Joseph_Nacchio

monocasa 7y ago

Wow, I normally am all about how google handles security issues (they get dragged through the mud for some Project Zero stuff), but this def did not get handled well. Super unclear communication, starting with "you're just using it wrong", more than six month turn around, and even then at the end no clear explanation of what went wrong with someone who was collaborating with you? That's amateur hour security.

ignoramous 7y ago
I'd pay to see Bryan Cantrill's reaction [0][1] to this: A seemingly mysterious firmware bug of a secure element / trusted-execution-environment but there's no knowing if there are more bugs (or, shudder backdoors). Since the source code isn't available for scrutiny (though Google has promised firmware transparency [2]), it is kind of difficult to tell what really went wrong in the current reported case and what else possibly could go wrong given the use-cases for it are far-reaching and sensitive: Google has advocated StrongBox as a trustable companion that could be used to attest user actions on medical devices [3], for instance; or for use as an Identity verificafion for documents such as Driving Licenses and Passports. [0] https://www.youtube-nocookie.com/embed/30jNsCVLpAE https://www.youtube-nocookie.com/embed/30jNsCVLpAE [1] https://www.youtube-nocookie.com/embed/fE2KDzZaxvE https://www.youtube-nocookie.com/embed/fE2KDzZaxvE [2] https://www.youtube.com/watch?v=0uG_RKiDmQY?t=33m https://www.youtube.com/watch?v=0uG_RKiDmQY?t=33m [3] https://android-developers.googleblog.com/2018/10/android-protected-confirmation.html https://android-developers.googleblog.com/2018/10/android-pr...
- sneak 7y ago
  More troubling to me than the closed source firmware is that the bug in TFA seems like something that the most basic of a test suite should be catching. It’s reminiscent of Apple’s “goto fail” lack of certificate checking - another easily testable case that simply wasn’t. The test authors don’t even need to be on the same team/manager. They can just write black box tests to the spec, like the author of this post did. I’m not even some big TDD guy. It just seems to me that in these core security-critical libraries/functions that should be pretty side-effect-free that you should have some basic “receive x, produce y” functional tests to make sure the API is doing what it claims to do on the tin.

_Microft 7y ago

Could it be that the first excerpt (https://github.com/beemdevelopment/Aegis/blob/def7c676148f261c1adf28bf1fc3d9fc03a25985/app/src/main/java/com/beemdevelopment/aegis/crypto/KeyStoreHandle.java#L47-L67 https://github.com/beemdevelopment/Aegis/blob/def7c676148f26... ) should not have included the line with .setIsStrongBoxBacked(true) yet? Edit: funny: 0dd0adde looks a lot like deadd00d (like "dead dude") with a reversed byte order. If this is a coincidence? Edit2: https://www.bing.com/search?q=deadd00d https://www.bing.com/search?q=deadd00d

alexbakker 7y ago
You're absolutely right about the excerpt. Fixed, thanks.
v64 7y ago
Very interesting observation! "Comments on a number of StackOverflow questions have pointed out that a fault address of deadd00d indicates a deliberate VM abort." That ending up in the ciphertext multiple times seems to point to some memory corruption issue. It's also a good argument for using magic numbers that stand out.

4cao 7y ago

The most important takeaway is to stick to the 90-day disclosure policy. The deadline is only credible when it's enforced, and on a number of occasions Google have stated they believe so themselves. [1] 1. https://www.google.com/search?q="deadline+exceeded"+"automatically+derestricting" https://www.google.com/search?q="deadline+exceeded"+"automat...

kemonocode 7y ago

The fact they still haven't gone around to open-sourcing the Titan M firmware is, honestly, what worries me the most about this. It's probably going through some heavy internal auditing now, which is not the best approach, all things considered.

m3kw9 7y ago

Maybe this mysterious “bug” is a backdoor

jasonvorhe 7y ago
Maybe you should refrain from spreading rumors? Hanlon's razor applies.

aasasd 7y ago

@alexbakker: could you please make code in the snippets wrap at least when viewed on a phone? I gain nothing from them being non-wrapping, while having to scroll back and forth to read. In each editor I've used, code soft-wraps at screen edge, so I don't even understand where this trend came from.

aasasd 7y ago
(Or rather, I guess it's inherited from ye olde ‘pre’ block, even though snippets are full of their own markup nowadays.)
qu4z-2 7y ago
As a counterpoint, I always disable wrapping in my editor, as I find it much less readable wrapped.
- aasasd 7y ago
  Well, at least you're likely editing on the desktop. On a phone, reading code listings is PDF all over again.

alexbakker 7y ago

Author here. I should have made this clear in the blog post, but I'd be interested in seeing boot logs from Pixel 3 (or newer) devices. If the firmware update failed on more devices than just mine, it would be good to know about that. If you'd like to help, first make sure you're at least on the December 2019 security update. To capture the log plug your phone into a computer, run "adb reboot ; sleep 1 ; adb logcat | grep -i citadel" and turn the phone back on. Wait for it to boot, unlock the SIM card and unlock the screen. This should yield the version information of the firmware of Titan M.

alexandrerond 7y ago
Mine got updated it seems