| 15 Oct 2024 |
 commiterate | * at least that's my understanding and what that security finding outlines, but the existing EIC AuthorizedKeysCommand Bash scripts aren't the easiest to read | 06:45:31 |
| commiterate | even if they did encrypt the keys with the cert, it would still be vulnerable to MITM since it can just replace all IMDS responses | 06:46:28 |
 Arian | I think the trick here is maybe to point to flakehub? | 09:53:30 |
| Arian | Note there's a determinate systems discord. I'd suggest discussing a bit there | 09:53:50 |
| Arian | P.S. MacOS is such a pain on EC2 holy moly | 09:54:18 |
| Arian | You have to install NixOS on the (unsupported) instance store | 09:54:43 |
| Arian | * You have to install Nix on the (unsupported) instance store | 09:54:51 |
| Arian | and I have had several occasions where the instance store is just... broken | 09:55:02 |
| Arian | Installing nix on the EBS volume isn't possible automatically. You need to do a GUI step | 09:55:20 |
| Arian | I've wasted days and hours of my life on this at work | 09:55:37 |
| Arian | and any time you make a mistake; AWS will take around 3-8 hours to reboot the machine | 09:55:49 |
| Arian | it's the most frustrating, painful product I have ever used | 09:56:03 |
| Arian | no you're not as you dont have control over amazon's certificates | 10:07:56 |
| Arian | that's why you cant spoof EIC keys (after they fixed the vuln in the post) | 10:08:09 |
| Arian | but the root key is just plopped on disk by cloud-init without any checks | 10:08:22 |
| Arian | I guess you're "protected" because cloud-init does this on first boot and then leaves it alone | 10:08:41 |
| Arian | But my problem is you want to replace with with a ProxyCommand which makes it a continuous risk. EIC has hardening agaisnt this by signing the payloads with an AWS Cert. but the main SSH key doesnt have this protection | 10:09:18 |
| Arian | The fact that the key is written to disk only once at bootup is kind of a security feature in this way | 10:09:40 |
| Arian | as later IMDS spoofing doesn't lead people to be able to change the key | 10:09:53 |
| Arian | EIC doesn't have this issue due to the Certificate being in play and not being able to spoof the IMDS payload | 10:10:15 |
| Arian | * that's why you cant spoof EIC keys (after they fixed the vuln of incorrect cert validation in the post. which they seem they have) | 10:10:37 |
| Arian | I mean AuthorizedKeysCommand when I wrote ProxyCommand | 10:11:58 |
| commiterate | hmm assuming the trusted root CAs are baked onto the host and the attacker can only spoof off-instance stuff (e.g. IMDS), the attacker can just only inject responses in the get SSH keys endpoint.
Basically, as long as the certs from the cert endpoint are valid, it just blindly trusts the SSH keys endpoint response. | 17:24:34 |
| commiterate | Unless this line is actually doing some kind of validation my thing is missing: https://github.com/aws/aws-ec2-instance-connect-config/blob/551c73e8ec1f5ade4c8b1f52cf616e75b47879b4/src/bin/eic_parse_authorized_keys#L307 | 17:25:09 |
| commiterate | If it is then I need to fix that and probably also drop the EC2 Key Pair handling | 17:25:44 |
| commiterate | Yeah installing Nix on the bare instance doesn't work due to macOS's "security" feature that requires UI access to approve access | 17:29:07 |
| commiterate | it works if you do a nested VM though (e.g. Tart VM) | 17:29:16 |
| commiterate | however I think they removed the need for full disk access as of v0.27.0
https://github.com/DeterminateSystems/nix-installer/pull/1210 | 17:30:04 |
| commiterate | * however I think they removed the need for full disk access as of v0.27.0
https://github.com/DeterminateSystems/nix-installer/releases/tag/v0.27.0
https://github.com/DeterminateSystems/nix-installer/pull/1210
| 17:30:26 |
| commiterate | unless that's what you mean by the instance store (local hard disk) | 18:31:19 |
