Re: xz backdoor
Sirius <sirius@trudheim.com> writes:
> Would throwing away these unmodified (?) macros packaged projects may be
> carrying for hysterical raisins in favour of just using the autoconf
> native macros reduce the attack-surface a potential malicious actor
> would have at their disposal, or would it simply be a "putting all eggs
> in one basket" and just make things worse? And by how much vis-a-vis the
> effort to do it?
Most of the macros of this type are not from Autoconf. They're from
either gnulib or the Autoconf Archive. In both cases, blindly upgrading
to a newer upstream version may break things, I believe. I'm not as sure
with gnulib, but the Autoconf Archive is a huge collection of things with
varying quality and does not necessarily have any guarantees about APIs.
> I think that what I am trying to get at is this: is there low-hanging
> fruit that for minimal effort would disproportionately improve things
> from a security perspective. (I have an inkling that this is a question
> that every distribution is wrestling with today.)
I think the right way to think about this is to say that the Autoconf
ecosystem is rife with embedded code copies and, because the normal way of
using this code is to make a copy, is also somewhat lax about making
breaking changes since the expectation is that you only update during your
release process when you can fix up any changes.
(That code is also notoriously hard to read, both because M4 is a language
with fairly noisy syntax and because the only tools assumed to be
available in the output scripts is a very minimal Bourne shell and
standard POSIX shell utilities, so there's a lot of the type of
programming that only shell aficionados can love. That was the problem
with detecting this backdoor: the sort of chain of tr and eval and
whatnot that injected the backdoor is what, e.g., all of Libtool looks
like, at least on a first superficial glance.)
I know all this adds up to "why are we using this stuff anyway," but the
amount of hard-won portability knowledge that's baked into these tools is
IMMENSE, and while probably 75% of it is now irrelevant because the
systems that needed it are long-dead, no one can agree on what 75% that is
or figure out which useful 25% to extract. And rewriting it in some other
programming language is daunting and feels like churn rather than
progress.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: