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, 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." 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
Component: Untriaged → General Automation
Product: Firefox → Release Engineering
QA Contact: catlee
Version: 46 Branch → unspecified
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.
(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.
Component: General Automation → Build Config
Product: Release Engineering → Core
QA Contact: catlee
You need to log in before you can comment on or make changes to this bug.