For PC users it’s a case of here we go again. Earlier in 2015, PC giant Lenovo was infamously caught shipping Windows computers with a piece of useless adware containing a self-signed root certificate that opened a massive security hole for customers. This week, it was Dell’s turn. Crowdsourced researchers revealed that the company had suffered the same egregious weakness not once, but twice, this time inside a pair of tools used for remote support.

Lenovo’s issue was more embarrassing than Dell’s – the vulnerability was part of a program called Superfish witlessly put there to serve adverts inside browser sessions – but frankly from a security point this sort of distinction makes no odds. Embedding a self-signed SSL certificate with the private key in an application shipped to large numbers of users is asking for trouble and should not have happened. This sort of configuration would be normal for a development application, not the final software, which should have used a signed certificate in the filestore from a Certificate Authority (CA).


The problem in more detail: Dell’s Foundation Services remote support tool was discovered to have installed a self-signed root certificate identifying itself as ‘eDellRoot’. In common parlance, that offered anyone aware of the issue the possibility of extracting the certificate’s private key to create a means to impersonate any HTTPS website connection they fancied as part of a TLS man-in-the-middle compromise. This is very bad – browsers would accept this borrowed certificate as genuine and in most cases throw up no browser warning. Criminals could also sign malware to make it appear legitimate not to mention delve into encrypted data such as website logins by sniffing laptops connecting through public Wi-Fi.

The size of the risk? Potentially huge for any system lacking remediation (see below). This must be addressed urgently.

That all? Apparently a second tool, Dell System Detect (DSD), has been discovered trying the same insecure trick with a self-signed certificate called DSDTestProvider. The Dell private PKI keys used to create these certificates are now insecure.

How was it discovered? Technical users and interested researchers talking to one another on Reddit and other sites.

Which Dell computers are affected? It’s still not 100 percent clear but potentially any recent system using Dell’s Foundation Services software from the factory-installed image, including business systems in the XPS, Vostro, Inspiron, OptiPlex, and Precision lines. The second issue, DSDTestProvider, only applies to customers who downloaded that component between October 20 and November 24, 2015.

Are Dell’s non-PC products affected? No, the support program is a Windows service. Also, PCs that don’t have applications such as browsers that would access the certificate are not a priority for fixes.

What about remediation? Unlike Lenovo, which appears to have dithered over Superfish for weeks or even months, Dell has jumped on the issue quickly. Detailed instructions are available on Dell’s website and can be achieved manually by stopping the Dell Foundation Services software form Task Manager before deleting the relevant .dll. The two certificates must also be deleted from the certificate store (cmd > certmgr.msc, look for ‘Trusted Root Certificate Authorities’). An automated tool to do the above is also available.

Additional admin headache: Because the Dell Foundation Services is part of the factory image, recovery partitions will still contain the vulnerable software. If that image is used to recover a system at some point in the future then the same flaw will recur. This means that admins probably need to reinstall a new factory image from scratch on all affected systems.

Why did this happen? Most likely programming oversight and complacency and a failure of whatever security assurance is used by Dell. The developers should not have installed a self-signed root certificate - a trusted Certificate Authority (CA) should have been used for this type of software – and certainly should not have assumed that marking the private key as ‘non-exportable’ in the certificate store offered protection. Tools exist to bypass this sort of security.

Any larger lessons for businesses? It's not Not Dell's doing but CAs are a these days a source of security worry with rogue companies having been found issuing what appear to be trusted certificates but turn out to have been created for malevolent ends. State-backed groups are fond of this tactic. The world is not far from an age of aggressive CA whitelisting – that will have been given a big jolt by the Superfish and Dell incidents.