Security

Lenovo and Superfish

By Jake Edge
February 25, 2015

While it doesn't directly affect Linux users, Lenovo's bundling of the Superfish adware—malware is probably more accurate—is serious enough to warrant a look. It is a blunder that has been compared with the Sony rootkit scandal of the mid-2000s and, in truth, is probably worse. Due to the bundling, users of Windows on certain Lenovo laptop models have had both their privacy and their security imperiled—sacrificed on the altar of ad delivery. It's not terribly surprising that Lenovo and Superfish have tried to downplay the severity of the incident, but that narrative seems unlikely to prevail.

Web browsers use a collection of root certificates (called the root store) to identify certificate authorities (CAs) and their keys. The public keys in those certificates are trusted to verify the TLS/SSL certificates for other web sites. Attackers who have access to the private key associated with a certificate in the root store can sign a certificate that purports to be from any domain on the internet. That certificate will be accepted by browsers without any questions or warnings. So a user visiting their bank might get an attacker-controlled certificate from a "man in the middle", who could proxy the traffic to the actual bank site while capturing passwords and other sensitive information.

Lenovo pre-installed Superfish to serve ads in the web browser on some of its laptop models; a list can be found at the end of Lenovo's first response to the incident. The company said that it stopped bundling Superfish in January after customer complaints. For those concerned that they might be affected, there is a site that they can visit to determine if Superfish (or some other forms of ad-malware) are running on their systems.

When it was installed by Lenovo, Superfish placed a root certificate into the Windows system root store; it also added the certificate to Firefox's (and Thunderbird's) separate root store. The intention is to be able to intercept the user's encrypted traffic so that ads can be shown; these will even show up on TLS-protected sites (i.e. HTTPS).

As it turns out, the Superfish ad serving proxy uses an "SSL hijacker" from Komodia [Wayback Machine link due to a denial of service attack against Komodia] to actually perform the man-in-the-middle attack. The Komodia hijacker intercepts the server certificate presented by the remote site, replaces the public key in the certificate with its own, then signs the certificate with the private portion of the public key placed into the root store.

The Komodia private key is protected by a password, but the password (which is the super-secure string "komodia") is the same on all of the installations. In fact, all of the Superfish-infected Lenovo laptops share the same key, but other Komodia-using applications get their own key. All appear to use the same password, however. Anyone with access to the keys can use them to sign any certificate they want, which will be accepted without complaint by the Komodia/Superfish-infected systems.

Unfortunately for Komodia, Superfish, Lenovo, and others, it gets worse than that. A man-in-the-middle attacker doesn't even need to use the easily available keys because the Komodia proxy will re-sign any bad certificate that it receives with its own key. It effectively launders bad certificates, turning them into valid certificates. It does actually change the domain name on the bad certificate, which will lead to a warning from the browser—except when it doesn't.

While it is likely that many users will just click past the warning, changing a self-signed certificate for example.com to verify_fail.example.com (as Komodia hijacker does) at least gives the user some warning. But the Komodia code doesn't handle any alternate names in the certificate, so an attacker can just put the real domain name they want to spoof in the alternate name field, Komodia will re-sign the certificate, and the browser will accept it without any questions. It makes exploiting the Komodia hijacker all that much easier.

The reaction from the players has ranged from nearly comical ("Despite the false and misleading statements made by some media commentators and bloggers, the Superfish software does not present a security risk", Superfish said) and Lenovo's since-removed original response ("We have thoroughly investigated this technology and do not find any evidence to substantiate security concerns") to a slowly evolving recognition that there is a real problem at hand (Lenovo's second and third statements on the uproar). So far, Komodia has not put out a statement at all.

While this "attack" targeted Windows, there is nothing that makes it an inherent problem for that operating system. A rogue application could certainly interfere with the root store(s) on a Linux system. It might be aimed at delivering ads, as this was, or perhaps as some kind of anti-cheating mechanism for a game or a DRM measure for some kind of media. In any of those cases, or other, similar scenarios, it would be hard to see that action as anything other than a man-in-the-middle attack.

But, in essence, the mechanism used is no different from what some network administrators do to the machines on their network: add a root certificate that provides a local trust anchor so that they can decrypt TLS traffic. That is why the certificate pinning feature that originated in Chrome/Chromium and has been added to Firefox does not thwart root certificates that have been installed locally. Thus the current implementations of certificate pinning are no defense against the Superfish/Komodia software. If pinning were to ignore local trust anchors, it would take away local administrators' ability to install their own certificates, either for snooping on traffic or simply to enable a separate company-controlled signing authority to avoid the expense of CAs. On the other hand, recent Android systems do warn users about certificates that have been added to the root store.

The real lesson from this horrendous security botch by Lenovo—beyond the idea of simply listening to security researchers rather than trying to bluster your way around them—is yet another reminder that the certificates stored on your systems need to be jealously guarded. Whether a rogue root certificate comes from a CA with inadequate safeguards or from a company that thinks it is a good idea to inject ads into your supposedly secure browsing hardly matters. The end result is the same: degradation or elimination of your privacy and security.

