[03:44] schestowitz__n the simplest words, static linking means embedding your programs dependencies directly into the program image. The term is generally used in contrast to dynamic linking (or dynamic loading) that keep the dependent libraries in separate files that are loaded at programs startup (or runtime).
[03:44] schestowitz__Why is static linking bad? The primary problem is that since they become the integral part of the program, they can not be easily replaced by another version. If it turns out that one of the libraries is vulnerable, you have to relink the whole program against the new version. This also implies that you need to have a system that keeps track of what library versions are used in individual programs.
[04:20] schestowitz__● Feb 23 [15:00] Techrights-sec2 the background processing of 2020 finished. it should now have better [15:00] Techrights-sec2 block quotes [15:00] schestowitz__ excellent, I will try to be consistent with the html to assure it's consistently converted [15:36] Techrights-sec2 thanks. there's not really a way to do error checking since it is just scraping ● Feb 23 [16:16] *TechrightsBN (~b0t@techrights.org) has joined #boycottnovell [16:16] TechrightsBN Hello World! I'm TechrightsBN running phIRCe v0.75 [16:21] *TechrightsBN has quit (Ping timeout: 272 seconds) ● Feb 23 [18:28] *TechrightsBN (~b0t@techrights.org) has joined #boycottnovell [18:28] TechrightsBN Hello World! I'm TechrightsBN running phIRCe v0.75 ● Feb 23 [20:10] Techrights-sec2 HV and TR and TM ha [20:10] Techrights-sec2 ve had network problems and been unavailable on and offhost! [20:11] schestowitz__ Yes, that happened yesterday as well, it breaks off for a few minutes, kaniini irc clients also temporarily falls offline or stalls [20:11] schestowitz__ Did I miss anything between 5pm UTC today and this time the session of ytalk resumed? [20:12] Techrights-sec2 I send a partial traceroute in the e-mail a while ago. #From####################### [20:12] Techrights-sec2 both the EU and the US the break was in the same point [20:13] Techrights-sec2 No, just the comments about HV etc being unavialable via the net. [20:14] schestowitz__ I went to sleep around that time, so did not see the moment ytalk broke apart... could not reconnect until just now ● Feb 23 [22:34] *schestowitz__ is now known as schestowitz ● Feb 23 [23:09] schestowitz Re: Jonathan Wiltshire image URL change [23:09] schestowitz > You have a few links to the jonathan-wiltshire-* image in here: [23:09] schestowitz > [23:09] schestowitz > http://techrights.org/2020/10/26/jonathan-wiltshire-gchq-theory/ [23:09] schestowitz > [23:09] schestowitz > The new URL: [23:09] -TechrightsBN/#boycottnovell-techrights.org | Jonathan Wiltshire and Debian, Falsified Harassment Claims, Tiger Computing and GCHQ | Techrights [23:09] schestowitz > [23:09] schestowitz > https://ipfs.io/ipfs/QmereN1pANAgeiwPZiADehPsNKwrye4qpFB8YhTLqcGNDQ [23:09] schestowitz Updated. [23:10] schestowitz > Hi Roy, [23:10] schestowitz > [23:10] schestowitz > I made some changes to the text, can you please sync it? I feel the [23:10] schestowitz > revised text is easier to follow and makes a stronger point. [23:10] schestowitz I will update now. [23:14] schestowitz It does add some necessary background, which I sort of overlooked as it lacked an explanation of the analogous scenario. I can think of many other similar stories. [23:41] schestowitz Re: Bill Gates burned in croatian carnaval [23:41] schestowitz > https://twitter.com/NicolasPichot6/status/1363280931163938821 [23:41] -TechrightsBN/#boycottnovell-@NicolasPichot6: Bill Gates cibl par un Carnaval en Croatie qui a tout compris. Son effigie caricaturale finira brle. (voir au d https://t.co/0qOf8T1qlQ [23:41] -TechrightsBN/#boycottnovell-@NicolasPichot6: Bill Gates cibl par un Carnaval en Croatie qui a tout compris. Son effigie caricaturale finira brle. (voir au d https://t.co/0qOf8T1qlQWhen we encrypt material with the TPM, we can ask it to record the PCR state. This is given back to us as metadata accompanying the encrypted secret. Along with the metadata is an additional signature created by the TPM, which can be used to prove that the metadata is both legitimate and associated with this specific encrypted data. In our case, that means we know what the value of PCR 23 was when we [04:20] schestowitz__ encrypted the key. That means that if we simply extend PCR 23 with a known value in-kernel before encrypting our key, we can look at the value of PCR 23 in the metadata. If it matches, the key was encrypted by the kernel - userland can create its own key, but it has no way to extend PCR 23 to the appropriate value first. We now know that the key was generated by the kernel.
[04:20] schestowitz__But what if the attacker is able to gain access to the encrypted key? Let's say a kernel bug is hit that prevents hibernation from resuming, and you boot back up without wiping the hibernation image. Root can then read the key from the partition, ask the TPM to decrypt it, and then use that to create a new hibernation image. We probably want to prevent that as well. Fortunately, when you ask the TPM to [04:20] schestowitz__ encrypt something, you can ask that the TPM only decrypt it if the PCRs have specific values. "Sealing" material to the TPM in this way allows you to block decryption if the system isn't in the desired state. So, we define a policy that says that PCR 23 must have the same value at resume as it did on hibernation. On resume, the kernel resets PCR 23, extends it to the same value it did during hibernation, and then attempts to [04:21] schestowitz__ decrypt the key. Afterwards, it resets PCR 23 back to the initial value. Even if an attacker gains access to the encrypted copy of the key, the TPM will refuse to decrypt it.
[04:21] schestowitz__And that's what this patchset implements. There's one fairly significant flaw at the moment, which is simply that an attacker can just reboot into an older kernel that doesn't implement the PCR 23 blocking and set up state by hand. Fortunately, this can be avoided using another aspect of the boot process. When you boot something via UEFI Secure Boot, the signing key used to verify the booted code is [04:21] schestowitz__ measured into PCR 7 by the system firmware. In the Linux world, the Shim bootloader then measures any additional keys that are used. By either using a new key to tag kernels that have support for the PCR 23 restrictions, or by embedding some additional metadata in the kernel that indicates the presence of this feature and measuring that, we can have a PCR 7 value that verifies that the PCR 23 restrictions are present. We then seal [04:21] schestowitz__ the key to PCR 7 as well as PCR 23, and if an attacker boots into a kernel that doesn't have this feature the PCR 7 value will be different and the TPM will refuse to decrypt the secret.