[HN Gopher] A mysterious bug in the firmware of Google's Titan M...
___________________________________________________________________
A mysterious bug in the firmware of Google's Titan M chip
Author : alexbakker
Score : 122 points
Date : 2020-02-29 13:15 UTC (9 hours ago)
(HTM) web link (alexbakker.me)
(TXT) w3m dump (alexbakker.me)
| 4cao wrote:
| 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"+"automat...
| _Microft wrote:
| Could it be that the first excerpt
| (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
| v64 wrote:
| 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.
| alexbakker wrote:
| You're absolutely right about the excerpt. Fixed, thanks.
| tpmx wrote:
| 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-i...
|
| "Googlers say "F __* you" to NSA, company encrypts internal
| network "
|
| https://arstechnica.com/information-technology/2013/11/googl...
|
| @monocasa: Got a credible source?
| monocasa wrote:
| Google is part of PRISM and was (and probs still is)
| collaborating directly with the government.
| lern_too_spel wrote:
| No, Google isn't part of PRISM. The FBI is part of PRISM.
| Google responds to court-ordered data requests, including
| from the FBI.
| monocasa wrote:
| The NSA's slides disagree with you.
|
| https://www.theguardian.com/world/interactive/2013/nov/01/p
| r...
| lern_too_spel wrote:
| The NSA's slides disagree with you. Here is the slide
| explaining how the data flows. https://imgur.com/setOJIm
|
| PRISM is simply a data integration system that gets data
| from the FBI's Data Intercept Technology Unit, which is
| the group that handles Internet communication wiretaps on
| specific individuals under investigation.
| monocasa wrote:
| > No, Google isn't part of PRISM.
|
| The slides literally list Google as a data provider as
| part of the PRISM program.
| lern_too_spel wrote:
| If you paint with that broad brush, the users whose data
| PRISM consumes are also part of the PRISM program. That's
| a fairly useless definition. What people are interested
| when talking about PRISM is whom the NSA integrates with.
| monocasa wrote:
| End users didn't build automated systems to comply with
| government requests and integrate with the PRISM program.
|
| End users also aren't listed in NSA documentation as
| collaborators.
| lern_too_spel wrote:
| Google also isn't listed in NSA documentation as
| collaborators.
|
| Google also didn't integrate with the PRISM program.
|
| Same.
|
| Edit (responding too fast):
|
| > Literally page five lists the companies
|
| Page 5 doesn't say they are "collaborators."
|
| > and page six lists the per company agreement dates
|
| Page 6 doesn't say there was an "agreement" with those
| companies. It simply lists the dates that the FBI made
| data they have from these companies available for
| ingestion.
|
| Stop pretending words exist in the documents that don't.
| That's conspiracy theory nonsense by the _exact_ same
| method as Pizzagate.
| monocasa wrote:
| Literally page five lists the companies, and page six
| lists the per company agreement dates.
|
| Stop gaslighting us.
| tpmx wrote:
| The title of page six is:
|
| "Dates When PRISM Collection Began for Each Provider".
|
| That is not the same as "company agreement", by any
| stretch of the imagination.
|
| (gaslighting? seriously? you're clearly the person who is
| trying really, really, hard to twist the facts here)
|
| I don't like Google more than anyone else. The truth
| though, that's important stuff worth spending time
| defending.
| monocasa wrote:
| They're automated systems in support of the 702 program.
| The companies in question had to have done work to
| assist, by the nature of how the program works.
| tpmx wrote:
| Okay. I see what you mean. Take care.
| tpmx wrote:
| Nothing in those slides substantiates your claim.
| monocasa wrote:
| The slides literally list Google as a data provider as
| part of the PRISM program.
| tpmx wrote:
| No, they list Google as one of the PRISM data sources. It
| doesn't say if Google was breached or if Google
| volunteered.
|
| Again:
|
| https://arstechnica.com/information-
| technology/2013/11/googl...
| monocasa wrote:
| The PRISM slides list per company agreement dates
| spanning over five years. Microsoft started first in
| 2007, Google was added in 2009, with Apple being one of
| the last in 2012. If it was a system that was simply
| ingesting FBI data, why would it wait until 2012, unless
| you're suggesting that Apple didn't respond to FBI
| requests at all until late 2012?
|
| Just because the NSA had a program to exceed even what
| had been negotiated via PRISM, doesn't mean that PRISM
| didn't involve collaboration.
| imglorp wrote:
| Except for the 2013 "Oh shit" slide from the Snowden dump. At
| least part of Google wasn't on board.
| monocasa wrote:
| That was MUSCULAR, not PRISM. It was to exceed the access
| that even PRISM gave them.
| lern_too_spel wrote:
| 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.
| monocasa wrote:
| It's automated systems for those requests. It by default
| gives government access without anyone at Google or
| anywhere else granting that access at time of use.
|
| It does record the request though which is why NSA tried
| to exceed the bounds of that with MUSCULAR.
|
| Edit to respond to your edit: 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.
|
| Edit 2 since apparently this is how we're doing this:
|
| > Since almost nobody (including suspected terrorists,
| apparently) uses Apple's email service, their system was
| the lowest priority to support.
|
| There's a fuck ton of metadata that iMessage reports back
| up; PRISM isn't just about email. And yes, iPhones are
| the most common smartphone in the world. I guarantee you
| that Apple isn't last because they were a low priority,
| that's absolutely absurd.
|
| Edit 3:
|
| Your argument that "it would be illegal and shutdown like
| the other illegal programs documented here if it were
| actually illegal" has to be one of the hottest takes I've
| heard.
|
| And the PRISM collection was part of what the Supreme
| Court dismissed not because it isn't illegal, but because
| you can't prove that affected the claimant personally
| without a breach to national security, so they can't
| prove they have standing, so the case had to be
| dismissed. https://www.aclu.org/files/assets/amnesty_v_cl
| apper_scotus_o...
| baybal2 wrote:
| I remind you, Google was one of the companies caught
| collaborating with NSA as per NSA leak by Edward Snowden
| shadowgovt wrote:
| The Snowden leak indicated Google's internal network has been
| physically compromised. That's the opposite of collaboration.
|
| Google is still a big target for the NSA and other espionage
| organizations.
| baybal2 wrote:
| They were both compromised, and being coaxed into
| collaboration.
|
| It was on the powerpoint in the leak with the list of
| "industry partners"
| kyrra wrote:
| Here's a fun story about it:
|
| https://arstechnica.com/information-
| technology/2013/11/googl...
|
| Google also started encrypting all cross data center traffic
| as a result of these findings.
| eternalny1 wrote:
| The NSA literally dug a hole in the ground via Level 3 to get
| into that network.
|
| That isn't collaboration.
| thefounder wrote:
| Was/is there any US corp not cooperating?
| stopads wrote:
| 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 wrote:
| Feels like there's a lesson in this story.
| ISL wrote:
| 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 wrote:
| https://en.wikipedia.org/wiki/Joseph_Nacchio
| tpmx wrote:
| https://en.wikipedia.org/wiki/Qwest#Refusal_of_NSA_surveill
| a...
|
| > Former Qwest CEO Joseph Nacchio, alleged in appeal
| documents that the NSA requested that Qwest participate in
| its wiretapping program more than six months before
| September 11, 2001. Nacchio recalls the meeting as
| occurring on February 27, 2001. Nacchio further claims that
| the NSA cancelled a lucrative contract with Qwest as a
| result of Qwest's refusal to participate in the wiretapping
| program. Nacchio surrendered April 14, 2009 to a federal
| prison camp in Schuylkill, Pennsylvania to begin serving a
| six-year sentence for an insider trading conviction. The
| United States Supreme Court denied bail pending appeal the
| same day.
| [deleted]
| RedComet wrote:
| Another case of Google not following their own rules. But they're
| happy to hang others out to dry when they exceed 90 days.
| sneak wrote:
| 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.
| pvg wrote:
| 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-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 wrote:
| Can you explain where you see that? In the post itself it says
| that Google offered coordinated disclosure at 90day mark?
| bArray wrote:
| 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 wrote:
| The big question is indeed how many devices got themselves
| into this 'bad state'. Your guess is as good as mine.
| monocasa wrote:
| 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 wrote:
| 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
|
| [1] https://www.youtube-nocookie.com/embed/fE2KDzZaxvE
|
| [2] https://www.youtube.com/watch?v=0uG_RKiDmQY?t=33m
|
| [3] https://android-developers.googleblog.com/2018/10/android-
| pr...
| sneak wrote:
| 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.
___________________________________________________________________
(page generated 2020-02-29 23:00 UTC)