CVE-2017-11108 - DoS in print-stp.c

[anarcat]

As part of the Debian LTS audit process, we are investigating the vulnerability in tcpdump identified with CVE-2017-11108:

tcpdump 4.9.0 allows remote attackers to cause a denial of service (heap-based buffer over-read and application crash) via crafted packet data. The crash occurs in the EXTRACT_16BITS function, called from the stp_print function for the Spanning Tree Protocol.

There was a discussion surrounding the issue in the RedHat bugtrackers, but it is unclear if the original submitter (in CC) was able to reach out to you:

https://bugzilla.redhat.com/show_bug.cgi?id=1468504

I am taking, however, what was said there at face value, however, and therefore opening a discussion surrounding this issue on this bugtracker to ensure followup.

I can confirm I have reproduced the issue in tcpdump 4.9.0 in Debian (stretch and wheezy), but cannot confirm how easily exploitable it could be. The symptoms are easily triggered by running tcpdump against the proof of concept available in the RedHat bugtrackers, under valgrind or when compiling tcpdump with ASAN.

I'm trying to figure out exactly how to fix this, at this stage. It
doesn't look like upstream responded just yet, but I can already say the
following.

1. tcpdump does try to derefence a pointer with an address value that
   is user-controlled (mstp_len) in print-stp.c:478

2. even when tcpdump doesn't crash, it fails to render the packet
   properly. with -vvv, i get this:

   STP 802.1aq, Rapid STP, CIST Flags [Learn, Forward, Agreement], length 175
       port-role Designated, CIST root-id 8000.20:bb:c0:7b:d1:2e, CIST ext-pathcost 0
       CIST regional-root-id 8000.20:bb:c0:7b:d1:2e, CIST port-id 8002,
       message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
       v3len 8, [|stp 175]
   

   notice the trailing comma there: after the v3len field, there
   would normally be other things there, but some overflow detection
   kicks in stp_print_mstp_bpdu(), which, in turns, calls the magic
   ND_TCHECK macro which detects the overflow and bails out properly

3. therefore, -vvv doesn't trigger the bug

4. conclusion: it may be simply a matter of calling the proper
   ND_TCHECK macro before dereferencing the pointer.

I think that covers most of it. Let me know if you need more information.

[infrastation]

When you created this issue, did the issue form display any boilerplate text regarding security?

[anarcat]

it did. as I mentioned in the issue, the security team seems to have been contacted by the original author, so I thought this issue was ignored. Considering the issue has been public, with a proof of concept, for more than two weeks, I figured it was fair enough to publish a patch for the issue.

I did not, as far as I know, publish additional details regarding the security issue that make it more practical to exploit.

[anarcat]

I should also mentioned this is tracked in the Debian BTS (Bug Tracking System): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867718

[infrastation]

Thank you for the heads up, this issue is already in the pipeline, we will update shortly how exactly it will be resolved.

[mcr]

anarcat <notifications@github.com> wrote: I can confirm I have reproduced the issue in tcpdump 4.9.0 in Debian (stretch and wheezy), but cannot confirm how easily exploitable it could be. The An attacker would have to be on the same L2 link, and have permission by the switching fabric to send STP packets. I would not expect that to be possible in well configured datacenters as the hosts (or VMs) ought to be on access ports rather than trunk ports. That would seem to limit it to networks in homes, small offices, etc. Not that this diminishes the seriously of it. thank you following up on this.

[infrastation]

tcpdump release 4.9.1 resolves this specific problem, which was originally discovered by Kamil Frankowicz in February 2017. Thank you very much for the report, please send any future security reports to security@tcpdump.org.