1.0.1
This commit is contained in:
parent
35b4ae1d7f
commit
6db1bb9c7e
SSH key fingerprint:
SHA256:KiRjUay5C9i6objsEOIycygBHn54pDBB3Lj7fyJ0Elw
|
|
@ -1,5 +1,18 @@
|
|||
# home
|
||||
|
||||
> I'm looking for a job in IT (Node.js, DevOps, sysadmin, back-end) remote or in Ardèche.
|
||||
|
||||
> - I have 6 years of experience in the JavaScript and TypeScript ecosystems;
|
||||
> - I've used various Linux distros for 5 (Ubuntu-based, Arch and now NixOS);
|
||||
> - I'm interested in minimalism, efficiency and security (especially supply chain attacks).
|
||||
|
||||
> If you're looking to hire someone or need someone to make and manage:
|
||||
> - a website;
|
||||
> - a Discord or Telegram bot;
|
||||
> - anything else really! Automation, systems administrations, etc.
|
||||
|
||||
> Feel free to send me an email at (my username)@proton.me - Thanks!
|
||||
|
||||
this is my personal website.
|
||||
|
||||
*This is a work in progress.*
|
||||
|
|
@ -8,15 +21,14 @@ this is my personal website.
|
|||
- No crazy CSS
|
||||
- No videos
|
||||
- No bullshit
|
||||
- Just my words on the screen, so you better read them.
|
||||
|
||||
## me
|
||||
|
||||
Tasia `(they/them)`
|
||||
|
||||
I'm a Node.js TypeScript developer, specialized in DevOps, backend development and supply chain security.
|
||||
I'm a Node.js TypeScript developer, specialized in DevOps, back-end development and supply chain security.
|
||||
|
||||
Assigned French at birth - UTC+0200
|
||||
Assigned French at birth, currently living in the tech blog archipelago - UTC+0200
|
||||
|
||||
I speak English and French. Feel free to provide constructive criticism if needed.
|
||||
|
||||
|
|
@ -54,17 +66,26 @@ Git
|
|||
|
||||
## how to support me
|
||||
|
||||
If you like my posts, please consider supporting me on [Liberapay](https://liberapay.com/tasiaiso) or [Ko-fi](https://ko-fi.com/tasiaiso). Thank you !
|
||||
If you like my posts, please consider supporting me on [Liberapay](https://liberapay.com/tasiaiso) or [Ko-fi](https://ko-fi.com/tasiaiso). Thank you!
|
||||
|
||||
## todo
|
||||
|
||||
- rss feed
|
||||
- offline archives (.zim)
|
||||
- gemini capsule
|
||||
|
||||
## changelog
|
||||
|
||||
### v1.0.1 (2024-05-18)
|
||||
|
||||
- add links to my git accounts, ko-fi and liberapay
|
||||
- add link to the apioform memetic page
|
||||
- this is now an actual website
|
||||
- fix wording
|
||||
- add legal stuff at the bottom of the page
|
||||
- now for hire
|
||||
|
||||
### 2024-05-09
|
||||
### v1.0.0 (2024-05-09)
|
||||
|
||||
- fixed url paths bugs
|
||||
- gruvbox theme
|
||||
|
|
|
|||
|
|
@ -3,29 +3,32 @@ date: 2024-05-08
|
|||
draft: true
|
||||
---
|
||||
|
||||
# curl | bash
|
||||
|
||||
<!-- Current: paper or tech report -->
|
||||
<!-- Wanted: discussion between 2 colleagues or friends -->
|
||||
# curl | bash DONE
|
||||
|
||||
In April of 2024 I wrote a post on Fedi explaining that using `curl | bash` was not a security risk.
|
||||
A bit later, I debated on the same subject on a Matrix channel.
|
||||
<!-- The other parties involved caused me to do some further research on the subject and led me to review my opinion. -->
|
||||
TODO
|
||||
As you could imagine, it turns out that the answer actually is, "it depends".
|
||||
<!-- discuss on ? -->
|
||||
A bit later, I discussed on the same topic in a Matrix channel.
|
||||
The people involved showed me how it was actually a bit risky to use `curl | bash`.
|
||||
This is what caused me to do research on the topic and write this post.
|
||||
|
||||
But is it actually dangerous ?
|
||||
Is the cake a lie ?
|
||||
Well, as you could probably imagine, it turns out that the answer actually is, "it depends".
|
||||
|
||||
I based my original argument on the fact that you ultimately have to trust the person that provides you the code, which is true, but *incomplete*.
|
||||
I'll present to you the actual dangers of using `curl | bash`, and how we can mitigate them.
|
||||
|
||||
<!-- Here are the results of my reseach. At the end I will present a simple way we can use `curl | bash` safely. -->
|
||||
TODO
|
||||
> TL;DR: If you're here because you just want to download software, go for it. You're *probably* going to be just fine. If you're interested in learning or want to implement a `curl | bash` script however, please read the rest.
|
||||
|
||||
TL;DR: If you're here because you just want to download software, go for it. You're *probably* going to be just fine. If you're interested in learning or want to implement a `curl | bash` script however, please read the rest.
|
||||
## Terminology DONE
|
||||
|
||||
## Terminology
|
||||
- Software artifact: Stuff that comes out of your repository: code, shell scripts, binaries, etc. In this blog post I will focus on the shell script that installs your binaries more than anything else.
|
||||
|
||||
Software artifact: Stuff that comes out of your repository: code, shell scripts, binaries, etc. In this blog post I will focus on the shell script that installs your binaries more than anything else.
|
||||
- Signing authority: a server that hosts the artifact's cryptographic hash or signature.
|
||||
|
||||
## Surface attack
|
||||
- Artifact provider: a server that serves the artifact directly to us.
|
||||
|
||||
## Surface attack DONE
|
||||
|
||||
We can establish a simplified supply chain for a software artifact:
|
||||
|
||||
|
|
@ -50,7 +53,7 @@ For the purpose of this post however, the attack vectors (1), (2) and (5) are ou
|
|||
|
||||
Precisely. *Most of the time*.
|
||||
|
||||
## An example script
|
||||
## An example script DONE
|
||||
|
||||
```bash
|
||||
curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix | sh -s -- install
|
||||
|
|
@ -75,10 +78,13 @@ At first glance, this seeems like a secure way to run the installer.
|
|||
However, this script does't check that the script you're downloading is what it should be.
|
||||
If the server is compromised in some way, we could be downloading malware instead.
|
||||
|
||||
We can mitigate this risk by using a method used by most package managers, which is using 2 different servers with different functions: one that hosts the artifact's cryptographic hash or signature (here called *signing authority*), and another one that serves the artifact directly to us (here called *artifact provider*).
|
||||
We can mitigate this risk by using a method used by most package managers, which is using 2 different servers with different functions:
|
||||
- One that hosts the artifact's cryptographic hash or signature (here called *signing authority*);
|
||||
- And another one that serves the artifact directly to us (here called *artifact provider*).
|
||||
|
||||
This way, if either server is compromised, the software that's served to the client will not be verified and therefore not run.
|
||||
|
||||
We can reduce the risk of getting both machines compromised at once by:
|
||||
We can drastically reduce the risk of getting both machines compromised at once by:
|
||||
|
||||
- Having them be controlled by 2 different entities (companies and/or persons);
|
||||
- Having them be managed by 2 different systems administrators;
|
||||
|
|
@ -114,6 +120,14 @@ An example infrastructure would look like this:
|
|||
- HTTP server: Nginx
|
||||
- Domain: `determinate.systems`
|
||||
|
||||
|
||||
- Signing authority (alternative)
|
||||
- Managed by gitea.com
|
||||
<!-- - Hosted by DigitalOcean (Germany) -->
|
||||
<!-- - OS: NixOS -->
|
||||
<!-- - HTTP server: Nginx -->
|
||||
- Domain: `gitea.com`
|
||||
|
||||
- Artifact provider
|
||||
- Managed by Jane Poe
|
||||
- Hosted by a worldwide CDN (Hetzner) TODO
|
||||
|
|
@ -125,16 +139,13 @@ An example infrastructure would look like this:
|
|||
|
||||
Now, compromising this part of the supply chain has become extremely hard. The attacker will either:
|
||||
|
||||
- Need technical competency (TODO) in NixOS, RHEL, Nginx and Apache, as well as compromising an entire CDN (TODO);
|
||||
- Need technical knowledge in NixOS, RHEL, Nginx and Apache, as well as compromising an entire CDN (TODO);
|
||||
- Compromise both of the sysadmin's machines through social engineering;
|
||||
<!-- - Potentially, compromise the reverse proxy; -->
|
||||
- ...
|
||||
- Use several of the methods listed above.
|
||||
|
||||
Now, it would be a lot more feasible to attack another part of the supply chain, which is a subject for another blog post.
|
||||
|
||||
<!-- (more text) -->
|
||||
|
||||
## Implementing curl | bash safely
|
||||
|
||||
> You've spent so much time explaining that `curl | bash` is insecure, why would we bother making a secure version of it ?
|
||||
|
|
@ -151,9 +162,16 @@ EXPECTED='caa42ef74ba42d3d097bfcd7c718cd22ca807c1116ce1f86b00ecce9337858d7 -'
|
|||
ACTUAL=$(echo $CURL | sha256sum)
|
||||
|
||||
if [ "$EXPECTED" == "$ACTUAL" ]; then
|
||||
echo "Good checksum"
|
||||
echo $CURL | bash
|
||||
else
|
||||
echo "Checksum mismatch"
|
||||
fi
|
||||
```
|
||||
|
||||
### Updating the script
|
||||
|
||||
When a new artifact is available, the artifact provider has to start hosting it.
|
||||
Then, the signing authority needs to get the artifact's hash (dirctly from the source) and then update the way the script is displayed (git repo or website).
|
||||
|
||||
Preferably, the artifact provided should include the artifact's version in it's URL and keep hosting non-vulnerable versions, that way the script will still work before the signing authority finishes its work, and after another update is released.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
{
|
||||
"name": "tilde",
|
||||
"version": "0.0.0",
|
||||
"description": "My personal website",
|
||||
"version": "1.0.1",
|
||||
"scripts": {
|
||||
"format": "npm run prettier && npm run markdown",
|
||||
"prettier": "prettier --cache --write --check .",
|
||||
|
|
|
|||
Loading…
Reference in a new issue