BA3003: tolerate exceptions from DWARF CommandLineInfos parser#1191
BA3003: tolerate exceptions from DWARF CommandLineInfos parser#1191himaja-kesari wants to merge 2 commits into
Conversation
Some real-world ELF binaries contain DWARF producer entries that the DWARF parser does not yet understand (for example, newer DW_FORM_* values emitted by recent toolchains, or string-form references whose backing section the parser cannot resolve). When that happens, binary.CommandLineInfos throws and currently aborts BA3003 entirely for the target with an ERR998. After this change the exception is caught and the rule falls back to the symbol-table heuristic (looking for __stack_chk_fail / __stack_chk_guard / __intel_security_cookie), matching the behavior already used for ELF binaries that simply lack any DWARF compile-unit information. No behavior change for inputs whose DWARF producer tags parse successfully.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
The DWARF parser code paths reachable from CommandLineInfos throw a mix of exception types -- InvalidOperationException, NotImplementedException, ArgumentException, DwarfBufferOverreadException, and bare System.Exception (see DwarfCompilationUnit / DwarfMemoryReader / DwarfCommonInformationEntry). Because some throw the base Exception type directly, we cannot narrow this catch any further without re-introducing the ERR998 abort the parent commit set out to fix. Add a #pragma warning disable for CA1031 with an inline justification and expand the existing comment to document the constraint.
|
Addressed the CodeQL CA1031 note in 9df5035: I expanded the comment to enumerate the exception types thrown by the DWARF parser paths reachable from Because some of those call sites throw the base |
| catch (Exception) | ||
| #pragma warning restore CA1031 | ||
| { | ||
| commandLineInfos = new List<DwarfCompileCommandLineInfo>(); | ||
| } |
2 participants
Summary
When
binary.CommandLineInfosthrows while parsing DWARF producer entries, BA3003 currently aborts for the entire target with an ERR998 instead of falling back to the symbol-table heuristic the rule already has for ELF binaries with no DWARF info.This happens in practice on real-world binaries where the DWARF parser encounters producer entries it does not yet understand — e.g. newer
DW_FORM_*values emitted by recent toolchains (GCC 15 with-gdwarf-5), or string-form references whose backing section the parser cannot resolve (e.g.DW_FORM_GNU_strp_altpointing into a.gnu_debugaltlinkalt file produced bydwz).Change
Wrap the
binary.CommandLineInfosaccess in a try/catch. On exception, treat the binary as having no DWARF compile-unit information, which lets the existing symbol-table fallback (__stack_chk_fail/__stack_chk_guard/__intel_security_cookie) run as it already does for ELF binaries that simply have no DWARF info.No behavior change for inputs whose DWARF producer tags parse successfully.
Repro that motivated this
Stripped ELF binaries shipped by Azure Linux 4 (e.g.
/usr/lib/dracut/skipcpiofromdracut-107-9.azl4.x86_64.rpm) cause BinSkim 4.4.x to throwInvalidOperationException(Producer : 7969) inside BA3003 when--local-symbol-directoriesis pointed at the matching*-debuginfotree, because the producer tag in the separate.debugfile usesDW_FORM_GNU_strp_alt. With this patch the rule still cannot affirmatively validate the producer (that requires alt-file support, a separate change), but it no longer hard-fails — it falls back to the symbol heuristic, which is the documented behavior for the no-DWARF case.Testing
main(commit 696f2ba) withdotnet build src/BinSkim.Rules/BinSkim.Rules.csproj -c Release.linux-x64publish that the previously-crashing skipcpio scan now completes and falls through to the symbol check, matching the no-DWARF code path.I am happy to add a functional-test fixture if maintainers can suggest the preferred shape (a minimal ELF with a deliberately malformed producer abbrev) — the existing BA3003 test data only exercises the happy path.