> The OpenSSH project is careful about not taking on unnecessary dependencies, but Debian was not as careful. That distribution patched sshd to link against libsystemd, which in turn linked against a variety of compression packages, including xz's liblzma. Debian's relaxing of sshd's dependency posture was a key enabler for the attack, as well as the reason its impact was limited to Debian-based systems such as Debian, Ubuntu, and Fedora, avoiding other distributions such as Arch, Gentoo, and NixOS.

Does Fedora use Debian's patch set for sshd, or a similar patch set that adds libsystemd?

Edit: It looks like Fedora wasn't affected because the backdoor triggered a valgrind test failure, so they shipped it with a flag that disabled the functionality that was backdoored. Seems like they lucked out. https://lists.fedoraproject.org/archives/list/devel@lists.fe...

A very well-written piece. The section on funding open source is as relevant as it's ever been, and I don't think we've learnt much since last year.

As the proportion of younger engineers contributing to open-source decreases (a reasonable choice, given the state of the economy), I see only two future possibilities:

1. Big corporations take ownership of key open-source libraries in an effort to continue their development.

2. Said key open-source libraries die, and corporations develop proprietary replacements for their own use. The open source scene remains alive, but with a much smaller influence.

From Linux Security Summit 2019, a retrospective on mandatory access control and bounding "damage that can be caused by flawed or malicious applications" in Android, iOS, macOS, Linux, FreeBSD and Zephyr, https://static.sched.com/hosted_files/lssna19/e5/LSS2019-Ret...

  For the past 26 years, the speaker has been engaged in the design, implementation, technology transfer, and application of flexible Mandatory Access Control (MAC). In this talk, he describes the history and lessons learned from this body of work. The background and motivation for MAC is first presented, followed by a discussion of how a flexible MAC architecture was created and matured through a series of research systems. The work to bring this architecture to mainstream systems is then described, along with how the architecture and implementation evolved. The experience with applying this architecture to mobile platforms is examined. The role of MAC in a larger system architecture is reviewed in the context of a secure virtualization system. The state of MAC in mainstream systems is compared before and after our work. Work to bring MAC to emerging operating systems is discussed.

One of my struggles is to get docker to lockdown which images it loads. I'd like to only pull from my own blessed registry and it seems Docker wants to always go back to theirs.

For other "package" managers (eg: CPAN, Debian) I can point to my own archive and be sure everything I manage down stream gets the blessed bits.

I basically have a huge archive/mirror for the supply chain for my perl, PHP, JavaScript, etc.

If anyone has pro tips on how to "lock" docker to one registry that would be cool.

A lovely article, but one section definitely needs a [citation needed]

> (OpenSSL is written in C, so this mistake was incredibly easy to make and miss; in a memory-safe language with proper bounds checking, it would have been nearly impossible.)

    package main

    import "fmt"

    type CmdType int

    const (
        WriteMsg CmdType = iota
        ReadMsg
    )

    type Cmd struct {
        t CmdType
        d []byte
        l int
    }

    var buffer [256]byte

    var cmds = []Cmd{
        Cmd{WriteMsg, []byte("Rain. And a little ice. It's a damn good thing he doesn't know how much I hate his guts."), 88},
        Cmd{WriteMsg, []byte("Rain. And a little ice."), 23},
        Cmd{ReadMsg, nil, 23},
        Cmd{ReadMsg, nil, 88}, // oops!
    }

    func main() {
        for c := range cmds {
            if cmds[c].t == WriteMsg {
                copy(buffer[:], cmds[c].d[:cmds[c].l])
            } else if cmds[c].t == ReadMsg {
                fmt.Println(string(buffer[:cmds[c].l]))
            }
        }
    }

It wasn't caught because OpenSSL had built its own buffer/memory management routines on top of the actual ones provided by the language (malloc, memcpy, realloc, free), and all sorts of unsafe manipulations were happening inside one big buffer. That buffer could be in a language with perfect memory safety, the same flaw would still be there.

Related; https://news.ycombinator.com/item?id=43617352 North Korean IT workers have infiltrated the Fortune 500

Good article for what it covers, but sadly does not cover isolation/sandboxing/least privilege.

Great coverage, however it failed to mention code review and artifact signing as well as full source bootstrapping which are fundamental defenses most distros skip.

In our distro, Stagex, our threat model assumes at least one maintainer, sysadmin, or computer is compromised at all times.

This has resulted in some specific design choices and practices:

- 100% deterministic, hermetic, reproducible

- full source bootstrapped from 180 bytes of human-auditable machine code

- all commits signed by authors

- all reviews signed by reviewers

- all released artifacts are multi-party reproduced and signed

- fully OCI (container) native all the way down "FROM scratch"

- All packages easily hash-locked to give downstream software easy determinism as well

This all goes well beyond the tactics used in Nix and Guix.

As far as we know, Stagex is the only distro designed to strictly distrust maintainers.

https://stagex.tools

Very suspicious article. Sounds like the "nothing to see here folks, move along" school of security.

Reproducibility is more like a security smell; a symptom you’re doing things right. Determinism is the correct target and subtly different.

The focus on supply chain is a distraction, a variant of The “trusting trust” attack Ken Thompson described in 1984 is still among the most elegant and devastating. Infected development toolchains can spread horizontally to “secure” builds.

Just because it’s open doesn’t mean anyone’s been watching closely. "50 years of security"? Important pillars of OSS have been touched by thousands of contributors with varying levels of oversight. Many commits predate strong code-signing or provenance tracking. If a compiler was compromised at any point, everything it compiled—including future versions of itself—could carry that compromise forward invisibly. This includes even "cleanroom" rebuilds.