Hacker News Reader

Comment by jeromenerf | Hacker News Reader

As if supply chain attacks, ransomwares and all the zero click wormable vulnerabilities we receive every other day were not enough.

I like gardening my small personal home server, services and backups but there is no reason debian packages could not be subject to the same supply chain "evil maid" or upstream "evil new maintainer". Everything being done in the open and reviewed makes it less probable, but not impossible. Sigh.

As a company, "risk" is mostly insurance. As an individual, it’s anxiety.

View on HN

> but there is no reason debian packages could not be subject to the same supply chain "evil maid" or upstream "evil new maintainer"

I'm always suspicious of the number of blogspam generic linux help advice sites that get you to install some random ppa complete with a nifty little code snippet that automatically installs certs and updates your sources.list! How handy!

haha

I love using sites like that for my personal computer/projects, but I never copy and paste code snippets or install PPAs on work machines or computers with magic internet money on them

But do you put them on the same networks?

`curl -o- https://example.com/install-harmless-utility.sh | sh`

Related: Detecting the use of "curl | bash" server side

https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

You can make it so that the server returns benevolent looking code when auditing it with just "curl URL", but return malware when curl is directly piped to bash.

I.e. the correct and expected method for installing the latest version of Node.js as a package on Debian. (Except you're supposed to run it as root.)

And then there is Raspberry Pi, which recently installed a PPA and gpg key in a kernel post-install hook...

See also: the Raspberry Pi Foundation's decision to slip a Microsoft repository into Raspberry Pi OS without so much as a by-your-leave.

Yes, that was very sad. I really didn't think they would sink so low. I've always just used Raspbian on my Pi's without giving it much thought. Remotely activated Microsoft spyware was nowhere on my radar.

Keep in mind that "Raspberry Pi OS" isn't Raspbian [0], which the Raspberry Pi Foundation seems to want to memory-hole.

[0] https://www.raspbian.org/

I actually discovered this myself a few days ago. Quite surprising... I assume it's safe to remove?

Every package manage is a horrible vulnerability (along with being a useful tool). When you package a webapp: - Debian - Maven - NPM - On the dev machines: Brew, Chrome extensions...

Aren’t they very easy to exploit, for a mildly dedicated actor? I don’t see any decent solution to this. Any line could contain a wget | bash...

Deno addresses this problem by not giving module’s permission by default I think

No, that's per process. Not very useful and can already be done with selinux etc

You can always just accept the risk.

Or you can not, and work to control your supply chain. Host the artifacts yourself and choose carefully which ones you use.

There is no magic bullet, just boring and painful risk-control processes. But they do help.

The future is sandboxed apps with flatpak. Who cares if Spotify is malware when it can't access anything.

Wayland, SELinux, Flatpak, PipeWire. These will save us or at least reduce the problem of evil maintainers.

This model has been tried and proven for over a decade on mobile. What we call malware on mobile is simply the app doing bad things with what you enter in to the app itself and not the desktop class "steals all your data and then encrypts it"

Encouraging people to run random binaries from strangers is probably worse.

Except that often the sandboxed apps are also a nuisance to work with. They don't pick up themes from the desktop, keyboard shortcuts don't work anymore (if you have e.g. set some global shortcuts), exchanging data with other programs can be a pain as well...

They are only a nuisance right now. Almost all of the issues you encounter are minor implementation problems and not fundamental issues with sandboxing or flatpak. Things are getting better.

I'd like to agree, but as always, the problem is the security/ease-of-use tradeoff. SELinux can be a nightmare to deal with, particularly if you're compiling an application from source and you want to take advantage of it (and even if you aren't, it can lead to mysterious failures). I managed to make Asterisk work in SELinux, until I tried to add a Bluetooth channel module to the mix. At that point, I was backed into a corner; there just didn't seem to be a way for me to let Asterisk access Bluetooth with SELinux running.

> The future is sandboxed apps with flatpak.

If the sandbox is configured by the same person or organization that writes the code there's no improvement in trust.

That's why package maintainers have a role in Linux distributions.

No. The solution to the problem of evil m̶a̶i̶n̶t̶a̶i̶n̶e̶r̶s independent software vendors is maintainers.

See http://kmkeen.com/maintainers-matter/

Maintainers do not review code. At best they test it to make sure it works. The Debian maintainers let in a timebomb borderline malware in to the xscreensaver package without them noticing it.

Maintainers do not have the time or ability to check for even intentional malware let alone security bugs.

So you count on SELinux. Who maintains SELinux policies for you, so that it knows what is allowed to a program and what isn't? It's people just like other software maintainets.

There is no way around having to trust somebody else.

> Aren’t they very easy to exploit, for a mildly dedicated actor?

Debian does very extensive vetting of the contents of packages - and of the volunteers who get to become Debian Developers.

Debian has been working towards reproducible builds [1].

What this means is that the package maintainer is unable to alter the binary/package outside of the publicly available sources.

In the case of the web extension, the maintainer could build whatever software they wanted, not necessarily the source you see on github or elsewhere. A reproducible build system would prevent this type of attack (that I'm talking about here).

1: https://wiki.debian.org/ReproducibleBuilds

Traditionally people dealt with this by applying updates manually. Of course, that had it's own problems.

The only solution is to roll your own everything. Happy coding! :)

Reply on news.ycombinator.com