Notices by Klaus Frank (agowa338@chaos.social)

@pid_eins @siosm

Lol, so now we should boot the compromised system again? You know that normal security practice is to wipe it before it lays eggs right?

Also if just rebooting was enough then we wouldn't literally need to do the factory reset...

@pid_eins @siosm

But why should I need to break the trustchain as an attacker wanting to exfiltrate secrets? I can do most of that as regular user. Therefore we never turn compromised systems back on once we know they're compromised.
That just gives attackers opportunities to have their scripts ran. Also there is still the risk of exploits.

It is just bad security practice to boot from a compromised disk. At most you'd attach it to an air gapped offline system to do analysis and such...

@pid_eins @siosm

to be frank I just don't want to think about how trustworthy it is and just dump the entire state into the trash.

You're making things way more complicated than they should have to be.
Now one actually needs to check if the chain of trust is still valid or if the attacker was able to just use e.g. some exploit to disable secure boot (or it may not even have been enabled to begin with) or re-signed parts of the trustchain using and so on...

@pid_eins @siosm

Oh, I think I see where the misunderstanding lays. How does your UKI get signed? I always forget that you develop systemd with a focus on distros like Fedora and such.

On ArchLinux the keys to sign it generally also lay on the system itself it gets signed locally...

@pid_eins @siosm
Yea, that's why clearly defining the thread vector as someone in another post asked you about is so important.

I think I by now understand that you're targeting this as a feature for system integrators selling devices and not to everyone that installed Linux on some random device.

Because then the question of how to get your kernel signed automatically after updating or after you recompiled it locally doesn't even arise to begin with...

@pid_eins @siosm
kinda true, however why would I need a dedicated build system for building something tailored to a single notebook. Guess that systemd feature is just simply not for me then.

I'm kinda looking forward to seeing how this feature gets used in the wild (if at all) and if it is actually going to be provided in a secure way that doesn't just leave it open to be bypassed or compromised by attackers (e.g. them resigning and enrolling their keys or an unprotected script or something)

@bluca @pid_eins @siosm
Ok, but I have 192 cpu cores here right next to me. Also that may be something for distros to do I think it may be a bit unreasonable to setup something like mkosi for everyone that wants to have a slightly differently built kernel.

Also I don't see how using someone elses keys should be more secure than using ones that only work for a single device and are not available anywhere else...

@bluca @pid_eins @siosm

You misunderstood. I secure the key by not having it available in a datacenter. Also the Image it signes will only boot on a single computer so the interest of anyone stealing it area also quite slim.

On ArchLinux every user typically generates their own keys and enrolls these self generated keys within their devices.

Also one can use a HSM if they want to but because of the limited scope it isn't really required.

As I said above entirely different use case...

@bluca @pid_eins @siosm

In earlier posts I misunderstood the new feature. It is obviously way more meaningful when the intended audience is distro that ship a single static and pre-signed kernel or environments with e.g. a golden image.
It also was already outlined above that I'm therefore not within the target audience and that a distro where the final UKI and kernel are created on each individual machine with a different set of parameters also was never one of the intended scenarios either.

@bluca @pid_eins @siosm
In my case these keys are solely protected by the fact that you have to have booted at least once to have the TPM release the key to decrypt the drive.

The only thread vector that is still valid considering the actual intended audience is how one would ensure against an attacker with root access permissions enrolling their own signing keys, patching the kernel, and re-signing it. But that probably only applies to expert users configurations only anyway...

@bluca @pid_eins @siosm
"for normal users" ArchLinux isn't necessarily for normal users.

What is worse in having the uefi signing keys compared to being able to place your malicious script within the build path of an UKI and thereby getting pulled in and (because you don't know about it) signed by you after entering the pin?
None. Both actions require the attacker having root permissions on your system...

@bluca @pid_eins @siosm

So what you're saying is being able to control which files get included in the initrd, as well as which file is used as kernel, and therefore ultimately end up being signed isn't giving an attacker full control?

Sure....

@bluca @pid_eins @siosm
And how is that not also loading arbitrary code before ESB when the attacker basically controls which file gets signed?

I don't see a difference between attacker controlled input and an attacker controlling the input and the signing keys. It's literally the same in this case.

The only reason the UKI is signed at all is because it isn't protected by LUKS2+TPM and could be tampered with offline.

@GossiTheDog well wouldn't be surprised if someone is just calling them pretending to be from their IT department and instructing them to grant them access.

@GossiTheDog Ehm, they're doing both things. The easiest way to get physical access to most companies is to pretend being an employee of their it service contractor. They often just open all of the doors and show you the way right into the server room or ask you if they should log out before you take over (followed by if you'd like tea or coffee). At most what you as an attacker risk is getting also tasked with fixing the printer or copy machine "now that you're already here"...

@GreenSkyOverMe schick das mal dem Lauterbach, der hat doch so sehr von KI im Gesundheitswesen geschwärmt.

@GossiTheDog So ummm responsible disclosure in the US is dead then, right? I mean if criminals are now in CISA and would get informed about zerodays months before they're patched why not just disclose them publicly immediately then?

@bunni @EpicKitty

Need to steal this for @easterhegg2025, hope I'll remember and find it again next month.
#easterhegg #easterhegg2025

@GossiTheDog What exactly do you mean with "you can do it over the internet if you have access to any VM".

Do you mean there needs to be an attacker service running on the VM or that just having a service like a webserver running inside such a VM is enough? (As long as said webserver is accessible from external).

Also to what extend would such a service have to be compromised first?

@malwaretech That may be a copyright violation in certain countries. So including the preview data may not be a great idea...