News for hackers. Stuff that matters.
Re:The sad state of sysadmin in the age of containers (2015) by GordonS on Monday December 09, 2019 @10:01AM (#21743176)
Sorry, I don't follow.

If I have a makefile, I can inspect it and see what it does.

If I have shell script (or indeed a makefile!) that calls `curl | bash`, I can inspect that shell script and see the URL that is used with curl, and then inspect the contents that the URL returns.

Re:The sad state of sysadmin in the age of containers (2015) by Avamander on Monday December 09, 2019 @10:31AM (#21743427)
You can't see what comes from `curl | bash` before you actually pipe it to bash, click the link and read the article please.
Re:The sad state of sysadmin in the age of containers (2015) by GordonS on Monday December 09, 2019 @10:56AM (#21743672)
OK, I see - in theory, an attacker in control of the backend could write a handler that could craft a bash script that writes different content when `curl | bash` is used.

TBH, while I take your point, I do think it's a little disingenuous of you to claim that "You don't have the opportunity" to inspect the script prior to executing it - you ordinarily will, but can't in the unlikely event of an attack like the article describes, which would require an attacker to be in full control of the web server.

Off the top of my head, this could be mitigated in a couple of ways:

1. Hash a known-good script and check the hash matches prior to executing (this does however mean that you need to update the hash every time the remote script is changed)

2. Use curl to download the remote script to a local file first, and provide the opportunity to inspect it prior to piping it into bash

Re:The sad state of sysadmin in the age of containers (2015) by Avamander on Monday December 09, 2019 @12:37PM (#21744549)
> Off the top of my head, this could be mitigated in a couple of ways:

Or the third opportunity of not piping curl to bash and using a proper repository that has all these integrity and authenticity checks built-in.