BLU Discuss list archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss] Debian 12 in the Cloud
- Subject: [Discuss] Debian 12 in the Cloud
- From: richard.pieri at gmail.com (Rich Pieri)
- Date: Mon, 3 Jun 2024 17:46:23 -0400
- In-reply-to: <20240603155857.3eae5d9d@mydesk.domain.cxm>
- References: <a09a4ca0-bfc8-4c5c-ad30-e307be9e2cc1@borg.org> <f840e62cb5c88c336909575f0acc5365.squirrel@mail.mohawksoft.com> <20240601230337.2a901446@mydesk.domain.cxm> <20240602104210.4165888d.Richard.Pieri@gmail.com> <20240603155857.3eae5d9d@mydesk.domain.cxm>
On Mon, 3 Jun 2024 15:58:57 -0400 Steve Litt <slitt at troubleshooters.com> wrote: >> >Numbers of lines of code does not correlate with attack surface. > That's exactly what I said, except I used the word correlate. You said there is a correlation even if it's not 1:1. I said that no such correlation exists. It's a myth. Because all other things are *not* equal. Smaller and simpler can be easier to understand, test, and debug; but being easier to understand, test and debug is not a function of size. A large, well-written program can be easier to understand, etc., than a small, poorly-written program. The Linux kernel vs. systemd. The kernel is ~15 times larger than systemd in terms of lines of code, yet the attack surface is much smaller due to better design and better coding practices. I need to amend your timeline because systemd is getting better. The developers have been removing potentially insecure external dependencies, including XZ, so the timeline really looks like this: * systemd incorporates XZ into itself [basic Unix philosophy of reusing existing tools/libraries] * Long game evil SOB tortures unpaid, volunteer XZ maintainer [not underpaid; unpaid] * SOB begins preparations for inserting their backdoor into XZ code * Two years of SOB slowly and carefully implementing their payload delivery scheme [backdoor is not here, yet] * systemd crew announce forthcoming removal of XZ dependency [disaster for SOB] * SOB, now under severe time constraints, quickly commits obfuscated backdoor code into the 5.6.0 and 5.6.1 tarballs, hidden from the github repo using .gitignore. * SOB asks Red Hat and Debian to accept the 5.6.0/5.6.1 releases into their testing/rolling releases which they do. Other rolling distros and development releases follow suit. [common practice for developers wanting their latest and greatest included in the latest and greatest distro releases] [backdoor is now live on a relatively small number of systems -- including two of mine running Tumbleweed, though neither exposed to the public network and therefore not exploitable] * Andres Freund identifies an anomaly, tracks it to the backdoor [*very* lucky us] -- \m/ (--) \m/
- Follow-Ups:
- [Discuss] Debian 12 in the Cloud
- From: slitt at troubleshooters.com (Steve Litt)
- [Discuss] Debian 12 in the Cloud
- References:
- [Discuss] Debian 12 in the Cloud
- From: slitt at troubleshooters.com (Steve Litt)
- [Discuss] Debian 12 in the Cloud
- From: richard.pieri at gmail.com (Rich Pieri)
- [Discuss] Debian 12 in the Cloud
- From: slitt at troubleshooters.com (Steve Litt)
- [Discuss] Debian 12 in the Cloud
- Prev by Date: [Discuss] Debian 12 in the Cloud
- Next by Date: [Discuss] Kaspersky KVRT
- Previous by thread: [Discuss] Debian 12 in the Cloud
- Next by thread: [Discuss] Debian 12 in the Cloud
- Index(es):