Control: forwarded -1 https://code.wireshark.org/review/#/c/25192/2 Control: tags -1 upstream confirmed pending
Hi Jon, On Mon, Jan 8, 2018 at 7:34 AM, Jon <[email protected]> wrote: > Package: tshark > Version: 2.4.3-1 > Severity: important > Tags: patch > > Dear Maintainer, > > dumpcap unconditionally attempts to set net.core.bpf_jit_enable to 1 > when each time it runs. This is done without any consideration of the > admin's desired system configuration or the current value of > kernel.unprivileged_bpf_disabled. The only indication it has done this > is in the help output of tshark and dumpcap, it does not indicate it has > done this when you're simply running tshark/dumpcat normally. > > Since the default value of kernel.unprivileged_bpf_disabled is 0, this > means dumpcap is enabling the BPF JIT for unprivileged users. The > kernel's BPF JIT is a known attack vector for Spectre variant 1 > (CVE-2017-5753) > This is not the first security relevant CVE to occur in the BPF JIT > either, the just the 4.14 kernel has had CVE-2017-16995 and CVE-2017-16996 > > An admin who believes their kernel to be configured safely because they have > net.core.bpf_jit_enable set to 0 will rather unexpectedly find it > re-enabled (FOR UNPRIVILEGED USERS!) if they perform a packet capture > using tshark or wireshark. (AFAIK Viewing an existing packet capture does > not auto-enable the BPF JIT) > > This is true in all wireshark versions starting with 1.11.3-rc1. So this > impacts o-o-stable, o-stable, stable, testing, and sid. I'm not sure if > this wireshark behavior is in and of itself CVE worthy or not. > > I've attached a patch for Wireshark v2.4.3 that removes the offending > code entirely. A more elaborate approach which adds checks on the value > of kernel.unprivileged_bpf_disabled is possible, but I think its better > to just leave the system alone. Thank you for the patch and the detailed explanation. I forwarded a slightly modified version upstream and I'll apply it to the package shortly. Cheers, Balint
