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.
