Dominique Martinet wrote:
I'm not 100% sure about the theory, but it looks like `autoreconf
-fi`
looks at the 'serial' in the first line of the script.
The one bundled in the xz sources was marked very high:
# build-to-host.m4 serial 30
But the one in the system (as of f39) is only 'serial 1'.
Artificially lowering the serial back to 0 in the file and running
`autoreconf -fi` again properly reinstall the one from the system over
it, but anything higher will keep it...
So if we want to go this route, we should remove the full m4 dir, but
unfortunately I've seen quite a few projects that depend on non-standard
m4 scripts so we'll need to fix these as we go...
Well, it all depends on whether those m4 scripts are really source code or
whether they are autoimported from somewhere like gnulib. True source code
needs to be retained, anything that can be autoimported should be
autoimported at build time. (And upstreams should stop using imported
copylibs to begin with, but that is a different story.)
(At which point I'd suggest it's probably faster to convert
it all to
meson or another new shiny, and saner, build system, but getting upstreams
to agree will be fun)
CMake! :-)
> (2) We should discourage gnulib as much as possible.
> [...]
> In the xz case it was a gnulib-derived script which was modified to do
> the initial injection (original:
>
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/build-to-ho...).
(Honestly I did compare the backdoored script and the real one this
morning and I would be hard pressed to say if either is backdoored just
looking at either version... Admitedly it was 3AM when I looked at it,
but I don't think it's just a late hour problem)
That is exactly the problem with autotools code, almost nobody understands
what the heck it does, almost everybody just copies and pastes somebody
else's snippet hoping it does not do bad things. And gnulib is a
particularly ugly piece of the puzzle.
Before making each of these safer we should make sshd not link with
so
many things in the first place.
Indeed. E.g., Arch Linux does not transitively link sshd against liblzma.
Fedora does because of this innocuous-looking patch:
https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-7.4p1-s...
which is what ultimately allowed this to happen. This drags in libsystemd
for sd_notify, and libsystemd is linked to way too much stuff including
liblzma. Either we need a split libsdnotify that contains only sd_notify, or
we should just stop using sd_notify at all. It increases the attack surface
of daemons a lot just to allow the service to be "Type=notify" rather than
one of the other available approaches. Arch Linux is also systemd-based
nowadays, but still does not link OpenSSH against libsystemd.
Kevin Kofler