Live-Capture Forensics of Corruptor-Injector Network injecting fake Chrome install via https@google

[SmirGel]

Source:http://www.google.com,O= Google Inc,L = Mountain View,ST = California,C = US

Valid From 6 May 2015, 10:29 a.m.

Valid To 4 Aug 2015, midnight

Serial Number 5F:BB:FC:7C:4C:6E:FF:92 (6898384865036533650)

CA Cert No

Key Size 2048 bits

Fingerprint (SHA-1) 4B:9D:33:E6:4E:F6:10:4E:20:43:BF:1E:09:28:92:4F:6D:41:33:7A

Fingerprint (MD5) 3E:35:9B:E7:DB:85:D1:5B:98:06:B5:2E:E2:36:0E:68

SANS http://www.google.com

 

As this is a server-end ssl certificate - SHA1 fingerprint - 4B9D33E64EF6104E2043BF1E0928924F6D41337A - there is no authoritative database against which we can check it to simply verify it is "legitimate" or not. One of the many frustrations and failures of CA-based certificates is the utterly imprecise nature of what a "fraudulent" certificate is, or is not. Rather than being a binary yes/no question, we're left with vast swaths of arguable gray-zone... for even professional researchers, debate over the legitimacy of particular certs can go on for weeks... or longer.

 

However, a few quick tests don't provide confidence-inspiring results:

 

First, the cert is signed SHA1 and Google has long since moved away from this as a suitable cert-signing algorithm. Nor is it perhaps some ancient root certificate signed as such decades ago: this one claims to have been issued 6 May 2015 - less than 10 days ago. Is someone at Google really issuing SHA1-signed certs in May of 2015? This seems highly unlikely.

 

Second, the cert-embedded "Authority Information - OCSP" URI (a nearly-vestifial form of not-CRL but also not-full-cert-pinning certificate recovation procedure that we will not bore you with explaining in further detail here) - http://clients1.google.com/ocsp404s when loaded.This is not the sort of thing one will find in a legitimately Google-issued certificate, created less than 10 days ago. (the fact that CRL, OSCP, and other cert-embedded URIs routinely lead to 404s, endless redirects, dead air, and mysterious 'numbers-radio' style short strings of digits - quite often in the case of full root certificates - is one of those realities of CA-certificate existence that is rarely commented on, but remains surreal in its implications)...

 

 

Here's the URI that's supposed to represent the issuer's 'official' credentials, which in theory helps the benighted browser operator verify if the certificate matches this issuer's credentials (although the specifics of doing that match are both impressively complex, and even if done right do not yield valid/fraud clarity but only some degree of qualified 'maybe'): view-source:http://pki.google.com/GIAG2.crt. The certificate that gets provided at that URL is as follows (after a pre-conversion from .crt/DER to .PEM, of course):

 

-----BEGIN CERTIFICATE-----MIID8DCCAtigAwIBAgIDAjp2MA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9iYWwgQ0EwHhcNMTMwNDA1MTUxNTU1WhcNMTYxMjMxMjM1OTU5WjBJMQswCQYDVQQGEwJVUzETMBEGA1UEChMKR29vZ2xlIEluYzElMCMGA1UEAxMcR29vZ2xlIEludGVybmV0IEF1dGhvcml0eSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJwqBHdc2FCROgajguDYUEi8iT/xGXAaiEZ+4I/F8YnOIe5a/mENtzJEiaB0C1NPVaTOgmKV7utZX8bhBYASxF6UP7xbSDj0U/ck5vuR6RXEz/RTDfRK/J9U3n2+oGtvh8DQUB8oMANA2ghzUWx//zo8pzcGjr1LEQTrfSTe5vn8MXH7lNVg8y5Kr0LSy+rEahqyzFPdFUuLH8gZYR/Nnag+YyuENWllhMgZxUYi+FOVvuOAShDGKuy6lyARxzmZEASg8GF6lSWMTlJ14rbtCMoU/M4iarNOz0YDl5cDfsCx3nuvRTPPuj5xt970JSXCDTWJnZ37DhF5iR43xa+OcmkCAwEAAaOB5zCB5DAfBgNVHSMEGDAWgBTAephojYn7qwVkDBF9qn1luMrMTjAdBgNVHQ4EFgQUSt0GFhu89mi1dvWBtrtiGrpagS8wEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAQYwNQYDVR0fBC4wLDAqoCigJoYkaHR0cDovL2cuc3ltY2IuY29tL2NybHMvZ3RnbG9iYWwuY3JsMC4GCCsGAQUFBwEBBCIwIDAeBggrBgEFBQcwAYYSaHR0cDovL2cuc3ltY2QuY29tMBcGA1UdIAQQMA4wDAYKKwYBBAHWeQIFATANBgkqhkiG9w0BAQUFAAOCAQEAJ4zP6cc7vsBv6JaE+5xcXZDkd9uLMmCbZdiFJrW6nx7eZE4fxsggWwmfq6ngCTRFomUlNz1/Wm8gzPn68R2PEAwCOsTJAXaWvpv5Fdg50cUDR3a4iowx1mDV5I/b+jzG1Zgo+ByPF5E0y8tSetH7OiDk4Yax2BgPvtaHZI3FCiVCUe+yOLjgHdDh/Ob0r0a678C/xbQF9ZR1DP6ivgK66oZb+TWzZvXFjYWhGiN3GhkXVBNgnwvhtJwoKvmuAjRtJZOcgqgXe/GFsNMPWOH7sf6coaPo/ck/9Ndx3L2MpBngISMjVROPpBYCCX65r+7bU2S9cS+5Oc4wt7S8VOBHBw==-----END CERTIFICATE-----

That, in turn unpacks to...

 

 

Certificate:

Data:

Version: 3 (0x2)

Serial Number: 146038 (0x23a76)

Signature Algorithm: sha1WithRSAEncryption

Issuer:

commonName = GeoTrust Global CA

organizationName = GeoTrust Inc.

countryName = US

Validity

Not Before: Apr 5 15:15:55 2013 GMT

Not After : Dec 31 23:59:59 2016 GMT

Subject:

commonName = Google Internet Authority G2

organizationName = Google Inc

countryName = US

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (2048 bit)

Modulus:

00:9c:2a:04:77:5c:d8:50:91:3a:06:a3:82:e0:d8:

50:48:bc:89:3f:f1:19:70:1a:88:46:7e:e0:8f:c5:

f1:89:ce:21:ee:5a:fe:61:0d:b7:32:44:89:a0:74:

0b:53:4f:55:a4:ce:82:62:95:ee:eb:59:5f:c6:e1:

05:80:12:c4:5e:94:3f:bc:5b:48:38:f4:53:f7:24:

e6:fb:91:e9:15:c4:cf:f4:53:0d:f4:4a:fc:9f:54:

de:7d:be:a0:6b:6f:87:c0:d0:50:1f:28:30:03:40:

da:08:73:51:6c:7f:ff:3a:3c:a7:37:06:8e:bd:4b:

11:04:eb:7d:24:de:e6:f9:fc:31:71:fb:94:d5:60:

f3:2e:4a:af:42:d2:cb:ea:c4:6a:1a:b2:cc:53:dd:

15:4b:8b:1f:c8:19:61:1f:cd:9d:a8:3e:63:2b:84:

35:69:65:84:c8:19:c5:46:22:f8:53:95:be:e3:80:

4a:10:c6:2a:ec:ba:97:20:11:c7:39:99:10:04:a0:

f0:61:7a:95:25:8c:4e:52:75:e2:b6:ed:08:ca:14:

fc:ce:22:6a:b3:4e:cf:46:03:97:97:03:7e:c0:b1:

de:7b:af:45:33:cf:ba:3e:71:b7:de:f4:25:25:c2:

