Re: openwrt Conclusions from CVE-2024-3094 (libxz disaster)

[Denis Ovsienko <denis () ovsienko info>]

On Tue, 2 Apr 2024 14:06:28 +0200
Francois-Xavier Le Bail via tcpdump-workers
<tcpdump-workers () lists tcpdump org> wrote:

> Even if we keep the tarball archive, we could have a host compromise
> (bad autoconf, etc.) and if the "configure" script is generated on
> it, we risk to open a door to an attack.
>
> Thus, don't deliver "configure" in the tarball and ask to run
> "./autogen.sh" with autotools installed.

Let's consider the problem and the solution.

If the host is fully compromised (a remote attacker made themselves the
root user of my computer's OS), there is little point in trying to
game around it.  I delete configure, they put the virus into
autogen.sh.  I delete autogen.sh, they put the virus into mkdep.  I
delete mkdep, they put the virus into Makefile.in.  I delete
Makefile.in, they put the virus into CMakeLists.txt.  I delete
CMakeLists.txt, they put their own file of any name and contents into
the tarball because they are not limited by the contents of the git
repository.  They just need me to sign and publish a tarball with
their contents.

If the host is mostly clean, but the Autoconf package is compromised
through the upstream or otherwise, it means the compromised Autoconf
package is not limited to placing the virus into configure.  It may
happily produce a correct clean configure from a correct clean
configure.ac, and then add the virus into configure.ac or autogen.sh or
mkdep or Makefile.in or...

If the host is clean and Autoconf is clean and every other package is
clean, but the developer is compromised, then in that case why the
compromised developer would limit themselves to the configure script
if they have full control of the release archive contents and the git
repository contents?  What would prevent a compromised developer from
publishing a "secure, configure-free" tarball with a virus in some
other file (configure.ac, etc.)?

If the host is clean and all packages are clean and the developer is
clean and the tarball has no configure script, then the users that want
to compile the source will need to supply their own Autoconf, which can
be compromised as realistically as yours or mine, so effectively
excluding the configure script does not solve the problem, but shifts it
to somebody else's side of the fence and multiplies the number of times
it will need to be solved after the release.

It would not be impossible for every user that builds from source to
arrange a compatible version of Autoconf (you have to build it first in
pkgsrc, for example, and the dependencies) and to verify that their
Autoconf is not compromised.  Some users take exactly this approach and
run "autoreconf -f" as the very first step no matter if the tarball
included configure or not.  Other users choose not to duplicate the work
unnecessarily, but to trust the software developers to figure the
details out correctly once and to use a clean release environment
correctly once, and to publish a tarball that is not compromised, has
a ready to run configure script and a signature.  This is a reasonable
expectation.

A possible way to add confidence to the process could be additional
verification.

Individual computers and OSes can be compromised.  To that end, for
example, the release maker could run "make releasetar" on at least two
separate physical computers, each with a different OS and a different
architecture, and let a script compare the results.  Computers are small
and very affordable now.

Individual developers can be compromised.  When one developer produces
the signed tarballs at their end, another could run "make releasetar"
at their end and let a script compare the contents and verify the
signatures.

This would be a bit of additional work, but security and confidence are
usually at the opposite ends of the same scale.

-- 
    Denis Ovsienko
_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers () lists tcpdump org
To unsubscribe send an email to tcpdump-workers-leave () lists tcpdump org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s