Hacker News Reader

Comment by rahuldottech | Hacker News Reader

I know for a fact that HP distributes software and drivers over FTP files that they link to on their website.

FTP isn't used much anymore, but IMO/IME, it's still nice to have for those rare times when you come across a file that you need to download and it's served over FTP.

View on HN

The FTP link can still use xdg-open or whatever the local equivalent is to spawn the user's FTP app and connect to that URL. I think that's how most URLs with unsupported (by the browser) protocols are handled nowadays anyway.

What average user has a ftp app installed?

On desktop, almost everyone. Windows Explorer speaks FTP, MacOS finder speaks FTP, I think all major Linux desktop file managers do.

(Of course there's no guarantee they'll keep support for it, based on similar arguments)

Agreed completely, but Google don't care about "nice to have"; if it doesn't ultimately make them money, they couldn't care in the slightest, yet people here will often applaud this attitude as if it were progress.

It is progress though. FTP is insecure, and worse still it breaks the security model of HTTPS (see article for more info). Plus additional code paths could be sources of bugs/exploits, particularly old/rarely updated ones.

Moreover it's not implausible (I'd wager it's actually likely) that HP and other websites still relying on FTP will be pressured to actually fix their sites and switch to something more secure once Chrome drops support.

They'll switch to links which require proper cookies and referers to be set making them impossible to wget. As they always do.

Now that's so much better and more secure!

You can justify removing anything with "less code paths." I hate that argument. Don't care about FTP being insecure either. Google's just being hostile to the open web as usual and getting the usual applause.

> Don't care about FTP being insecure either.

Well, then its probably a good thing that you aren't a browser developer.

"Insecure" is the new "is a witch". Too coarse to be used as a valid argument.

Alright. It's not encrypted and not origin-verifiable then. I think we all knew that though... anyway it should be abundantly clear at this point that no one should be using protocols that can trivially be MITM'ed to access anything over the internet.

Or involves the plain text transmission of passwords by design.

>...anyway it should be abundantly clear at this point that no one should be using protocols that can trivially be MITM'ed to access anything over the internet.

This is a specious argument because HTTP/HTTPS is regularly (and legally) MITM'ed[0, 1].

If we shouldn't use anything that can be MITM'ed, shouldn't we just shut down the internet? Wouldn't that stop MITM attacks permanently-like? What about phones? Or letters? Or even talking? Where does this scare-tactic of the MITM "boogey-man" end (for you)?

[0] - https://www.symantec.com/products/proxy-sg-and-advanced-secu...

[1] - https://www.occrp.org/en/daily/10431-kazakh-officials-delay-...

So HP is now on notice to fix that. It's not happening until 2020Q2, so that gives them plenty of time.

HP has nothing broken to fix.

They do though: 1) They are distributing executables to their users over a MITM-able channel. That is not acceptable. 2) A bunch of their users will have a much tougher time downloading their drivers when Chrome stops supporting FTP.

The drivers are cryptographically signed so the MitM-able channel is absolutely irrelevant.

The users will just have to stop using Chrome. Supporting Google software is always just a pain in the ass (and I've gotta know as developer of Android apps)

Actually a MitMable channel makes the "it's just cryptographically signed" thing into a heap more trouble.

Bad guys can now replay old drivers, which were cryptographically signed, as the latest drivers.

So then you need to build cryptographically signed metadata structures, so that you can tell that these were the latest drivers as of some recent moment. You need to have this idea of freshness, and a mechanism to ensure it's kept up to date.

There's a period of several years where Linux distros split into two camps: One camp used HTTPS and so it was fine, and the other camp would have a bug where bad guys could cause something unexpected with a MitM attack, and they'd patch it, and then some new bug would be found, and they'd patch that and repeat...

It isn't _impossible_ to get there, Fedora can safely update over insecure protocols today as far as we know. Or, you can skip all that noise and just do HTTPS as RHEL itself had been doing for many years by that point.

This.

I've seen a lot of naive designs where signed data is downloaded via an unsigned control channel. At the very least, they are vulnerable to replay attacks. Beyond that, it enables more selective blocking/filtering to prevent clients from accessing specific data.

Let's not forget the lost "confidentiality" aspect of TLS either. Your request for HP_Drivers_2019_Update.exe is now broadcasting to the Internet: "Hey I'm running a vulnerable, unpatched device! Last chance to hack me!"

Drivers have versions in them, it's part of the driver itself and therefor cryptographically signed.

People like to cargo cult TLS as if it's the only option but it's really not, even debian doesn't use https (and gets quite a bit of backlash despite understanding very well their security model): https://whydoesaptnotusehttps.com/

The CVE mentioned at the beginning of the page you linked is one of the reasons why TLS is still nice to have, security-wise. Saying that TLS is the only option may be an overstatement, but saying that it definitely provides some benefits is not.

I'm not sure if you remember, but soon after that site hit the HN frontpage several CVEs where discovered in the way APT uses http that would have been mitigated if they used HTTPS.

https://gist.github.com/roycewilliams/cf7fce5777d47a8b222655...

Specifically, for drivers: https://lifars.com/2016/01/significant-security-flaw-discove...

Sure. You can't easily replace the driver with a self-written, malicious driver without exploiting some sort of deep Windows vulnerability. However, executable code can perform all manner of mischief without being a driver. Anyway, I don't think HP's TechOps underachievement is going to convince anyone to switch their browser. Instead, HP'll just have someone spend a week or two setting up an HTTPS file server and everyone will move on. It's better for their users and it's less effort than trying to have a battle to defend FTP of all things.

You can repackage the real driver together with your own (signed by you) trojan in a new (signed by you) installer.

How many users do you think check which entity signed an executable?

Same for supermicro - your drivers/firmware is on ftp

I couldn't find an FTP link for drivers/firmware on Supermicro (or HP). I only tried a few random products out of curiosity, but: are you sure? :)

Reply on news.ycombinator.com