Comments (16 posted)

Brief items

Security quotes of the week

We can laugh at proprietary vendors engaging in dreadful security practices. We can feel smug about giving users the tools to choose their own level of security. But until we're actually making it straightforward for users to choose freedom without giving up security, we're not providing something meaningfully better - we're just providing the same shit sandwich on different bread.

— Matthew Garrett

With these stolen encryption keys, intelligence agencies can monitor mobile communications without seeking or receiving approval from telecom companies and foreign governments. Possessing the keys also sidesteps the need to get a warrant or a wiretap, while leaving no trace on the wireless provider’s network that the communications were intercepted. Bulk key theft additionally enables the intelligence agencies to unlock any previously encrypted communications they had already intercepted, but did not yet have the ability to decrypt.

— Jeremy Scahill and Josh Begley on SIM card encryption key theft, as revealed by Edward Snowden, in The Intercept

It would be nice to see that the revelation of the NSA undermining one use of encryption led people to realize the stupidity of undermining other forms of encryption, but somehow, it seems likely that our law enforcement community won't quite comprehend that message.

— Mike Masnick

We always knew that they would occasionally steal SIM keys. But all of them? The odds that they just attacked this one firm are extraordinarily low and we know the NSA does like to steal keys where it can.

— Bruce Schneier in The Register

Comments (6 posted)

EFF: Lenovo is breaking HTTPS security on its recent laptops

Here is a statement from the Electronic Frontier Foundation on the revelation that Lenovo has been shipping insecure man-in-the-middle malware on its laptops. "Lenovo has not just injected ads in a wildly inappropriate manner, but engineered a massive security catastrophe for its users. The use of a single certificate for all of the MITM attacks means that all HTTPS security for at least Internet Explorer, Chrome, and Safari for Windows, on all of these Lenovo laptops, is now broken." For additional amusement, see Lenovo's statement on the issue.

There are a lot of Lenovo users in LWN's audience. Presumably most of them have long since done away with the original software, but those who might have kept it around would be well advised to look into the issue; this site can evidently indicate whether a machine is vulnerable or not.

Comments (144 posted)

Green: Another update on the Truecrypt audit

On his blog, Matthew Green gives an update on the plans to audit the TrueCrypt disk encryption tool. Green led an effort in 2013 to raise money for an audit of the TrueCrypt source code, which sort of ran aground when TrueCrypt abruptly shut down in May 2014. "It took us a while to recover from this and come up with a plan B that works within our budget and makes sense. We're now implementing this. A few weeks ago we signed a contract with the newly formed NCC Group's Cryptography Services practice (which grew out of iSEC, Matasano and Intrepidus Group). The project will evaluate the original Truecrypt 7.1a which serves as a baseline for the newer forks, and it will begin shortly. However to minimize price -- and make your donations stretch farther -- we allowed the start date to be a bit flexible, which is why we don't have results yet."

Comments (5 posted)

Remote code execution vulnerability in Samba

The Samba 4.1.17, 4.0.25 and 3.6.25 releases are available; they fix an unpleasant code-execution vulnerability. See this Red Hat security blog entry for more information. "CVE-2015-0240 is a security flaw in the smbd file server daemon. It can be exploited by a malicious Samba client, by sending specially-crafted packets to the Samba server. No [authentication] is required to exploit this flaw. It can result in remotely controlled execution of arbitrary code as root."

Comments (68 posted)

New vulnerabilities

apache-poi: denial of service

Package(s):

apache-poi

CVE #(s):

CVE-2014-9527

Created:

February 23, 2015

Updated:

February 26, 2015

Description:

From the Red Hat bugzilla:

A denial of service flaw was found in the way the HSLFSlideShow class implementation in Apache POI handled certain PPT files. A remote attacker could submit a specially crafted PPT file that would cause Apache POI to hang indefinitely.

Alerts:

Mageia	MGASA-2015-0087	apache-poi	2015-02-26
Fedora	FEDORA-2015-2090	apache-poi	2015-02-23

Security

Lenovo and Superfish

Brief items

Security quotes of the week

EFF: Lenovo is breaking HTTPS security on its recent laptops

Green: Another update on the Truecrypt audit

Remote code execution vulnerability in Samba

New vulnerabilities

apache-poi: denial of service

bind9: denial of service

drupal6-views: multiple vulnerabilities

drupal7-path_breadcrumbs: access restriction bypass

e2fsprogs: code execution

freetype: many vulnerabilities

glibc: sends DNS queries to random file descriptors

glibc: code execution

java: unspecified vulnerability

kernel: two vulnerabilities

kernel: two vulnerabilities

mozilla: multiple vulnerabilities

openstack-glance: access restriction bypass

php5: code execution

php: use after free

ruby-redcloth: cross-site scripting

samba: root code execution

tomcat: HTTP request smuggling

typo3-src: authentication bypass

xdg-utils: command execution