GDB 10.1 released [LWN.net]

GDB 10.1 released

Posted Oct 25, 2020 17:53 UTC (Sun) by kalvdans (subscriber, #82065) [Link]

Considering that DWARF4 expressions are turing complete with the backwards branching opcode DW_OP_bra I guess malicous debuginfo can cause even a bug-free GDB to hang.

GDB 10.1 released

Posted Oct 25, 2020 19:26 UTC (Sun) by mjw (subscriber, #16740) [Link] (8 responses)

Note the Security section of debuginfod:

debuginfod does not include any particular security features. While it is robust with respect to inputs, some abuse is possible. It forks a new thread for each incoming HTTP request, which could lead to a denial-of-service in terms of RAM, CPU, disk I/O, or network I/O. If this is a problem, users are advised to install debuginfod with a HTTPS reverse-proxy front-end that enforces site policies for firewalling, authentication, integrity, authorization, and load control. The /metrics webapi endpoint is probably not appropriate for disclosure to the public.
When relaying queries to upstream debuginfods, debuginfod does not include any particular security features. It trusts that the binaries returned by the debuginfods are accurate. Therefore, the list of servers should include only trustworthy ones. If accessed across HTTP rather than HTTPS, the network should be trustworthy. Authentication information through the internal libcurl library is not currently enabled.

That last sentence doesn't seem accurate or doesn't mean what I think it does. It might be speaking about client certificates, not server cerficates. Server certificates seem to be checked as expected. I noticed that the experimental opensuse debuginfod server had an expired certificate. libdebuginfod refuses to retrieve any binaries/debuginfo/sources from that server. The error message doesn't mention that is because of a bad certificate though. I submitted a patch.

GDB 10.1 released

Posted Oct 25, 2020 23:37 UTC (Sun) by pabs (subscriber, #43278) [Link] (7 responses)

Hmm, so the security of gdb when using debuginfod servers is solely based on https certificates and the web PKI? That doesn't inspire confidence in me, I think I would want to run a local debuginfod server that transparently uses rpm/apt to download the right packages, extract and cache the debug symbols.

GDB 10.1 released

Posted Oct 26, 2020 10:37 UTC (Mon) by mjw (subscriber, #16740) [Link] (5 responses)

> Hmm, so the security of gdb when using debuginfod servers is solely based on https certificates and the web PKI?

I wouldn't say solely. You already trust your distro to provide the binaries to run under gdb, which could in theory do anything. But yes, the underlying idea is that you trust the binary provider to also provide the debuginfo and sources for that binary through trusting their https certificate.

> That doesn't inspire confidence in me, I think I would want to run a local debuginfod server that transparently uses rpm/apt to download the right packages, extract and cache the debug symbols.

That is certainly a valid use case. There is even an example config that does (almost) what you want out of the box (for rpm based systems): https://sourceware.org/git/?p=elfutils.git;a=blob;f=confi...

And that is basically what distro public servers do, except they can more easily work with all packages ever build and just preindex the packages (plus debuginfo and debugsources) based on build-ids.

If you want to do it completely transparently and locally then you'll just need to add a transparent downloader for the rpm/apt packages (based in build-id) that deposits those in a directory that the debuginfod server scans.

GDB 10.1 released

Posted Oct 26, 2020 12:52 UTC (Mon) by pabs (subscriber, #43278) [Link] (4 responses)

I think it would be useful to have fully functional packages for the scheme I described available in various distros, then folks who need one could easily setup one and distros could even use that for their debuginfod servers. On that note, is the setup of the existing public debuginfod servers published somewhere?

GDB 10.1 released

Posted Oct 26, 2020 14:32 UTC (Mon) by fuhchee (guest, #40059) [Link] (3 responses)

> On that note, is the setup of the existing public debuginfod servers published somewhere?

The debuginfod.systemtap.org server I operate is just an off-the-shelf copy of debuginfod, run against a directories that contain literally nothing but curl-scraped copies of rpm/deb/etc. files from distros' web archives. There is little to the setup other than cron jobs driving curl from ugly little shell scripts.

Longer form background info on server operation is here:

https://developers.redhat.com/blog/2019/12/17/deploying-d...

GDB 10.1 released

Posted Oct 26, 2020 15:01 UTC (Mon) by pabs (subscriber, #43278) [Link] (2 responses)

curl makes it sound like you aren't doing any signature verification when downloading packages?

GDB 10.1 released

Posted Oct 26, 2020 15:42 UTC (Mon) by fuhchee (guest, #40059) [Link] (1 responses)

rpms are self-signing, if that's what you mean, independent of how they are transported.

GDB 10.1 released

Posted Oct 27, 2020 3:37 UTC (Tue) by pabs (subscriber, #43278) [Link]

As a Debian user I always forget that aspect of the RPM world. Please note that for Debian based distros per-package signatures are usually not used, so your scripts might want to use apt instead of curl.

GDB 10.1 released

Posted Oct 26, 2020 12:03 UTC (Mon) by fuhchee (guest, #40059) [Link]

> That doesn't inspire confidence in me.

I get it. To some extent, this is inherent in returning contents of distro archives in raw form, no longer protected by whatever crypto signature mechanism is in use at the distro level. Substantial trust will come from having distros / ISVs set up their own https debuginfod servers. End-users can each decide which servers they wish to trust (since they control $DEBUGINFOD_URLS), and particularly concerned end-users can very easily run their own local server.

GDB 10.1 released

Posted Oct 25, 2020 22:25 UTC (Sun) by roc (subscriber, #30627) [Link]

Having read quite a lot of gdb source code I wouldn't have any faith in its ability to process untrusted input.

Using a SIGSEGV handler to work around crashes in C++ demangling also does not inspire confidence. https://robert.ocallahan.org/2020/03/debugging-gdb-using-...