Practical /dev/TCP in the HTTPS Era | Hacker News Reader

TCP in the HTTPS Era

blog.pkgforge.dev

15 pointsazathothas10 comments

They are solving the problem that should not have existed. Simply include the binaries into the installer.

Also I wouldn't run suspicious third-party binary installer anyway. If it is not in the official repositories, it doesn't get installed, because I have no time to figure out if it is a safe software or not, what it will do to my system, does it include telemetry, and I have no time to build a sandbox.

> Checksums can be verified after download

They can be but _are_ they? Does their installer actually verify the checksum?

Because if it's designed for systems so minimal/broken they can't do normal HTTPS, I kinda doubt it...

Update: Checked the script, and not only does their official installer not verify the download at all - it immediately executes it.

Therefore, it's trivially possible to RCE someone running this script you are MITMing - block all the HTTPS connections, and then replace the binary in the HTTP connection with malware.

Frankly this vulnerability is so obvious and so negligent that I would never use this tool, which is unfortunate as it sounds like a cool idea.

I feel you’ve missed the point. They’re not trying to use https, they can’t, they are downloading tools that only exist online as https links from a legacy system that only supports http. They simply couldn’t download jack shit and came up with a way to do it.

If you can get the insecure bash script onto the system you can also get a bundle with a more secure downloader (or even better, the binaries to be installed) on the system in the same way. Even if you are limited to copy and pasting ASCII text, shell archives are a thing as are a myriad of other possible solutions that do not involve downloading a binary over plain HTTP without any verification.

I think you've missed the point. Even on systems where HTTPS is normally available an attacker in the middle can trivially cause their official installer script to download and run malware by just blocking a few HTTPS connections.

This is the DEFAULT fallback behavior in their installer - not something that only happens on legacy machines.

If I install a project from GitHub on the airport WiFi I'm assuming that the authors know what they're doing and I'm not potentially getting silently MITMed. And when I find out the authors don't know what they're doing to this extreme extent, I note down to never use their project.

I think /dev/tcp is bash specific. The actual socket is at /proc/net/{tcp,udp}

I don't fully understand how this works

Does bash "overlay" /dev/tcp over the filesystem? If the kernel created an actual /dev/tcp file, would bash be unable to access it or...?

Why not https://github.com/gh2o/bash_tls ?

(requires bc, doesn't validate cert chain)

Since /dev/tcp doesn't work with https, complex redirect chains or even dns sometimes, almost all mentions of it in the hacking articles online are not that useful

We had to make soar's install script be able to work anywhere, In the article you get to know about http://http.pkgforge.dev & how you can use it to make /dev/tcp finally practical & useful in the modern https age

Reply on news.ycombinator.com