When you install un-signed code into your editor, it might as well be malware | Hacker News Reader

When you install un-signed code into your editor, it might as well be malware

glyph.twistedmatrix.com

31 pointslvh10 comments

The point the author is making is that at least your third-party plugins should be protected from tampering in transit.

Don't think this is only restricted to state-level actors. With even commercial routers like Cisco and Juniper shipping with backdoors, and of course personal routers with vulnerabilities all over the place, it's not an especially heavy lift to take over a bunch of last-mile routers.

There are tons of these unprotected attack vectors, and the author is right that we need to start rooting each one out. It all starts with your OS's keys (or below your OS, in UEFI!)

This is probably even more of an issue for Linux distros that serve their initial install CD's (or bittorrent links) over HTTP. That's an easy vector for a third party to slip in a replacement CD/DVD and checksums, or even just slipstream in the changes without bothering with the checksums, since probably most people never check the digests and if they did and they didn't match, they'd just figure it was a bad download and never suspect a thing.

When people say "oh, no one cares about me", it's simply not true. That's why there's > million viruses out there. That's why ransomware exist. Oh, yes. they care.

Was hoping to see a mention of Sublime Text...because I most definitely haven't taken the time to audit the packages I install, nor do I even really have much insight to how the central package repository is maintained. I did a couple of Google searches for "sublime text package malware"/security/sandbox and didn't see articles specific to the topic.

Sublime Packages are just Python modules. I don't believe there is any sandboxing. At the very least I know that you can use popen and run arbitrary programs.

The default list is here: https://github.com/wbond/package_control_channel

Anybody can pull request, maintainers tend to review the package briefly.

I've published a sublime package, when I PR'd the guy actually looked at my code pretty thoroughly and had some helpful advice. It was a really good open source experience.

Package Control protects package information in transit using TLS, verifies TLS hostnames, and requires that package metadata source URLs are HTTPS. The source URLs for package information are all tracked in an open source repo on GitHub.

For the past couple of years a volunteer who goes by the handle FichteFoll does most of the review process, and I tend to fill in when he is unavailable. We check for common packaging issues, areas of confusion for users and sometimes even code suggestions.

In terms of hosting, it is all done via a private server that I run, configured to only allow TLS 1.0+ connections. I am the only user with access to the box.

All of this is to say that Package Control generally tries to vet packages to get them info the default channel, and then protects them in transport. However, packages are in no way audited, and could (obviously) be subverted by anyone with access to the original source code repo/hosting.

Someone really should take the time to sort this out … I guess that I'm someone.

If a secure server is compromised, then none of this matters. You have to trust someone at some point.

There's a difference between bowing to practicality / trusting someone, and trusting everyone in the chain that gets the packets from the server to your device.

Yes, precisely.

Attackers might target the link between you and ISP, which isn't secured to an adequate degree. Servers ought to be harder to reach, but lack of hygiene displayed by offering only unauthenticated http downloads in 2015 means that even if people running those servers switched to https we know they are probably incapable of securing them. In a way it is better http stays as a red flag.

Reply on news.ycombinator.com