1271159 - Verifiable debug symbols

Status: UNCONFIRMED

(Firefox Build System :: General, defect)

Description

[davsipt]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160502172042




Expected results:

Given the recent vulnerabilities in GNU libiberty, reported by Marcel
Böhme on oss-sec[1], and a response of

"I don't think it makes much sense to fuzz the demangler with arbitrary
binary files.  This isn't some daemon that runs 24/7 and is vulnerable
to buffer overflow attacks."[2]

I suggest that the debug symbols provided by Mozilla be GPG signed,
similar to how Mozilla products are shipped with a verifiable
SHA512SUMS.asc.

1: http://seclists.org/oss-sec/2016/q2/238

2: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687

Comment 1

[(not currently active) Ted Mielczarek]

It's an interesting idea, although I don't know how practical it is. What we do currently have is a .gnu_debuglink section in the binaries we ship that references the stripped-off debug symbols available from symbols.mozilla.org:
$ readelf -x .gnu_debuglink ~/firefox/firefox

Hex dump of section '.gnu_debuglink':
  0x00000000 66697265 666f782e 64626700 11d7795b firefox.dbg...y[

The last 4 bytes are a CRC of the debug file, per:
https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html

What I don't know is whether GDB verifies the CRC of the debug file when it loads it. That URL does also say "This computation does not apply to the “build ID” method." (in reference to the CRC).

Since we do provide signatures for the binaries we ship, we could do something simple like embed a SHA256 hash of the debug file in a special section in the binary, which would be included in the signature, so you could then verify the hash of the debug file matches the hash in the binary and be confident nothing has been changed. Extending that so that GDB does the verification for you would be a nice touch, but presumably you're already using something like https://gist.github.com/luser/193572147c401c8a965c to fetch symbols from our symbol server, so we could just do the verification there.

Comment 2

[Tom Tromey :tromey]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #1)

> What I don't know is whether GDB verifies the CRC of the debug file when it
> loads it. 

It does.  This is generally considered one of the major drawbacks of the CRC method --
it means reading debuginfo is very slow.

> That URL does also say "This computation does not apply to the
> “build ID” method." (in reference to the CRC).

Correct, build ids are not checked.  Instead they are used to find the correct separate
debug info.

> Extending that so that GDB does
> the verification for you would be a nice touch, but presumably you're
> already using something like
> https://gist.github.com/luser/193572147c401c8a965c to fetch symbols from our
> symbol server, so we could just do the verification there.

Yes, it seems to me that it would be better to verify the integrity at download time;
then once you have it locally, rely on build-id to find the correct file.

Having gdb do the verification isn't out of the question, just slow.