On Sat, Mar 30, 2024 at 8:07 AM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org> wrote:
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! :-)
Funnily enough, xz can also be built with CMake. :)
I don't know whether the CMake scripts are complete enough to switch
to yet, but we should consider doing it.
>> (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.
This is related to philosophical differences between Arch and Fedora.
That said, it probably makes sense for sd_notify to be its own library
instead of being part of libsystemd. I'm sure systemd upstream will
consider it now. :)
--
真実はいつも一つ!/ Always, there's only one truth!