Another Dell root certificate discovered
pcworld.com
pcworld.com
Seriously, their entire security relied on 'if url.endswith('dell.com')', plus a bunch of home grown 'encryption' that was utterly ridiculous. I'm sure if anyone spent a good hour or so looking at some of the oodles of software they pre-install on laptops you can dig up some other juicy exploits.
1. http://webcache.googleusercontent.com/search?q=cache:http://... (sites down at the moment :/)
2. http://www.theregister.co.uk/2015/04/08/dell_update_security...
3. They literally just updated their home grown encryption/authentication code and made it clear that they didn't understand the issue at all.
Oh, and they obfuscated the binary for iron-clad maximum security.
That would be, if it were not for...
$ dig localhost.dell.com
; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> localhost.dell.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56836 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;localhost.dell.com. IN A
;; ANSWER SECTION: localhost.dell.com. 462 IN A 127.0.0.1
An attacker who can either abuse an already running local webserver (like Apache configured to listen to *:80) or start up a locally running webserver (using something like python's SimpleHTTPServer) can serve their content under a Dell subdomain.
This requires some sort of local filesystem privileges or potentially RCE, but if the original commenter is correct, this can be pivoted to SYSTEM RCE.
That doesn't suffice either, unless they also enforce HTTPS. Otherwise, any network you connect to can spoof DNS and load a fake dell.com page over http to break your security.
(Of course, even if they did require HTTPS, the attacker could serve up a fake dell.com HTTPS site signed with eDellRoot...)
And either way, they have no business even allowing an authentic dell.com page to execute arbitrary code on your system, either.
But nowadays it seems like not all keys are equal, and I'm under the impression that short of buying your own copy you can only reinstall the OEM, hacked-up version.
I've never tried though. I don't know if there is still a different version for OEM or VL windows like XP had different key types.
I performed a wipe/reinstall (with media created directly from a Microsoft download) and Windows 10 never asked me for a key after reinstalling it, and it reports as being activated.
Seems like they've moved away from requiring an OEM key in addition to the SLIC BIOS signature.
https://www.techdirt.com/articles/20150812/11395231925/lenov...
Once is normal, twice may be coincidence, thrice is enemy action. Let's hope for Dell that there won't be a third, and if there is that they spot it themselves before someone else does. And I'm not buying the line about 'improved customer service' even for a moment, you can't improve customer service by allowing anybody aware of this certificate to MITM any and all connections from these machines and even if that were the case it is just a little bit too convenient that such a mistake would also include the private key, which allows Dell to conveniently deny that they ever leaked the private key to anybody in particular (instead, they leaked it to the world at large).
Superfish was bad, this is in some ways just as bad or worse.
Now, Dell, can we please have a detailed technical explanation about why these two root certificates and their private keys were stashed on customers machines without their knowledge centering on specific functionality (as in what is that you could not do without these certificates and keys distributed) rather than some weasel worded techno babble about 'improved support'?
Also updated my corresponding blog post (links to cert and key there in case you're interested): https://blog.hboeck.de/archives/876-Superfish-2.0-Dangerous-...
http://www.theregister.co.uk/2015/11/25/dell_backdoor_part_t...
The other part is like, "You really did not see this coming?"
The worst part is that this was probably done for ridiculous reasons. If they had put the certificate on their systems to allow the NSA to spy on their customers (just as hypothetical example), planting such a certificate would probably be a reasonable approach. But in the case of Lenovo and Superfish, this was done to show f___ing advertisements to users, and I am certain in Dell's case their reason is not much better. And for that, they put their customers security at risk. For freaking advertisements and (Dell's claim, I think) making life slightly easier for their support staff.
Seriously, what were these guy thinking?
OTOH Dell used to bundle adware openly around 2007 and a lot of manufacturers still bundle badware/scareware. (Yes, I'm talking about McAfee here.)
Is this just incompetence, or is there some other reason that I'm failing to understand?
Exactly how Dell managed to distribute both private and public keys to this certificate is a wonder.
For example, a user wishing to use the Azure web services either supplies their own cert/public key to Azure, OR requests Azure to generate a unique cert/key, and supplies the private key to you. Now, obviously, someone using Azure APIs doesn't install this key into your root store.
And that's the second "WTF?" - why install this as a Trusted Root cert, when your application could just hold it locally, and reference it?
(The first WTF being distributing a common private key - rendering the point of encryption useless.)
And the best part - no bogus certs!
This is almost exactly what I've done to set up my machine: http://ubuntuforums.org/showthread.php?t=2301071&p=13382949#... . This thread claimed that the kernel v4.3 fixed this issue, but it still happens for me - I was going to wait until the next 4.4 RC to give it another whirl.
If your BIOS supports it choose 'sleep' rather than 'hibernate' for suspend/resume. It will be a bit slower but there is far less OS dependent magic going on under the hood.
...
The only problem I've had is that suspend/resume (i.e. closing the lid) causes a kernel panic
I think it's time to apply a higher standard to "runs like a dream."
It appears that hardware vendors cannot make enough money merely selling hardware, and so they sell access, data and advertising to third parties (at least Superfish was in that area).
Being able to mod the software on your car is (I think) recently allowed (by the Librarian of Congress?). But it can be taken away at any revisiting event. I can see the day coming when it will be illegal to wipe a machine, because circumventing.
Of something other than Windows, since Windows will automatically run binaries provided by the firmware in the "Windows Platform Binary Table", which hardware vendors now use to reinstall their malware into a fresh Windows install.
(Of course, if you don't trust the firmware, it can do any number of other terrible things to you as well. And firmware from major hardware vendors has messed with Windows partitions to reinstall malware even without the WPBT.)
http://www.extremetech.com/mobile/197005-new-apple-malware-i...
http://arstechnica.com/information-technology/2015/08/lenovo...
This isn't an inherently bad idea – it works to provide critical drivers which you might need to get online, for example – but it really underscores how much depends on the OEM being more diligent than they've been in the past.
I disagree that it isn't an inherently bad idea.
How else do you provide any drivers needed to get online? If you store them on the disk, malware or hardware failure will break it. If you use external media, it's an expense to OEMs and something the user will lose before they need it, not to mention the growing number of tablets & other devices which have very limited connectivity options.
I would be the first to say that Lenovo abused this and deserves all of the backlash they got but Microsoft created this mechanism to solve a real problem (“Get closer to an Apple-level experience”) which millions of people encounter at some point.
Unfortunately, when you cannot trust the hardware vendor the only answer is not to buy from them. There is no level of making the user experience worse or removing features which will prevent them from causing problems if they choose.
http://geer.tinho.net/geer.blackhat.6viii14.txt
https://www.google.com/webhp?sourceid=chrome-instant&ion=1&e...
It hasn't really taken off, so it appears that people don't highly value such safety.
Edit: I'm not defending Dell in any way, but if they're watching youtube and browsing facebook, they'll probably be just fine.
neither is something you'd want, even if the machine itself is not used for anything critical.
Email accounts are interesting for spammers. Reason enough to want working https.
> Nevertheless, because both eDellRoot and DSDTestProvider are installed in the Windows root store for certificate authorities together with their private keys, they can be used by attackers to generate rogue certificates for any website that would be accepted on the affected Dell systems.
It's not the certificate that's the problem. It's the installation of the private keys along with the certificate.
No, that just makes it much worse. Your system provider has no business installing a root certificate even without a private key, because that still gives them the ability to spoof any website. And even if you trust them not to do so, do you trust everyone who could break their security?