A new Debian debuginfod service

Posted Feb 24, 2021 18:14 UTC (Wed) by dullfire (guest, #111432)
Parent article: A new Debian debuginfod service

With how "stable" I have seen gdb's parsers to be lately, I suspect this a code execution opportunity :/

A new Debian debuginfod service

Posted Feb 25, 2021 19:02 UTC (Thu) by lkundrak (subscriber, #43452) [Link] (7 responses)

Would this be a problem really? Shipping code that you end up executing is a large part of what Linux distributions do already.

Assuming the debugging symbols are signed in the same way as the packages are, shipping illicit debugging symbols achieves the same thing as directly shipping a backdoored package, only in a more complicated manner.

Also, Debian, much like Fedora, already ships the debugging symbols in separate packages. This merely optimizes the delivery process a bit.

A new Debian debuginfod service

Posted Feb 26, 2021 5:22 UTC (Fri) by k8to (guest, #15413) [Link] (5 responses)

I believe the suggestion is that if can pretend to be a debug info system on the network in can remote code execute on developer systems. That's a fairly different attack vector than "I put code into Debian".

A new Debian debuginfod service

Posted Feb 26, 2021 10:26 UTC (Fri) by cortana (subscriber, #24596) [Link] (4 responses)

I hope gdb correctly verifies the TLS server certificate against the hostname and against the system trust store (of course taking into account all the fiddly details such as either supporting every critical extension found in the certificate chain or aborting the connection...)

A new Debian debuginfod service

Posted Feb 26, 2021 12:25 UTC (Fri) by mjw (subscriber, #16740) [Link] (2 responses)

gdb relies on libdebuginfod which in turn relies on libcurl for https connections. libcurl performs peer SSL certificate verification by default. So it relies on the way the distro has setup how libcurl uses the CA store.

A new Debian debuginfod service

Posted Feb 26, 2021 16:57 UTC (Fri) by cortana (subscriber, #24596) [Link]

Hah, I didn't expect someone to check, thanks for that :)

I hope this will allay k8to's worries!

A new Debian debuginfod service

Posted Feb 26, 2021 16:59 UTC (Fri) by cortana (subscriber, #24596) [Link]

... that said - it seems CURLOPT_SSL_VERIFYSTATUS still defaults to 0, so clients have to opt in to revocation checking via OCSP (and whether revocation checking via CRL is even possible or practical, I have no idea).

A new Debian debuginfod service

Posted Feb 26, 2021 17:06 UTC (Fri) by floppus (guest, #137245) [Link]

Trusting a TLS certificate also requires trusting a lot more entities (debuginfo.debian.net operators, their ISPs and domain registrars, hundreds of CAs).

In contrast, when you install 'libc6-dbg' with apt, you're verifying the package against a list that is signed by a known, trusted key. You're not trusting the mirror, their ISP, your ISP, or any other third parties.

I don't know exactly how build-ids are generated, but apparently they're a SHA-1 hash of the original binary contents and some of the metadata. Setting aside the fact that SHA-1 looks rather weak nowadays, I wonder if it'd be possible to use this to verify the debug info before trying to parse it.

Or if that wouldn't work, perhaps 'strip' could be adapted to embed a strong hash of the debug info in the stripped binary.

A new Debian debuginfod service

Posted Feb 26, 2021 17:11 UTC (Fri) by floppus (guest, #137245) [Link]

> Assuming the debugging symbols are signed in the same way as the packages are

They aren't; that's the problem.