[Bug debuginfod/30978] New: debuginfod-client security: optionally(?) verify downloaded binaries

[Bug debuginfod/30978] New: debuginfod-client security: optionally(?) verify downloaded binaries

[rfhn.fhbrrjnzeneqpf at noclue dot notk.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30978

            Bug ID: 30978
           Summary: debuginfod-client security: optionally(?) verify
                    downloaded binaries
           Product: elfutils
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: debuginfod
          Assignee: unassigned at sourceware dot org
          Reporter: rfhn.fhbrrjnzeneqpf at noclue dot notk.org
                CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

This is mostly a follow-up of #25607 (debuginfod-client: paranoid federation
mode) and #27758 (security idea: DEBUGINFOD_VERIFY mode) as I was looking at it
again, but through a different approach: the downloaded files should be
verified from something within the debugged binary that has been signed by
$distro, so as not to trust a random binary downloaded from a random server (as
pointed out in the federation mode bz), even if it's just for debuginfo
parsing, as that code has had bugs.

As things stand, fedora/debian still ship a .gnu_debuglink section whch
contains a crc32 of the binary that can be verified:
```
$ file /lib64/libc.so.6
/lib64/libc.so.6: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=75fb4e8e3b20efcec877a571581917c4494a427e, for GNU/Linux 3.2.0,
not stripped
$ cd $HOME/.cache/debuginfod_client/75fb4e8e3b20efcec877a571581917c4494a427e
$ objdump -s -j .gnu_debuglink /lib64/libc.so.6

/lib64/libc.so.6:     file format elf64-x86-64

Contents of section .gnu_debuglink:
 0000 6c696263 2e736f2e 362d322e 33382d36  libc.so.6-2.38-6
 0010 2e666333 392e7838 365f3634 2e646562  .fc39.x86_64.deb
 0020 75670000 21402d66                    ug..!@-f        
$ cksfv debuginfo
; Generated by cksfv v1.3.15 on 2023-10-18 at 03:47.00
; Project web site: https://gitlab.com/heikkiorsila/cksfv
;
;      9994312  09:00.00 2023-10-03 debuginfo
debuginfo 662D4021
```
-> 662d4021 matches 21402d66

Unfortunately a mere crc32 has no cryptography value, so this bz isn't so much
about checking with .gnu_debuglink, than a much bigger process of making
.gnu_debuglink more safe (using e.g. sha256sum o anything considered secure at
the time) and then using that...

I'm unfortunately very selfish here as well as I have no time to work on this
short term, but would be happy to help in the long run after taking the initial
temperature as I think it's important to not trust random binaries downloaded
on the internet.

The process should be fairly straightforward:
- agree on what kind of checksum we want and new section name (as I don't
suppose .gnu_debuglink can change)
ideally here I'd suggest embedding the hash algorithm in the section so it can
evolve, e.g. `{sha256}<binaryhash>` or given it's small enough even as a string
`sha256-0gotgQ4N0yE8WZbsu7B3jmUIZrycbqjEMxZl01JcJj4=`
- add something similar to `objcopy --add-gnu-debuglink` to produce it; ideally
make it possible to use both options together in a single pass.
- add something to debuginfod to check after downloading a file if present (or
optionally if deemed too costly)
- convince distros to start producing using new objcopy option once it's
available (I don't think that'll be difficult given I remember this was a
concern multiple times on the fedora lists when debuginfod was first
introduced)

Thanks!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug debuginfod/30978] debuginfod-client security: optionally(?) verify downloaded binaries

[rfhn.fhbrrjnzeneqpf at noclue dot notk.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30978

--- Comment #1 from Dominique Martinet <rfhn.fhbrrjnzeneqpf at noclue dot notk.org> ---
Relevant part of the fedora-devel thread at the time, justifying there'd be
interest in distros:
https://www.mail-archive.com/devel@lists.fedoraproject.org/msg166474.html

(sorry for double-update, took me a bit to find that link)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug debuginfod/30978] debuginfod-client security: optionally(?) verify downloaded binaries

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30978

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fche at redhat dot com

--- Comment #2 from Frank Ch. Eigler <fche at redhat dot com> ---
Note that elfutils has impending patches (awaiting final review) for relaying
and verifying RPM-IMA per-file crypto signatures: bug #28204.  Fedora has been
shipping these types of signatures since something like f37 or f38.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug debuginfod/30978] debuginfod-client security: optionally(?) verify downloaded binaries

[rfhn.fhbrrjnzeneqpf at noclue dot notk.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30978

--- Comment #3 from Dominique Martinet <rfhn.fhbrrjnzeneqpf at noclue dot notk.org> ---
Interesting, thanks for the link!

The implementation hurdle is a bit higher than updating the already-used
objcopy command I was suggesting (won't be available for distros like debian
that don't ship IMA data), but if available it's definitely a good alternative.
As I understand that bz, the signature would be verified if available
regardless of the kernel IMA setting, so for all fedora users as soon as it's
available in debuginfod?
I'll check the bz in more details and patch as time permits (probably next
week)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug debuginfod/30978] debuginfod-client security: optionally(?) verify downloaded binaries

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30978

--- Comment #4 from Frank Ch. Eigler <fche at redhat dot com> ---
Note that the main problem with this sort of scheme is not the checksum
(whether CRC or a hash).  That part can help provide some assurance against
accidental corruption.  (Plus you'd need external checksums for source files,
which can't get additional ELF doohickeys inserted.

But you'd need crypto signatures on those hashes in order to protect against
deliberate corruption anywhere between the original build system and your
client.  That in turn requires distribution of crypto keys.  It goes well
beyond the objcopy stuff.

I'm not sure whether the debian ecosystem has started thinking about this
stuff, but when/if they do, debuginfod should be adaptable to pass on whatever
assurances are possible.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug debuginfod/30978] debuginfod-client security: optionally(?) verify downloaded binaries

[rfhn.fhbrrjnzeneqpf at noclue dot notk.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30978

--- Comment #5 from Dominique Martinet <rfhn.fhbrrjnzeneqpf at noclue dot notk.org> ---
debian has kept .gnu_debuglink (like fedora), so if we extend that to store a
more reliable hash I believe that process should be fairly straightforward as
they already must have an objcopy --add-gnu-debuglink command somewhere that
could just be updated

I haven't seen anything about IMA on debian though, so that'd likely come much
later

-- 
You are receiving this mail because:
You are on the CC list for the bug.