| 15 Oct 2024 |
 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 |
| Arian | Even when you keep the host reservation changing the AMI takes a few hours though ;/ | 18:33:02 |
| commiterate | but eventually you must go through a scrubbing cycle if you want updated firmware | 18:33:04 |
| Arian | Ah didn't know that | 18:33:08 |
| commiterate | I also talked with the ASG PMs and they're looking at root volume replacement for instance refresh | 18:33:28 |
| commiterate | but yeah due to Apple's EULA, Mac instances are the most inelastic instances of all time | 18:33:42 |
| commiterate | since elasticity requires it to be fast to take from and return to the free capacity pool | 18:33:58 |
