| 15 Oct 2024 |
 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 |
| commiterate | as for MacOS pains, you can actually blame Apple's EULA and security features for that | 18:31:33 |
| commiterate | Apple requires machines to be held for 24 hours minimum by a single tenant, hence why EC2 requires a dedicated host reservation for 24 hours minimum | 18:32:10 |
| commiterate | and the long instance scrubbing is due to the processes Apple needs for firmware and software updates | 18:32:36 |
| commiterate | you can skip scrubbing from instance stop and terminate with a root volume replacement though | 18:32:47 |
