Re: Remove dependency on libjansson

[Luca Boccassi <bluca@debian.org>]

On Mon, 1 Apr 2024 at 10:50, Sam James <sam@gentoo.org> wrote:
>
> Fangrui Song <i@maskray.me> writes:
>
> > On Sun, Mar 31, 2024 at 8:31 PM Rui Ueyama <rui314@gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> The recent xz incident demonstrated that supply chain attacks are a
> >> real threat, and dependence on third-party libraries can have
> >> significant consequences.
> >>
> >> In the wake of the incident, I propose we remove the dependency on
> >> libjansson from GNU ld.
> >>
> >> First of all, why does GNU ld depend on libjansson which is a JSON
> >> parsing library? GNU ld gained the `--package-metadata` option in May
> >> 2022 to embed a JSON string into a .note section for package
> >> management for Fedora and other Linux distributions. At the same time,
> >> the dependency on libjansson, a library for parsing JSON-format
> >> strings, was introduced to validate an argument for that option. If an
> >> argument is not a valid JSON string, ld reports an error. If the
> >> library is unavailable, or if `--disable-jansson` was passed to the
> >> configure script, the library will not be linked and the error check
> >> will be disabled. By default, the library will be linked if it exists.
> >>
> >> I opposed adding an extra dependency to GNU ld just for string
> >> verification purposes because it didn't seem worth adding extra
> >> dependency to the linker. LLVM lld and the mold linker also support
> >> the option, but they do not verify if the argument is a valid JSON
> >> string -- they simply treat it as an opaque string. If libjansson is
> >> unavailable, even GNU ld doesn't verify arguments. Therefore, the
> >> verification is not trustworthy, and the reader must be prepared for a
> >> malformed JSON string when reading a .note section. Moreover,
> >> verifying a string is straightforward without the feature; you can
> >> simply `echo` the string to pipe it to `jq` for verification before
> >> passing it to GNU ld.
> >>
> >> I just checked /usr/bin/ld on Ubuntu 24.04, which is set to be
> >> released this month, and the dependency on libjansson was indeed
> >> present.
> >>
> >> How much risk does it pose? Probably not much, as long as the library
> >> is maintained properly. However, the stakes are high; if someone takes
> >> control of the library and introduces malicious code, they could
> >> execute a Ken Thompson-style supply chain attack. Since GNU ld is used
> >> to build essentially everything, the attacker could in theory gain the
> >> power to not just contaminate a specific program such as openssh, but
> >> every executable in an official Linux distribution image. I think the
> >> risk is not worth taking. I believe we just should remove the string
> >> verification code and the dependency on the library from GNU ld.
> >>
> >> Rui Ueyama
> >
> > Thanks for bringing this up again. I support removing the json dependency.
> >
> > I lightly expressed my concern
> > https://sourceware.org/pipermail/binutils/2022-May/120846.html and
> > there might be others unsure about the dependency as well.
>
> I'd like to hear bluca's take before making up my mind. Note that it's
> also automagic right now IIRC (enabled if installed, not opt-in).
>
> But my take on it so far is that it doesn't sound worth it.

$ apt-cache rdepends libjansson4 | wc -l
310

Sorry, but this looks to me like a knee-jerk reaction that misses the
wood for the trees. The xz issue is that an extremely complex and
sophisticated social engineering attack was planned and executed over
multiple years. If it hadn't been on xz, it would have been on another
project. Dropping dependencies left and right without thinking will
not stop the next attack, as there is no shortage of overworked
maintainers to try and abuse. In fact, avoiding common libraries and
everyone reimplementing the wheel _increases_ the attack
opportunities.

The reason for this integration is that finding issues at build time
is cheaper than finding them at runtime or release time. We rely on
this in Fedora, Debian and Ubuntu to ensure valid data is written (in
all packages in the former, in an increasing set of opt-ins in the
latters) - in fact, validating input _before_ shipping binaries
_improves_ security, rather than decreasing it, given the payload is
parsed by a privileged component.

So if it was removed upstream, we'd just have to patch it back in
downstream in each interested distro - which if you recall, was
exactly how sshd was exploited, due to the lack of an upstream common
implementation. This is opt-in, so distributions that are not
interested can just avoid enabling it, with no extra effort required.
So please, leave it as-is. Thank you.