CVE-2017-9749

Think of objdump -D like a document reader that tries to translate a binary file into readable instructions. This bug is like a flaw in that translation step: if someone gives it a specially malformed file, the reader can crash. In a business setting, that mainly means a denial of service—your automated inspection or analysis job can fail or stop running.

This matters if you run GNU Binutils (especially objdump -D) on binaries you do not fully trust—such as files from customers, vendors, or anything coming from the internet. It’s not generally a risk just by being installed; the attacker has to be able to supply a crafted binary that your workflow then disassembles. In short: it’s a risk when objdump -D touches attacker-controlled files, not when the system is simply exposed to the internet.

Attackers have a public exploit for this issue, and it targets a common workflow step: disassembling binaries with objdump -D. Because exploitation depends on reaching the “process untrusted file with disassembler” step, this is not an automatic, internet-wide emergency—but it should be treated as a timely patch for environments that ingest untrusted files.

Confirm exposure

• Identify the exact GNU Binutils version on the systems doing disassembly:
  • Run: objdump --version and record the version.
• Identify where objdump -D is used:
  • Look for internal scripts, CI jobs, forensic tools, malware scanning pipelines, or upload-processing services that run Binutils disassembly on incoming files.
• Decide whether the inputs are attacker-influenced:
  • If you only run it on binaries produced internally (trusted build outputs), practical risk is low.
  • If you run it on uploaded/customer/vendor files, treat that as “attacker-controlled input is possible.”

Remediate

• Upgrade GNU Binutils to a version that includes the fix referenced by Sourceware bug 21586:
  • https://sourceware.org/bugzilla/show_bug.cgi?id=21586
• Apply the upgrade before expanding any automated workflows that handle untrusted uploads.
• If you have multiple environments (dev/staging/prod), patch from least to most critical, but prioritize any system that directly processes user-provided binaries.

Temporary workaround (if you can’t patch immediately)

• Stop using objdump -D on untrusted binaries until patched.
• If you must inspect binaries, isolate the disassembly step:
  • Run it in a restricted container/VM with minimal privileges, and ensure a crash can’t take down shared services.

What to monitor after upgrading

• Monitor for crashes or abnormal exits of objdump/Binutils disassembly jobs.
• If you have logs around upload-processing, watch for repeated failures on new incoming files (a sign of attempted triggering).

Severity is assessed as HIGH (reported CVSS 7.8), but the real-world risk depends on reachability: an attacker must be able to provide a crafted binary that your workflow disassembles. The weakness is consistent with CWE-119 (stack/buffer handling leading to memory corruption). The trigger is the Binutils disassembly code path using the “regs” macros in opcodes/bfin-dis.c, as exercised by running objdump -D against a crafted binary.

Exploitation context from findings: a public exploit is available, and the issue has resurfaced in press attention. KEV (CISA Known Exploited Vulnerabilities) is not listed for this CVE, so there’s no KEV-based “confirmed in-the-wild” indicator in the provided data. EPSS is listed as a prediction (flat trend), but public exploit availability and the specific trigger through disassembly are the main drivers for urgency here.