0d:35:89:9d:9d:fb:0e:11:79:89:1e:37:c5:af:8e:

72:69

Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 Authority Key Identifier: 

keyid:C0:7A:98:68:8D:89:FB:AB:05:64:0C:11:7D:AA:7D:65:B8:CA:CC:4E

 

X509v3 Subject Key Identifier: 

4A:DD:06:16:1B:BC:F6:68:B5:76:F5:81:B6:BB:62:1A:BA:5A:81:2F

X509v3 Basic Constraints: critical

CA:TRUE, pathlen:0

X509v3 Key Usage: critical

Certificate Sign, CRL Sign

X509v3 CRL Distribution Points: 

 

Full Name:

URI:http://g.symcb.com/crls/gtglobal.crl

 

Authority Information Access: 

OCSP - URI:http://g.symcd.com

 

X509v3 Certificate Policies: 

Policy: 1.3.6.1.4.1.11129.2.5.1

 

Signature Algorithm: sha1WithRSAEncryption

27:8c:cf:e9:c7:3b:be:c0:6f:e8:96:84:fb:9c:5c:5d:90:e4:

77:db:8b:32:60:9b:65:d8:85:26:b5:ba:9f:1e:de:64:4e:1f:

c6:c8:20:5b:09:9f:ab:a9:e0:09:34:45:a2:65:25:37:3d:7f:

5a:6f:20:cc:f9:fa:f1:1d:8f:10:0c:02:3a:c4:c9:01:76:96:

be:9b:f9:15:d8:39:d1:c5:03:47:76:b8:8a:8c:31:d6:60:d5:

e4:8f:db:fa:3c:c6:d5:98:28:f8:1c:8f:17:91:34:cb:cb:52:

7a:d1:fb:3a:20:e4:e1:86:b1:d8:18:0f:be:d6:87:64:8d:c5:

0a:25:42:51:ef:b2:38:b8:e0:1d:d0:e1:fc:e6:f4:af:46:ba:

ef:c0:bf:c5:b4:05:f5:94:75:0c:fe:a2:be:02:ba:ea:86:5b:

f9:35:b3:66:f5:c5:8d:85:a1:1a:23:77:1a:19:17:54:13:60:

9f:0b:e1:b4:9c:28:2a:f9:ae:02:34:6d:25:93:9c:82:a8:17:

7b:f1:85:b0:d3:0f:58:e1:fb:b1:fe:9c:a1:a3:e8:fd:c9:3f:

f4:d7:71:dc:bd:8c:a4:19:e0:21:23:23:55:13:8f:a4:16:02:

09:7e:b9:af:ee:db:53:64:bd:71:2f:b9:39:ce:30:b7:b4:bc:

54:e0:47:07

 

Full unpack here:

0 1008: SEQUENCE {   4  728:   SEQUENCE {   8    3:     [0] {  10    1:       INTEGER 2         :       }  13    3:     INTEGER 146038  18   13:     SEQUENCE {  20    9:       OBJECT IDENTIFIER sha1WithRSAEncryption (1 2 840 113549 1 1 5)  31    0:       NULL         :       }  33   66:     SEQUENCE {  35   11:       SET {  37    9:         SEQUENCE {  39    3:           OBJECT IDENTIFIER countryName (2 5 4 6)  44    2:           PrintableString 'US'         :           }         :         }  48   22:       SET {  50   20:         SEQUENCE {  52    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)  57   13:           PrintableString 'GeoTrust Inc.'         :           }         :         }  72   27:       SET {  74   25:         SEQUENCE {  76    3:           OBJECT IDENTIFIER commonName (2 5 4 3)  81   18:           PrintableString 'GeoTrust Global CA'         :           }         :         }         :       } 101   30:     SEQUENCE { 103   13:       UTCTime 05/04/2013 15:15:55 GMT 118   13:       UTCTime 31/12/2016 23:59:59 GMT         :       } 133   73:     SEQUENCE { 135   11:       SET { 137    9:         SEQUENCE { 139    3:           OBJECT IDENTIFIER countryName (2 5 4 6) 144    2:           PrintableString 'US'         :           }         :         } 148   19:       SET { 150   17:         SEQUENCE { 152    3:           OBJECT IDENTIFIER organizationName (2 5 4 10) 157   10:           PrintableString 'Google Inc'         :           }         :         } 169   37:       SET { 171   35:         SEQUENCE { 173    3:           OBJECT IDENTIFIER commonName (2 5 4 3) 178   28:           PrintableString 'Google Internet Authority G2'         :           }         :         }         :       } 208  290:     SEQUENCE { 212   13:       SEQUENCE { 214    9:         OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1) 225    0:         NULL         :         } 227  271:       BIT STRING         :         30 82 01 0A 02 82 01 01 00 9C 2A 04 77 5C D8 50         :         91 3A 06 A3 82 E0 D8 50 48 BC 89 3F F1 19 70 1A         :         88 46 7E E0 8F C5 F1 89 CE 21 EE 5A FE 61 0D B7         :         32 44 89 A0 74 0B 53 4F 55 A4 CE 82 62 95 EE EB         :         59 5F C6 E1 05 80 12 C4 5E 94 3F BC 5B 48 38 F4         :         53 F7 24 E6 FB 91 E9 15 C4 CF F4 53 0D F4 4A FC         :         9F 54 DE 7D BE A0 6B 6F 87 C0 D0 50 1F 28 30 03         :         40 DA 08 73 51 6C 7F FF 3A 3C A7 37 06 8E BD 4B         :                 [ Another 142 bytes skipped ]         :       } 502  231:     [3] { 505  228:       SEQUENCE { 508   31:         SEQUENCE { 510    3:           OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35) 515   24:           OCTET STRING         :             30 16 80 14 C0 7A 98 68 8D 89 FB AB 05 64 0C 11         :             7D AA 7D 65 B8 CA CC 4E         :           } 541   29:         SEQUENCE { 543    3:           OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 548   22:           OCTET STRING         :             04 14 4A DD 06 16 1B BC F6 68 B5 76 F5 81 B6 BB         :             62 1A BA 5A 81 2F         :           } 572   18:         SEQUENCE { 574    3:           OBJECT IDENTIFIER basicConstraints (2 5 29 19) 579    1:           BOOLEAN TRUE 582    8:           OCTET STRING 30 06 01 01 FF 02 01 00         :           } 592   14:         SEQUENCE { 594    3:           OBJECT IDENTIFIER keyUsage (2 5 29 15) 599    1:           BOOLEAN TRUE 602    4:           OCTET STRING 03 02 01 06         :           } 608   53:         SEQUENCE { 610    3:           OBJECT IDENTIFIER cRLDistributionPoints (2 5 29 31) 615   46:           OCTET STRING         :             30 2C 30 2A A0 28 A0 26 86 24 68 74 74 70 3A 2F         :             2F 67 2E 73 79 6D 63 62 2E 63 6F 6D 2F 63 72 6C         :             73 2F 67 74 67 6C 6F 62 61 6C 2E 63 72 6C         :           } 663   46:         SEQUENCE { 665    8:           OBJECT IDENTIFIER authorityInfoAccess (1 3 6 1 5 5 7 1 1) 675   34:           OCTET STRING         :             30 20 30 1E 06 08 2B 06 01 05 05 07 30 01 86 12         :             68 74 74 70 3A 2F 2F 67 2E 73 79 6D 63 64 2E 63         :             6F 6D         :           } 711   23:         SEQUENCE { 713    3:           OBJECT IDENTIFIER certificatePolicies (2 5 29 32) 718   16:           OCTET STRING 30 0E 30 0C 06 0A 2B 06 01 04 01 D6 79 02 05 01         :           }         :         }         :       }         :     } 736   13:   SEQUENCE { 738    9:     OBJECT IDENTIFIER sha1WithRSAEncryption (1 2 840 113549 1 1 5) 749    0:     NULL         :     } 751  257:   BIT STRING         :     27 8C CF E9 C7 3B BE C0 6F E8 96 84 FB 9C 5C 5D         :     90 E4 77 DB 8B 32 60 9B 65 D8 85 26 B5 BA 9F 1E         :     DE 64 4E 1F C6 C8 20 5B 09 9F AB A9 E0 09 34 45         :     A2 65 25 37 3D 7F 5A 6F 20 CC F9 FA F1 1D 8F 10         :     0C 02 3A C4 C9 01 76 96 BE 9B F9 15 D8 39 D1 C5         :     03 47 76 B8 8A 8C 31 D6 60 D5 E4 8F DB FA 3C C6         :     D5 98 28 F8 1C 8F 17 91 34 CB CB 52 7A D1 FB 3A         :     20 E4 E1 86 B1 D8 18 0F BE D6 87 64 8D C5 0A 25         :             [ Another 128 bytes skipped ]         :   }

