On backdooring open source projects

[Georgi Guninski]

If the recent xz backdoor drama didn't induce enough paranoia in you,
here is a second chance exception:

https://www.theregister.com/2024/04/16/xz_style_attacks_continue/


Open sourcerers say suspected xz-style attacks continue to target maintainers
Social engineering patterns spotted across range of popular projects
Tue 16 Apr 2024 // 14:07 UTC

Open source groups are warning the community about a wave of ongoing
attacks targeting project maintainers similar to those that led to the
recent attempted backdooring of a core Linux library.

[Lorenz Panny]

This also seems like a good time to reiterate an old comment of mine:
https://groups.google.com/g/sage-devel/c/Dq83PiiCAsU/m/RKSpD9_rDQAJ
...pasted below for your convenience.

On Tue, 21 Dec 2021 04:04:31 +0100, Lorenz Panny <l.s....@tue.nl> wrote:
> On Mon, 20 Dec 2021 14:41:27 +0100, Michael Orlitzky <mic...@orlitzky.com>
> wrote:
> > We already have 214 standard packages. That's 214 pieces of software
> > copy & pasted into the sage releases... and 214 SPKGs that the sage
> > developers need to keep updating, and 214 distro packages that every
> > distro maintainer needs to keep track of as dependencies of the sage
> > package.
>
> It's also 214 software packages which might, for all we know, at any
> time be hijacked by The Bad Guys to run arbitrarily malicious code on
> every Sage user's machine.
>
> This is terrifying.
>
> (For examples where the modern "import * from internet" mentality has
> led to security disasters, just search for terms like "malicious npm".
> Luckily it seems less bad with pip packages for now, but not for any
> real reason. Every single piece of code we import adds huge security
> questions, because updates to the dependency may be published at any
> time totally invisible to Sage developers and the review process used
> in Sage development. The build scripts will simply pull and run it.)
>
> We should reduce dependencies, not add more. _Especially_ when it's
> about non-essential convenience libraries.

> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group. To unsubscribe from this group and stop receiving emails
> from it, send an email to sage-devel+...@googlegroups.com. To view
> this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/CAGUWgD82%3DoROFFxZwrKZG6eB0Kd5GEKW8wrPw_Q4gm8WJjioCA%40mail.gmail.com.

[Georgi Guninski]

I think you raise very important concerns.
The only sage change I see after the xz drama is @Dima occasionally
PGP signing his mails.
The more packages you "own", the more developers you own. The more
developers you own, the more packages you own.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/20240418160443.79b10a15%40l4.

[Michael Orlitzky]

On 2024-04-18 16:04:43, Lorenz Panny wrote:
> >
> > It's also 214 software packages which might, for all we know, at any
> > time be hijacked by The Bad Guys to run arbitrarily malicious code on
> > every Sage user's machine.
> >
> > This is terrifying.

276 now

[Matthias Koeppe]

On Thursday, April 18, 2024 at 11:05:52 PM UTC-7 Georgi Guninski wrote:

The only sage change I see after the xz drama [....]

Well, here's one, waiting for review:

https://github.com/sagemath/sage/pull/37726 (prepared by @faisalfakhro; I reviewed and made some minor changes) updates the cryptographic hashes used by the Sage distribution for authenticating the downloaded tarballs to use the secure hash sha256 instead of sha1 because of the known insecurity of sha1.

[Emmanuel Charpentier]

I’d like to point out that Sage, by it’s very nature, is a large bundle of other people’s packages, offering them a (more or less) unified interface, thus ensuring interoperability. To reuse a simile used in Sage’s initial statements of intent, Sage is a car using many already- pepared wheels.

Any of these wheels is by definition, a gateway for attacking Sage. Reducing the number of packages we use entails developing suitable replacements.

Do we have the manpower necessary to such development ? .

​

[Michael Orlitzky]

On Sat, 2024-04-20 at 12:53 -0700, Emmanuel Charpentier wrote:
>
> Do we have the manpower necessary to such development ? .

Linux distributions (or e.g. Conda) already do it for us.

What we don't have is the manpower to do what we currently do, but
*correctly*. The sage distribution sucks. Lots of packages are
outdated. Our ./configure detection system doesn't understand complex
requirements. It can't do dependency resolution (can't tell if a
package is needed or not). System and SPKG packages can't be mixed. We
can't pass ./configure options to the packages we build. We don't have
different classes of (build, runtime, test) dependencies. Our build
scripts are random collections of shell code. Our tests don't pass. We
can't rebuild for ABI breakage. We don't support multiple versions of
packages. The standard/optional system is inconsistent. We can't push
security fixes to users. In fact, we don't even bother to look for
security issues in the first place.

Everything's easy if you do a bad enough job at it.

[Matthias Koeppe]

This has been merged in 10.4.beta7.

[Georgi Guninski]

On Sat, May 25, 2024 at 10:10 PM Matthias Koeppe
<matthia...@gmail.com> wrote:

> This has been merged in 10.4.beta7.
>

Good to see some action :)

Here is a short anti-security rant from my experience.

To protect something, you need to fix all weaknesses.
To break it, an attacker needs only one exploitable weakness.

What does game theory say about this non-cooperative "game",
will there be Nash equilibrium? Will competing attackers reach
equilibrium? Will everything be compromised? "Will they'll drop
the bomb" (Pink Floyd)?

In the past bugs has killed people by overdosing some medical stuff
and water supplies has be compromised, giving the ability to overdose
water "ingredients".

My threat model includes a prodigy (kid) which breaks
real world stuff like the electricity network (possibly while drunk).