It's SHA1 fingerprint is: BBDCE13E9D537A5229915CB123C7AAB0A855E798. This intermediate certificate appears to match up with the intermediate certificate provided by the questionable www.gooogle.com page-load, so we do a search on the SHA1 value of the cert's hash to see if it appears in conventional, common search results. Here it is, showing up at the invaluable ssl-tools.net site... although we also noted ourselves, in twitter recently, that this intermediate certificate pops up in some other google server-end of questionable veracity (here's the #fishycerts shapshot if it, for those curious):

 

 

Our conclusion on this server-end certificate being offered as credentials putatively backing this 'secure' https session to www.google.com (

4B9D33E64EF6104E2043BF1E0928924F6D41337A) is that it's illegitimate. The intermediate cert to which it chains (BBDCE13E9D537A5229915CB123C7AAB0A855E798) does appear legitimate... but also seems to be signing more than its fair share of questionable server-end 'Google' SSL certificates. What does that mean, and how does that correlation flesh out into possible theories for causative connection? We simply don't know, yet. Further research is required.

 

 

 

Our search on this server-end certificate's SHA1 hash value - 4B9D33E64EF6104E2043BF1E0928924F6D41337A - turns up no hits, anywhere online (nor for the lowercase-converted version, 4b9d33e64ef6104e2043bf1e0928924f6d41337a). Even if there are obscure mentions somewhere we could not find, the comparison between that and widely-distribued legitimate Google server-end certificates is, in a word, enormous.

 

- - - 

 

 

This post, drafted and edited by the cryptostorm team during a 36 hour window stretching from Friday afternoon through Sunday morning GMT, in fact covers a time-window longer than the transient phenomenon it has documented. By the time final edits were being finished, a check at ssl-labs for IP and certificate results received when their testing suite looks at www.google.com now yeilds the following results. Gone entirely are the two 212.*.*.* IP addresses, and in their place are a string of 74.*.*.*'s that have a much longer history of correlation with Google services (if still some weird results in terms of ssl cert credibility):

 

 

 

In the place of cert 4B9D33E64EF6104E2043BF1E0928924F6D41337A, a server-end certificate SHA1 1219337d219d1684f785bbabe688cea429ac6ee1 is now being presented when ssl-labs asks for the site... that cert is signed as well by intermediate certificate BBDCE13E9D537A5229915CB123C7AAB0A855E798, making it something of a half-sibling to the questionable 4b9d one we saw earlier in this investigation (only a few hours ago). 

 

 

{edited to add: the 4b9 and 1219 certificates appear to be overlapping each other in some ssl-labs test runs, and in browser session tests by some cryptostorm staff members - but not others - as this report has completed editing and is being published... which, as we have seen previous, is not in and in itself indicative of malfeasance but is another component of the suspiciously erratic & coincidence-laden pattern we have been observing}

 

- - - 

 

 

We expect this kind of elliptical, somewhat tedious form of "forensics" to emerge as the norm in Corruptor-Injector Network attack analysis. Such attacks are transient, their 'session prion' payload is buried in otherwise-innocuous http/https traffic hitting the browser via routine, innocuous web browsing (that such attacks will be highly successful beyond the relatively well-defended confines of the browser DOM sandbox is both inevitable, and frightening - protocols like jabber, sftp, and all the weird Java-wrapped cryptographic 'secure' network procedures each carry its own risk of injected prion and collapse of the entire local endpoint security model). 

 

A few points to reiterate: 

 

1. This is a session to http://www.google.com, not an obscure website. It's 'secured' by https, backed by the fearsome expertise and professional focus of google's entire Chrome security team, and then some. It relates to a session during which visitors download an installer for chrome; if that installer is modified even marginally, and achieves uptake on the local machine, all security is gone.

 

2. Certificates involved in effectively spoofing https credentials from google appear to be signed by genuine Google intermediate SHA1-signed certificates. The mechanism for this is not clear yet, but there are dozens of PoC'd methods for a well-resourced attacked to complete this step.

 

3. It's not clear that blaming "the browsers" for this makes sense. It is not the job of browsers to enfore routing legitimacy, although whose job that actually is remains an open question. The browsers can run about cancelling server-end certificates left and right, but it does nothing to address the problem of the injection/hijack gambit itself. 

 

4. A cursory review of DNS records suggests the vast space for temporary resource hijacking via cache poisoning and/or BGP borking forms a core element of these attacks as they exist in the wild today. While there are brilliant researchers out there able to diagnose such transient DNS anomalies, the fact is such anomalies are so common, and so fundamental to DNS as it has evolved, that we gain little in rehasing that well-explored ground.

 

5. We haven't even looked at IP6 in this analysis, despite some early evidence that it forms a crucial element of observed CIN methods. The same can be said for SPDY, QUIC, and other next-generation protocols: each designed and coded by brilliant women & men, but none having anything in the way of long track record in the wilds of CIN-infested routing landscapes.

 

6. This is one instance of this we've chosen to document here, in short form, as a test case and proof of (research) concept. We have files and forensics on dozens more, from obscure websites to serious resources used by hundreds of millions of internet citizens every day. Once we began keeping track o such things several months ago, the examples built up faster and faster... a "backlog of weirdness," as one staffer apologetically explained to a cryptostorm member who had seen data suggesting CIN activity, and hoped we'd be able to review it closely to confirm.

 

7. We see the consequences of this routinely in our member correspondence, globally, on a daily basis. Local computers that have strange network-connectivity problems. Difficulty installing routine packages like openssl or openvpn. Broken cryptographic deployments that cannot support our tightly-enforced standards for cryptostorm session authenticity... these weird goings-on have grown more and more common for us to see, month after month. They foreshadow a deluge of such functionality thefts by CINs from internet users worldwide.

 

"Total pwnage" - as the NSA glibly calls it. Sounds far-fetched? Here's what they have to say about their in-house CIN - #Balrog, we've named it - several years back:

 

 

How would such a system work, in practical terms? Well, here's how:

 

 

Moving to more tangible considerations, how would we know that SECONDDATE attacks were underway? Simple: we'd see network sessions inexplicably redirected to unexpected sites, and modified payloads arrive for those targeted individuals 'painted' by the CIN's selector logic. 

 

An attacker would gain enormous advantage if capable of injecting Chrome package downloads, even transiently. This may seem paranoid, to imagine the sheer arrogance required to play such dangerous games with one of the most powerful companies in the tech industy (and giving Google the benefit of initial assumption they are neither actively aware of these attacks, nor even passively helpless to stop them yet unwiling to make them public via full disclosure).

 

And besides... packages are signed! ...right? Indeed. While it's beyond the scope of this report to go into the numerous proven methods for undermining such signing security, here's a partial list of links - for just one distro of Linux - showing what tends to happen when package-signing throws errors...

 

https://code.google.com/p/chromium/issues/detail?id=249188

http://askubuntu.com/questions/1877/what-is-the-easiest-way-to-resolve-apt-get-badsig-gpg-errors

http://askubuntu.com/questions/410519/cannot-install-anything-via-apt-get-problem-with-apt-get-update?rq=1

http://askubuntu.com/questions/552253/cannot-update-google-chrome-stable-with-apt-even-using-dist-upgrade?rq=1

http://askubuntu.com/questions/307563/why-am-i-getting-package-cannot-be-authenticated-errors-for-google-chrome

http://askubuntu.com/questions/470699/ubuntu-12-04-gpg-error-http-archive-ubuntu-com-precise-release-the-following

http://askubuntu.com/questions/258435/sudo-apt-get-install-google-chrome-stable-current-amd64-deb-is-not-working?rq=1

http://askubuntu.com/questions/555800/upgrading-chrome-stable-aptitude-reports-version-39-but-chrome-chrome-reports?rq=1

http://askubuntu.com/questions/362327/unable-to-install-google-chrome-in-ubuntu12-04-via-google-chrome-stable-current?rq=1

 

There's more, hundreds and hundreds of posts of Linux users - a tiny percentage in the larger OS ocean - having these problems, leading back years. Of course, some - perhaps the majority or even nearly all, are simply the horrifically complex reality of package signing validation if done manually. For those curious, here's Google's Linux Chrome repo howto page with signing key and terse, if excellent, advice for users. That said, it's hosted on http://www.google.com itself... so is the key as-intended by Google? Is it always that way? 

 

If even 5% of those desperate posts reporting failures of the Chrome packages to pass gpg signature-verification are malicious... that's many tens of thousands of Linux Chrome users whose local machines have been irrevocably rooted by an unknown, invisible attacker. 

 

We captured the Chrome package as delivered from the suspect www.google.com page, this weekend. It's too early to say if it shows evidence of direct modification from legitimate parameters; several test-versions downloaded from other sources over the weekend appear to show the same size metrics, on the surface. However, SHA1 hashing is inconclusive: we have divergent hash values for our local copies, as compared to hashes posted elsewhere on the web by others recently for the same version and processor images... but that is far from conclusive, and more work is required.

 

 

Let's look at the package itself, meanwhile. For example, here's the --postinst script in the package captured by us this weekend:

 

#!/bin/sh## Copyright (c) 2009 The Chromium Authors. All rights reserved.# Use of this source code is governed by a BSD-style license that can be# found in the LICENSE file.set -e# Add icons to the system iconsXDG_ICON_RESOURCE="`which xdg-icon-resource 2> /dev/null || true`"if [ ! -x "$XDG_ICON_RESOURCE" ]; then  echo "Error: Could not find xdg-icon-resource" >&2  exit 1fifor icon in "/opt/google/chrome/product_logo_"*.png; do  size="${icon##*/product_logo_}"  "$XDG_ICON_RESOURCE" install --size "${size%.png}" "$icon" "google-chrome"doneUPDATE_MENUS="`which update-menus 2> /dev/null || true`"if [ -x "$UPDATE_MENUS" ]; then  update-menusfi# Update cache of .desktop file MIME types. Non-fatal since it's just a cache.update-desktop-database > /dev/null 2>&1 || true# Updates defaults.list file if present.update_defaults_list() {  # $1: name of the .desktop file  local DEFAULTS_FILE="/usr/share/applications/defaults.list"  if [ ! -f "${DEFAULTS_FILE}" ]; then    return  fi  # Split key-value pair out of MimeType= line from the .desktop file,  # then split semicolon-separated list of mime types (they should not contain  # spaces).  mime_types="$(grep MimeType= /usr/share/applications/${1} |                cut -d '=' -f 2- |                tr ';' ' ')"  for mime_type in ${mime_types}; do    if egrep -q "^${mime_type}=" "${DEFAULTS_FILE}"; then      if ! egrep -q "^${mime_type}=.*${1}" "${DEFAULTS_FILE}"; then        default_apps="$(grep ${mime_type}= "${DEFAULTS_FILE}" |                        cut -d '=' -f 2-)"        egrep -v "^${mime_type}=" "${DEFAULTS_FILE}" > "${DEFAULTS_FILE}.new"        echo "${mime_type}=${default_apps};${1}" >> "${DEFAULTS_FILE}.new"        mv "${DEFAULTS_FILE}.new" "${DEFAULTS_FILE}"      fi    else      # If there's no mention of the mime type in the file, add it.      echo "${mime_type}=${1};" >> "${DEFAULTS_FILE}"    fi  done}update_defaults_list "google-chrome.desktop"# This function uses sed to insert the contents of one file into another file,# after the first line matching a given regular expression. If there is no# matching line, then the file is unchanged.insert_after_first_match() {  # $1: file to update  # $2: regular expression  # $3: file to insert  sed -i -e "1,/$2/ {    /$2/ r $3    }" "$1"}# If /usr/share/gnome-control-center/gnome-default-applications.xml exists, it# may need to be updated to add ourselves to the default applications list. If# we find the file and it does not seem to contain our patch already (the patch# is safe to leave even after uninstall), update it.GNOME_DFL_APPS=/usr/share/gnome-control-center/gnome-default-applications.xmlif [ -f "$GNOME_DFL_APPS" ]; then# Conditionally insert the contents of the file "default-app-block" after the# first "<web-browsers>" line we find in gnome-default-applications.xml  fgrep -q "Google Chrome" "$GNOME_DFL_APPS" || insert_after_first_match \    "$GNOME_DFL_APPS" \    "^[    ]*<web-browsers>[    ]*$" \    "/opt/google/chrome/default-app-block"fi# Add to the alternatives system## On Ubuntu 12.04, we have the following priorities# (which can be obtain be installing browsers and running# update-alternatives --query x-www-browser):## /usr/bin/epiphany-browser  85# /usr/bin/firefox           40# /usr/bin/konqueror         30## While we would expect these values to be keyed off the most popular# browser (Firefox), in practice, we treat Epiphany as the lower bound,# resulting in the following scheme:CHANNEL=stablecase $CHANNEL in  stable )    # Good enough to be the default.    PRIORITY=200    ;;  beta )    # Almost good enough to be the default. (Firefox stable should arguably be    # higher than this, but since that's below the "Epiphany threshold", we're    # not setting our priority below it. Anyone want to poke Firefox to raise    # their priority?)    PRIORITY=150    ;;  unstable )    # Unstable, give it the "lowest" priority.    PRIORITY=120    ;;  * )    PRIORITY=0    ;;esacupdate-alternatives --install /usr/bin/x-www-browser x-www-browser \  /usr/bin/google-chrome-stable $PRIORITYupdate-alternatives --install /usr/bin/gnome-www-browser gnome-www-browser \  /usr/bin/google-chrome-stable $PRIORITYupdate-alternatives --install /usr/bin/google-chrome google-chrome \  /usr/bin/google-chrome-stable $PRIORITY# System-wide package configuration.DEFAULTS_FILE="/etc/default/google-chrome"# sources.list setting for google-chrome updates.REPOCONFIG="deb http://dl.google.com/linux/chrome/deb/ stable main"APT_GET="`which apt-get 2> /dev/null`"APT_CONFIG="`which apt-config 2> /dev/null`"SOURCES_PREAMBLE="### THIS FILE IS AUTOMATICALLY CONFIGURED #### You may comment out this entry, but any other modifications may be lost.\n"# Parse apt configuration and return requested variable value.apt_config_val() {  APTVAR="$1"  if [ -x "$APT_CONFIG" ]; then    "$APT_CONFIG" dump | sed -e "/^$APTVAR /"'!d' -e "s/^$APTVAR \"\(.*\)\".*/\1/"  fi}# Install the repository signing key (see also:# https://www.google.com/linuxrepositories/)install_key() {  APT_KEY="`which apt-key 2> /dev/null`"  if [ -x "$APT_KEY" ]; then    "$APT_KEY" add - >/dev/null 2>&1 <<KEYDATA-----BEGIN PGP PUBLIC KEY BLOCK-----Version: GnuPG v1.4.2.2 (GNU/Linux)mQGiBEXwb0YRBADQva2NLpYXxgjNkbuP0LnPoEXruGmvi3XMIxjEUFuGNCP4Rj/akv2E5VixBP1vcQFDRJ+p1puh8NU0XERlhpyZrVMzzS/RdWdyXf7E5S8oqNXsoD1zfvmI+i9b2EhHAA19Kgw7ifV8vMa4tkwslEmcTiwiw8lyUl28Wh4Et8SxzwCggDcAfeGqtn3PP5YAdD0km4S4XeMEAJjlrqPoPv2Gf//tfznY2UyS9PUqFCPLHgFLe80uQhI2U5jt6jUKN4fHauvR6z3seSAsh1YyzyZCKxJFEKXCCqnrFSoh4WSJsbFNc4PNb0V0SqiTCkWADZyLT5wll8sWuQ5ylTf3z1ENoHf+G3um3/wk/+xmEHvj9HCTBEXP78X0A/0Tqlhc2RBnEf+AqxWvM8sk8LzJI/XGjwBvKfXe+l3rnSR2kEAvGzj5Sg0X4XmfTg4Jl8BNjWyvm2Wmjfet41LPmYJKsux3g0b8yzQxeOA4pQKKAU3Z4+rgzGmfHdwCG5MNT2A5XxD/eDd+L4fRx0HbFkIQoAi1J3YWQSiTk15fw7RMR29vZ2xlLCBJbmMuIExpbnV4IFBhY2thZ2UgU2lnbmluZyBLZXkgPGxpbnV4LXBhY2thZ2VzLWtleW1hc3RlckBnb29nbGUuY29tPohjBBMRAgAjAhsDBgsJCAcDAgQVAggDBBYCAwECHgECF4AFAkYVdn8CGQEACgkQoECDD3+sWZHKSgCfdq3HtNYJLv+XZleb6HN4zOcFAJEAniSFbuv8V5FSHxeRimHx25671az+uQINBEXwb0sQCACuA8HT2nr+FM5y/kzIA51ZcC46KFtIDgjQJ31Q3OrkYP8LbxOpKMRIzvOZrsjOlFmDVqitiVc7qj3lYp6UrgNVaFv6Qu4bo2/ctjNHDDBdv6nufmusJUWq/9TwieepM/cwnXd+HMxu1XBKRVk9XyAZ9SvfcW4EtxVgysI+XlptKFa5JCqFM3qJllVohMmr7lMwO8+sxTWTXqxsptJopZeKz+UBEEqPyw7CUIVYGC9ENEtIMFvAvPqnhj1GS96REMpry+5s9WKuLEaclWpdK3krttbDlY1NaeQUCRvBYZ8iAG9YSLHUHMTuI2oea07Rh4dtIAqPwAX8xn36JAYG2vgLAAMFB/wKqaycjWAZwIe98Yt0qHsdkpmIbarD9fGiA6kfkK/UxjL/k7tmS4VmCljrrDZkPSQ/19mpdRcGXtb0NI9+nyM5trweTvtPw+HPkDiJlTaiCcx+izg79Fj9KcofuNb3lPdXZb9tzf5oDnmm/B+4vkeTuEZJ//IFty8cmvCpzvY+DAz1Vo9rA+ZncpWY1n6z6oSS9AsyT/IFlWWBZZ17SpMHu+h4Bxy62+AbPHKGSujEGQhWq8ZRoJATG0KSObnmZ7FwFWu1e9XFoUCt0bSjiJWTIyaObMrWu/LvJ3e9I87HseSJStfw6fki5og9qFEkMrIrBCp3QGuQWBq/rTdMuwNFiEkEGBECAAkFAkXwb0sCGwwACgkQoECDD3+sWZF/WACfeNAu1/1hwZtUo1bR+MWiCjpvHtwAnA1R3IHqFLQ2X3xJ40XPuAyY/FJG=Quqp-----END PGP PUBLIC KEY BLOCK-----KEYDATA  fi}# Set variables for the locations of the apt sources lists.find_apt_sources() {  APTDIR=$(apt_config_val Dir)  APTETC=$(apt_config_val 'Dir::Etc')  APT_SOURCES="$APTDIR$APTETC$(apt_config_val 'Dir::Etc::sourcelist')"  APT_SOURCESDIR="$APTDIR$APTETC$(apt_config_val 'Dir::Etc::sourceparts')"}# Update the Google repository if it's not set correctly.# Note: this doesn't necessarily enable the repository, it just makes sure the# correct settings are available in the sources list.# Returns:# 0 - no update necessary# 2 - errorupdate_bad_sources() {  if [ ! "$REPOCONFIG" ]; then    return 0  fi  find_apt_sources  SOURCELIST="$APT_SOURCESDIR/google-chrome.list"  # Don't do anything if the file isn't there, since that probably means the  # user disabled it.  if [ ! -r "$SOURCELIST" ]; then    return 0  fi  # Basic check for active configurations (non-blank, non-comment lines).  ACTIVECONFIGS=$(grep -v "^[[:space:]]*\(#.*\)\?$" "$SOURCELIST" 2>/dev/null)  # Check if the correct repository configuration is in there.  REPOMATCH=$(grep "^[[:space:]#]*\b$REPOCONFIG\b" "$SOURCELIST" \    2>/dev/null)  # Check if the correct repository is disabled.  MATCH_DISABLED=$(echo "$REPOMATCH" | grep "^[[:space:]]*#" 2>/dev/null)  # Now figure out if we need to fix things.  BADCONFIG=1  if [ "$REPOMATCH" ]; then    # If it's there and active, that's ideal, so nothing to do.    if [ ! "$MATCH_DISABLED" ]; then      BADCONFIG=0    else      # If it's not active, but neither is anything else, that's fine too.      if [ ! "$ACTIVECONFIGS" ]; then        BADCONFIG=0      fi    fi  fi  if [ $BADCONFIG -eq 0 ]; then    return 0  fi  # At this point, either the correct configuration is completely missing, or  # the wrong configuration is active. In that case, just abandon the mess and  # recreate the file with the correct configuration. If there were no active  # configurations before, create the new configuration disabled.  DISABLE=""  if [ ! "$ACTIVECONFIGS" ]; then    DISABLE="#"  fi  printf "$SOURCES_PREAMBLE" > "$SOURCELIST"  printf "$DISABLE$REPOCONFIG\n" >> "$SOURCELIST"  if [ $? -eq 0 ]; then    return 0  fi  return 2}# Add the Google repository to the apt sources.# Returns:# 0 - sources list was created# 2 - errorcreate_sources_lists() {  if [ ! "$REPOCONFIG" ]; then    return 0  fi  find_apt_sources  SOURCELIST="$APT_SOURCESDIR/google-chrome.list"  if [ -d "$APT_SOURCESDIR" ]; then    printf "$SOURCES_PREAMBLE" > "$SOURCELIST"    printf "$REPOCONFIG\n" >> "$SOURCELIST"    if [ $? -eq 0 ]; then      return 0    fi  fi  return 2}# Remove our custom sources list file.# Returns:# 0 - successfully removed, or not configured# !0 - failed to removeclean_sources_lists() {  if [ ! "$REPOCONFIG" ]; then    return 0  fi  find_apt_sources  rm -f "$APT_SOURCESDIR/google-chrome.list" \        "$APT_SOURCESDIR/google-chrome-stable.list"}# Detect if the repo config was disabled by distro upgrade and enable if# necessary.handle_distro_upgrade() {  if [ ! "$REPOCONFIG" ]; then    return 0  fi  find_apt_sources  SOURCELIST="$APT_SOURCESDIR/google-chrome.list"  if [ -r "$SOURCELIST" ]; then    REPOLINE=$(grep -E "^[[:space:]]*#[[:space:]]*$REPOCONFIG[[:space:]]*# disabled on upgrade to .*" "$SOURCELIST")    if [ $? -eq 0 ]; then      sed -i -e "s,^[[:space:]]*#[[:space:]]*\($REPOCONFIG\)[[:space:]]*# disabled on upgrade to .*,\1," \        "$SOURCELIST"      LOGGER=$(which logger 2> /dev/null)      if [ "$LOGGER" ]; then        "$LOGGER" -t "$0" "Reverted repository modification: $REPOLINE."      fi    fi  fi}DEFAULT_ARCH="i386"get_lib_dir() {  if [ "$DEFAULT_ARCH" = "i386" ]; then    LIBDIR=lib/i386-linux-gnu  elif [ "$DEFAULT_ARCH" = "amd64" ]; then    LIBDIR=lib/x86_64-linux-gnu  else    echo Unknown CPU Architecture: "$DEFAULT_ARCH"    exit 1  fi}NSS_FILES="libnspr4.so.0d libplds4.so.0d libplc4.so.0d libssl3.so.1d \    libnss3.so.1d libsmime3.so.1d libnssutil3.so.1d"add_nss_symlinks() {  get_lib_dir  for f in $NSS_FILES  do    target=$(echo $f | sed 's/\.[01]d$//')    if [ -f "/$LIBDIR/$target" ]; then      ln -snf "/$LIBDIR/$target" "/opt/google/chrome/$f"    elif [ -f "/usr/$LIBDIR/$target" ]; then      ln -snf "/usr/$LIBDIR/$target" "/opt/google/chrome/$f"    else      echo $f not found in "/$LIBDIR/$target" or "/usr/$LIBDIR/$target".      exit 1    fi  done}remove_nss_symlinks() {  for f in $NSS_FILES  do    rm -rf "/opt/google/chrome/$f"  done}remove_udev_symlinks() {  rm -rf "/opt/google/chrome/libudev.so.0"}remove_udev_symlinks## MAIN ##if [ ! -e "$DEFAULTS_FILE" ]; then  echo 'repo_add_once="true"' > "$DEFAULTS_FILE"  echo 'repo_reenable_on_distupgrade="true"' >> "$DEFAULTS_FILE"fi# Run the cron job immediately to perform repository configuration.nohup sh /etc/cron.daily/google-chrome > /dev/null 2>&1 &

Phew.

 

Three-hundred and seventy-six lines. A Chromium Debian reference build - not identical, to be clear, in package parameters - nevertheless is notable for its comparative size:

 

    #!/bin/sh    #    # Copyright (c) 2009 The Chromium Authors. All rights reserved.    # Use of this source code is governed by a BSD-style license that can be    # found in the LICENSE file.    @@[member=include02]@@../common/postinst.include    # Add to the alternatives system    #    # On Ubuntu 12.04, we have the following priorities    # (which can be obtain be installing browsers and running    # update-alternatives --query x-www-browser):    #    # /usr/bin/epiphany-browser 85    # /usr/bin/firefox 40    # /usr/bin/konqueror 30    #    # While we would expect these values to be keyed off the most popular    # browser (Firefox), in practice, we treat Epiphany as the lower bound,    # resulting in the following scheme:    CHANNEL=@@[member=Channel11]@@    case $CHANNEL in    stable )    # Good enough to be the default.    PRIORITY=200    ;;    beta )    # Almost good enough to be the default. (Firefox stable should arguably be    # higher than this, but since that's below the "Epiphany threshold", we're    # not setting our priority below it. Anyone want to poke Firefox to raise    # their priority?)    PRIORITY=150    ;;    unstable )    # Unstable, give it the "lowest" priority.    PRIORITY=120    ;;    * )    PRIORITY=0    ;;    esac    update-alternatives --install /usr/bin/x-www-browser x-www-browser \    /usr/bin/@@[member=usrevenge]_BIN_SYMLINK_NAME@@ $PRIORITY    update-alternatives --install /usr/bin/gnome-www-browser gnome-www-browser \    /usr/bin/@@[member=usrevenge]_BIN_SYMLINK_NAME@@ $PRIORITY    update-alternatives --install /usr/bin/google-chrome google-chrome \    /usr/bin/@@[member=usrevenge]_BIN_SYMLINK_NAME@@ $PRIORITY    @@[member=include02]@@../common/apt.include    @@[member=include02]@@../common/symlinks.include    remove_udev_symlinks    add_udev_symlinks    ## MAIN ##    if [ ! -e "$DEFAULTS_FILE" ]; then    echo 'repo_add_once="true"' > "$DEFAULTS_FILE"    echo 'repo_reenable_on_distupgrade="true"' >> "$DEFAULTS_FILE"    fi    # Run the cron job immediately to perform repository configuration.    nohup sh /etc/cron.daily/@@PACKAGE@@ > /dev/null 2>&1 &

Sixty-seven lines. A report of very unusual behaviour on the part of that script, from 2012. 

 

 

A Lintian scan of the .deb package reads as follows...

 

E: google-chrome-stable: embedded-library opt/google/chrome/PepperFlash/libpepflashplayer.so: opensslE: google-chrome-stable: embedded-library opt/google/chrome/chrome: lcms2E: google-chrome-stable: embedded-library opt/google/chrome/chrome: srtpE: google-chrome-stable: embedded-library opt/google/chrome/chrome: sqliteE: google-chrome-stable: embedded-library opt/google/chrome/chrome: libpngE: google-chrome-stable: embedded-library opt/google/chrome/chrome: libxml2E: google-chrome-stable: embedded-library opt/google/chrome/chrome: libjpegE: google-chrome-stable: embedded-library opt/google/chrome/chrome: libjsoncppE: google-chrome-stable: embedded-library opt/google/chrome/libffmpegsumo.so: libavutilE: google-chrome-stable: statically-linked-binary opt/google/chrome/nacl_helper_bootstrapE: google-chrome-stable: statically-linked-binary opt/google/chrome/nacl_irt_x86_32.nexeE: google-chrome-stable: debian-changelog-file-missing-or-wrong-nameW: google-chrome-stable: new-package-should-close-itp-bugW: google-chrome-stable: debian-changelog-line-too-long line 3E: google-chrome-stable: no-copyright-fileW: google-chrome-stable: description-synopsis-starts-with-articleW: google-chrome-stable: extended-description-line-too-longE: google-chrome-stable: dir-or-file-in-opt opt/google/E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/PepperFlash/E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/PepperFlash/libpepflashplayer.soE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/PepperFlash/manifest.jsonE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/chromeE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/chrome-sandboxW: google-chrome-stable: setuid-binary opt/google/chrome/chrome-sandbox 4755 root/rootE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/chrome_100_percent.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/cron/E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/cron/google-chromeE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default-app-blockE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default_apps/E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default_apps/docs.crxE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default_apps/drive.crxE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default_apps/external_extensions.jsonE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default_apps/gmail.crxE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default_apps/search.crxE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default_apps/youtube.crxE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/google-chromeE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/icudtl.datE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/libffmpegsumo.soE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/libwidevinecdm.soE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/libwidevinecdmadapter.soE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/am.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ar.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/bg.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/bn.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ca.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/cs.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/da.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/de.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/el.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/en-GB.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/en-US.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/es-419.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/es.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/et.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/fa.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/fi.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/fil.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/fr.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/gu.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/he.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/hi.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/hr.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/hu.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/id.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/it.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ja.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/kn.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ko.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/lt.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/lv.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ml.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/mr.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ms.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/nb.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/nl.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/pl.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/pt-BR.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/pt-PT.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ro.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ru.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/sk.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/sl.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/sr.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/sv.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/sw.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ta.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/te.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/th.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/tr.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/uk.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/vi.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/zh-CN.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/zh-TW.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/nacl_helperE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/nacl_helper_bootstrapE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/nacl_irt_x86_32.nexeE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/natives_blob.binE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_128.pngE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_16.pngE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_22.pngE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_24.pngE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_256.pngE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_32.pngE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_32.xpmE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_48.pngE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_64.pngE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/resources.pakE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/snapshot_blob.binE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/xdg-mimeE: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/xdg-settingsW: google-chrome-stable: non-standard-dir-perm usr/share/doc/google-chrome-stable/ 0700 != 0755E: google-chrome-stable: executable-manpage usr/share/man/man1/google-chrome.1E: google-chrome-stable: manpage-not-compressed usr/share/man/man1/google-chrome.1W: google-chrome-stable: manpage-has-errors-from-man usr/share/man/man1/google-chrome.1 1: warning: macro `"' not definedW: google-chrome-stable: binary-without-manpage usr/bin/google-chrome-stableW: google-chrome-stable: pkg-not-in-package-test google-chrome usr/share/menu/google-chrome.menuE: google-chrome-stable: prerm-calls-updatemenusW: google-chrome-stable: executable-not-elf-or-script usr/share/man/man1/google-chrome.1E: google-chrome-stable: shlib-with-non-pic-code opt/google/chrome/libffmpegsumo.soLintian finished with exit status 1

Do these results match known-good equivalents? It's entirely possible they do... but we'll be double-checking that, to be sure.

 

However, it's much harder to come up with a legitimate explanation for the presence of this parameter: 

 

 <netscape-remote>true</netscape-remote>

In /apt/google/chrome/default-app-block...

  <web-browser>      <name>Google Chrome</name>      <executable>/opt/google/chrome/google-chrome</executable>      <command>/opt/google/chrome/google-chrome %s</command>      <icon-name>google-chrome</icon-name>      <run-in-terminal>false</run-in-terminal>      <netscape-remote>true</netscape-remote>      <tab-command>/opt/google/chrome/google-chrome %s</tab-command>      <win-command>/opt/google/chrome/google-chrome --new-window %s</win-command>    </web-browser>

Netscape-remote" shows up in only a few places, including the Russian-presenting "Sisyphus" nonstandard repository, in a Gnome-related package called "gnome-control-center" - we're helpfuly informed that "If you install GNOME, you need to install control-center." It's not clear if this repository is borked or not. What is clear is that the parameter for remote-access is flagged "true" in the build we got from "www.google.com" this weekend. It seems highly unlikely that's the default setting coming out from Google liegitimately... although, as with all such things, we welcome correction from specific subject-matter experts.

 

 

 

These transient issues with strange 'google' certificates have been repeating themselves during the past couple months. In early April, a journalist in the UK reported on invalid Gmail SMTP certs being served to users worldwide for several hours. The issue was reported on twitter... but the tweet is now gone.

 

It appears everyone assumed this was an error on Google's part (comments left on the article cited - two of them indicate transient continuance of the issue up through mid-April at least, although blame is cast on Google for 'misconfiguring' gmai's servers), although the carefully-worded status updated Google provided are notable in not actually saying anything specific whatsoever...

 

 

4/4/15, 9:46 PM

The problem with Gmail should be resolved. We apologize for the inconvenience and thank you for your patience and continued support. Please rest assured that system reliability is a top priority at Google, and we are making continuous improvements to make our systems better.

 

4/4/15, 8:58 PM

We expect to resolve the problem affecting a majority of users of Gmail at 4/4/15, 10:00 PM. Please note that this time frame is an estimate and may change. smtp.gmail.com is displaying an invalid certificate.

 

4/4/15, 8:00 PM

We're aware of a problem with Gmail affecting a majority of users. The affected users are able to access Gmail, but are seeing error messages and/or other unexpected behavior. We will provide an update by 4/4/15, 9:00 PM detailing when we expect to resolve the problem. Please note that this resolution time is an estimate and may change. smtp.gmail.com is displaying an invalid certificate.

 

4/4/15, 7:21 PM

We're investigating reports of an issue with Gmail. We will provide more information shortly. smtp.gmail.com is displaying an invalid certificate.

 

And of course, in early May we flagged the unusual sibling-cert publicly in twitter.

 

But what about the GPG signatures, right? That's the bulwark, and we've not addressed it. Our results are preliminary and await confirmation, because... well, because gnupg. We're going to provide a sample of output from our signature-validation efforts, locally; it is representative of what we've seen in the short period we've been working this particular angle.

 

Once again, it could be we've managed to mis-specify the test - code-signing is not our cryptographic focus, despite cryptostorm being... well, something of a crypto-specalist shop in daily work life.

 

 

~/# wget https://dl.google.com/linux/linux_signing_key.pub

--2015-05-17 14:26:38-- https://dl.google.com/linux/linux_signing_key.pub

Resolving dl.google.com (dl.google.com)... 173.194.112.64, 173.194.112.72, 173.194.112.78, ...

Connecting to dl.google.com (dl.google.com)|173.194.112.64|:443... connected.

HTTP request sent, awaiting response... 200 OK

Length: 1745 (1.7K) [text/plain]

Saving to: ‘linux_signing_key.pub’

 

linux_signing_key.pub 100%[=============================================================================>] 1.70K --.-KB/s in 0.001s 

 

2015-05-17 14:26:39 (1.21 MB/s) - ‘linux_signing_key.pub’ saved [1745/1745]

 

~/# gpg --verify linux_signing_key.pub google-chrome-stable_current_i386.deb

gpg: verify signatures failed: unexpected data

 

~/# apt-cache policy google-chrome-stable

google-chrome-stable:

Installed: (none)

Candidate: 42.0.2311.152-1

Version table:

42.0.2311.152-1 0

500 http://dl.google.com/linux/chrome/deb/stable/main i386 Packages

 

~/# gpg --import linux_signing_key.pub

gpg: key 7FAC5991: public key "Google, Inc. Linux Package Signing Key <[email protected]>" imported

gpg: Total number processed: 1

gpg: imported: 1

 

~/# gpg --verify linux_signing_key.pub google-chrome-stable_current_i386.deb

gpg: verify signatures failed: unexpected data

 

~/# gpg -v -v --verify linux_signing_key.pub

gpg: armor: BEGIN PGP PUBLIC KEY BLOCK

gpg: armor header: Version: GnuPG v1.4.2.2 (GNU/Linux)

:public key packet:

version 4, algo 17, created 1173385030, expires 0

pkey[0]: [1024 bits]

pkey[1]: [160 bits]

pkey[2]: [1024 bits]

pkey[3]: [1021 bits]

keyid: A040830F7FAC5991

gpg: verify signatures failed: unexpected data

 

~/# apt-key add linux_signing_key.pub

OK

 

~/# gpg --list-sig 7FAC5991

pub 1024D/7FAC5991 2007-03-08

uid Google, Inc. Linux Package Signing Key <[email protected]>

sig 3 7FAC5991 2007-04-05 Google, Inc. Linux Package Signing Key <[email protected]>

sub 2048g/C07CB649 2007-03-08

sig 7FAC5991 2007-03-08 Google, Inc. Linux Package Signing Key <[email protected]>

 

~/# gpg --version

gpg (GnuPG) 1.4.18

Copyright © 2014 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

 

Home: ~/.gnupg

Supported algorithms:

Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA

Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,

CAMELLIA128, CAMELLIA192, CAMELLIA256

Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224

Compression: Uncompressed, ZIP, ZLIB, BZIP2

 

~/# apt-get --reinstall install gnupg

Reading package lists... Done

Building dependency tree 

Reading state information... Done

0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 2 not upgraded.

Need to get 1,170 kB of archives.

After this operation, 0 B of additional disk space will be used.

Get:1 http://http.debian.net/debian/jessie/main gnupg i386 1.4.18-7 [1,170 kB]

Fetched 1,170 kB in 5s (208 kB/s) 

(Reading database ... 149753 files and directories currently installed.)

Preparing to unpack .../gnupg_1.4.18-7_i386.deb ...

Unpacking gnupg (1.4.18-7) over (1.4.18-7) ...

Processing triggers for man-db (2.7.0.2-5) ...

Processing triggers for install-info (5.2.0.dfsg.1-6) ...

Setting up gnupg (1.4.18-7) ...

 

~/# gpg --version

gpg (GnuPG) 1.4.18

Copyright © 2014 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

 

Home: ~/.gnupg

Supported algorithms:

Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA

Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,

CAMELLIA128, CAMELLIA192, CAMELLIA256

Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224

Compression: Uncompressed, ZIP, ZLIB, BZIP2

 

~/# gpg --list-sig 7FAC5991

pub 1024D/7FAC5991 2007-03-08

uid Google, Inc. Linux Package Signing Key <[email protected]>

sig 3 7FAC5991 2007-04-05 Google, Inc. Linux Package Signing Key <[email protected]>

sub 2048g/C07CB649 2007-03-08

sig 7FAC5991 2007-03-08 Google, Inc. Linux Package Signing Key <[email protected]>

 

~/# gpg -v -v --verify linux_signing_key.pub

gpg: armor: BEGIN PGP PUBLIC KEY BLOCK

gpg: armor header: Version: GnuPG v1.4.2.2 (GNU/Linux)

:public key packet:

version 4, algo 17, created 1173385030, expires 0

pkey[0]: [1024 bits]

pkey[1]: [160 bits]

pkey[2]: [1024 bits]

pkey[3]: [1021 bits]

keyid: A040830F7FAC5991

gpg: verify signatures failed: unexpected data

 

These results remain open to clarification and correction, as we prepare to publish this report.

 

- - -

 

 

Corruptor-Injector attacks are not the sole province of the NSA, or their #Balrog system. China has made use of similar capabilties, often quite publicly - with a notable emphasis on session hijack of https 'secure' communiations via fraudulent certificates at mass scale. Private versions of the technology exist as well.

 

An old cryptographic adage goes that mathematical cryptanalytic attacks always get better; they never get worse. Corruptor-Injector Network systems apppear to have reached an inflection point; in game-theoretic terms, a potential 'tragedy of the commons' amoungst those giant entities who have them already. Once word begins to spread of how CINs work, the incentive to keep them under wraps drops asymptotically - since each attacker knows other attackers are likely to jump forward in aggressiveness and public visibility, even if they refrain. Thus, each has an incentive to be 'first to break' and the accelerating aggressiveness of these CIN tactics accelerates even further.

 

 

The end result is, in a word, internet chaos.

 

The security - and privacy - consequences of these tools spiralling into a frenzied battle for injector-primacy on our shared internet are simply impossible to overstate. Anyone infected with these - 'painted' by them, as disinfection is not structurally possible - will see themslves essentially driven offline if they are aware of the attack and must mitigate the security damage proactively by air-gapping. Those unaware they have been injected with a live session prion are rooted, and every activity of their computer, or smartphone, is being logged and remotely archived: email, encryption keys, chat logs, 'secure' web sesions, application updates. Screenshots are being taken and uploaded to the attacker, microphones enabled to record sound nearby, and webcams enabled to snap photos of the operator.

 

None of the items in this devil's list of extreme privacy violations is a could-be-possible, or a hypothetical. Leaked documents validate each one is being done, and more so each has been automated and works without manual intervention.

 

There is no greater threat to online privacy, network security, and the continued effective functioning of the internet for the next half-decade or more than Corruptor-Injector Networks, and their accelerating spread. All other threats combined likely don't meet the level CINs represent.

 

 

 

CINs are the 'dirty bombs' of mass surveillance: brutal, destructive, producing a long-term legacy of crippled internet functionality that will cost tens of billions of dollars in real human benefits foregone to these macabre engines of corruption.

 

But far worse than the economic devastation is the human cost of these privacy annhiliations, one person at a time. Activists picked up in their homes, tortued to death, bodies dumped in empty field by dictators with access to CIN intelligence. Minority groups wiped clean in tactical genocides enabled by absolutely totalistic, perfect intelligence data produced by CINs for violent fascists. Democratic political systems undermined by the massive blackmail leverage of total CIN visibility in the hands of opponents... the list goes on.

 

The time to face CINs as the threat they have become is now. The data exist to validate already-existing deductive confirmation of their expanding footprint, thanks to Snowden and other whistleblowers. 

 

At cryptostorm, we are all-in to enable broad-scope CIN-evasion techniques, systems, architectures, and services. Already we're working on layered approaches, fluid and flexible and decentralised. The tools exist to do this - good tools, well-tested - but the will to face the threat will be the key driver. We have that will, because we know the damage our members face if they are without protection from CIN. It is our obligation to provide that protection, as a security service, and we look forward to working with other researchers to expand our vision and, in time, retake the internet from the power-mad corruption of these obscene mechanisms.

 

 

With sincerity,

 

~ cryptostorm_team

 

[cesrai]

I haven't read all of it yet, but my first thoughts is people who made this are really smart and I may have a fake chrome build.

[Enderman]

And this is why you ALWAYS use an antivirus, kids.

Using the internet safely with common sense cannot keep you secure forever.....

[cesrai]

And this is why you ALWAYS use an antivirus, kids.

Using the internet safely with common sense cannot keep you secure forever.....

What do you recommend ?? I just use windows defender and antimalwarebytes.

[UnknownEngineer]

There wouldn't happen to have a TLDR for this....please?

[qwertywarrior]

do u want to get banned or something

stop posting 10 mile long topics already

[Delusional Phil]

There are forensics for that ? You learn something new everyday I guess ... 

[Hawx]

What do you recommend ?? I just use windows defender and antimalwarebytes.

 

Kaspersky and Bitdefender are the best. Take your pick.

 

 

There wouldn't happen to have a TLDR for this....please?

 

It's essentially a man-in-the-middle attack that can directly affect major websites like google. It's hard to track and hasn't been extensively documented before now.

[colonel_mortis]

@SmirGel as per the posting guidelines, can you only include a short snippet of the source rather than copying out the entire, incredibly long, source.

[Bouzoo]

What do you recommend ?? I just use windows defender and antimalwarebytes.

I use nod32 and recommend it to everyone, never had any problems it (what, 7 years now?), not a single virus or anything, while on the other hand a lot of people had problems with other a/vs. Yes, you have to pay for it but it's worh it.

Kaspersky and Bitdefender are the best.

Heard only from 1 person bad thing about Kaspersky, and it was about slowing network traffic or something like that when playing a MMO. But I think that person was, well dumb tbh. And how is Bitdefender these days? I wouldn't touch it with a stick, had lots of problems with it years ago, but have been hearing recently it's quite good now.

[Enderman]

What do you recommend ?? I just use windows defender and antimalwarebytes.

avast or AVG

those two are the best

 

but dont stop using malwarebytes, you want that one too

[colonel_mortis]

@SmirGel I'm locking this thread now since it doesn't follow the Tech News and Reviews Posting Guidelines. Specifically, you have quoted the entire source rather than only providing an extract from it, and you haven't provided any original input on the story. If you edit the OP to bring it inline with the guidelines then send me a PM, I can unlock it again for you.