21 ms·

Linux kernel: CVE-2017-6074: DCCP double-free vulnerability (local root)

182 points by QUFB 10y ago

m00dy 10y ago
It looks legit.
0x0 10y ago
Status in Debian: https://security-tracker.debian.org/tracker/CVE-2017-6074 https://security-tracker.debian.org/tracker/CVE-2017-6074
- yourcelf 10y ago
  Status in Ubuntu: https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-6074.html https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2...
  - ptrincr 10y ago
    The below should be followed at the users own risk. Perhaps someone can confirm if the following is sane. For Ubuntu versions: Ubuntu 12.04.3 LTS Ubuntu 14.04.5 LTS The following should get you patched up, you will need a reboot though: sudo apt-get update sudo apt-get install linux-headers-3.13.0-110 linux-headers-3.13.0-110-generic linux-image-3.13.0-110-generic After reboot: uname -a Linux hostname 3.13.0-110-generic #157-Ubuntu Any Digital Ocean users may need to power down their droplet and switch the kernel to the following version: DigitalOcean GrubLoader v0.2 (20160714) Ubuntu Without this the new kernel may not be used.
    - lobster_johnson 10y ago
      Digital Ocean hasn't required that you change the kernel through the UI for some time now. Are you sure that's necessary?
      - jsamuel 10y ago
        It's only necessary for older servers (e.g. Ubuntu 12.04 and 14.04) where people haven't done this already.
        vdloo 10y ago
        you can also use the API for this https://developers.digitalocean.com/documentation/v2/#change-the-kernel https://developers.digitalocean.com/documentation/v2/#change... for example for precise the kernel ID is 7515 for the "DigitalOcean GrubLoader v0.2 (20160714) Ubuntu" kernel. If you do this be sure to double-check the id by listing the kernels using the API though. You can also do this with libcloud using 'ex_change_kernel' from the 'DigitalOcean_v2_NodeDriver'
- sp332 10y ago
  RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1423071 https://bugzilla.redhat.com/show_bug.cgi?id=1423071 Edit: I'm looking for something for CentOS but I can't even find a tracker where they put CVE's?
  - Operyl 10y ago
    CentOS should get their stuff when RedHat is finished, as is usually the case, I think.
    - kbenson 10y ago
      Yeah, just look for a kernel package the same name (including minor version numbers) as the upsteam redhat one. You can find info on Redhat Errata here[1]. CentOS looks to have some form of errata listing (possibly non-official) here[2]. You could theoretically locate teh SRPM for the kernel and build from that, but I haven't done that in years and the last I heard RedHat was going to make that harder because they weren't happy Oracle was copying their work wholesale and then selling it as a competitor, so that may be harder now? Redhat is finished, CentOS is probably just lagging a little bit. 1: https://rhn.redhat.com/errata/ https://rhn.redhat.com/errata/ 2: http://centoserrata.nagater.net/list.html http://centoserrata.nagater.net/list.html
      - Operyl 10y ago
        I use RHEL6 at work, so we already get errata notifications :).
- gghh 10y ago
  Status in SLES: https://www.suse.com/security/cve/CVE-2017-6074.html https://www.suse.com/security/cve/CVE-2017-6074.html
Wheaties466 10y ago
Let me see if I got this right, This can be used to DOS a system by consuming all free memory? In the CVE it almost hints that this specifically is UDP related. Am I right in thinking this?
- 0x0 10y ago
  It says in the post that you can execute arbitrary code in the kernel. So, full compromise of the system. (In the case of Docker, perhaps you can even escape to the root system?)
  - andrewstuart2 10y ago
    AFAIK Docker is still not considered ready to run untrusted code on shared machines. If you want to run untrusted code, you should just use a VM anyway.
    - raesene6 10y ago
      Even with a VM you need to be somewhat careful as hypervisor breakouts are not unknown.
      - jeffmcjunkin 10y ago
        Absolutely. That said, the Linux kernel is a helluva lot more attack surface than the relatively few hypercalls provided by most Type 1 hypervisors.
  - staticassertion 10y ago
    Should be able to escape docker with this. Docker provides host kernel access, so if you get the kernel you're good to go.
- geofft 10y ago
  This is a double-free vulnerability. In userspace, this would basically be void *x = malloc(16); free(x); ... free(x); When malloc makes the allocation, it actually allocates a bit more than 16 bytes so it knows how much to free. Usually what it'll do is store a structure right before the pointer it returns; for instance, it might allocate 24 bytes, use the first 8 bytes to store the number 24, and then return the rest of that allocation. Then, when free is called, it subtracts 8 from what it was given, and frees that many bytes. (More complicated malloc implementations will have more complicated structures, possibly including pointers to other, shared structures.) If you call free a second time on the same pointer, a lot of things could happen. In particular, if there was another call to malloc() in between, it might reuse that same location, and you might free that. Or if some other sequence of allocations happened, there might be a completely nonsensical number stored at x-8. If the second call "frees" data that's still in use, two parts of the program will be writing to the same memory. Maybe one thing is storing the return value of a call, and the other thing is storing the current UID. So when the first thing writes 0, now you're UID 0. Alternatively, if the second call frees something nonsensical, you might "free" memory that was never the allocator's in the first place - and cause the next call to malloc() to return a pointer to something important elsewhere in memory, perhaps even the program's stack frame. If the program then reads attacker-controlled data into that newly-allocated memory, the attacker takes over the program's control flow. DCCP is a protocol that is kind of like UDP, in that it's message-oriented, but kind of like TCP, in that it's reliable and implements congestion control. It's not very common, and uncommon networking protocols have been a historic good source of vulnerabilities in the Linux kernel.
geofft 10y ago
This is a good reason for systems running untrusted code to disable module automatic loading. Almost nobody uses DCCP, and as a result, almost nobody looks at the DCCP code, writes bad userspace apps that trigger kernel bugs that get debugged, etc. We rarely see double-frees in the TCP or UDP implementations. On my Debian kernel, CONFIG_IP_DCCP is set to "m" (in /boot/config-`uname -r`), which means that DCCP support is built as a module. The code isn't loaded until the first program tries to call socket(...IPPROTO_DCCP). At that point, the kernel will look at /proc/sys/kernel/modprobe and run that program, /sbin/modprobe by default, to load dccp.ko. Automatic module loading is great when e.g. udev runs and detects what hardware you have, but it's probably not something you'd ever need once a system has completed boot. A very simple hardening measure for machines running untrusted unprivileged code is to echo /bin/false > /proc/sys/kernel/modprobe, late in the boot process (e.g., in /etc/rc.local). The downside is that system administrator won't be able to run tools that require loading modules, of which iptables is probably the most notable one. A better option than /bin/false is a shell script that logs its arguments to syslog, e.g., `logger -p authpriv.info -- "Refused modprobe $*"`. The sysadmin can manually run modprobe on whatever module name got syslogged (or temporarily set /proc/sys/kernel/modprobe back to /sbin/modprobe). And you can alert on that syslog line to see if there's an attack in progress. (Does anyone know if it's possible to disable module auto-loading for a tree/namespace of processes, e.g. a Docker container, but keep it working for the base system?)
- amluto 10y ago
  There's a patchset called "Timgad" floating around to do exactly this.
- youdontknowtho 10y ago
  That's really good advice, thank you.
- sdeziel 10y ago
  root can undo that with echo /sbin/modprobe > /proc/sys/kernel/modprobe at any time so you are better off using: echo 1 > /proc/sys/kernel/modules_disabled
wronskian 10y ago
The diff from the patch: - goto discard; + consume_skb(skb); + return 0; One of the rare cases in the wild where a goto really was considered harmful! ;-)
- sidarape 10y ago
  Tbf, the return acts like a goto.
- deleted 10y ago
  [deleted]
- IshKebab 10y ago
  Rare? What about goto fail?
  - sp332 10y ago
    That was 3 years ago. And kernel code is covered in gotos.
  - sebcat 10y ago
    in 'goto fail', the problem looked like: if (foo() != 0) goto fail; goto fail; That extra line of code could just as likely have been a return statement or anything else. The problem was not with the goto statement itself. Edited to add: 'goto fail' is a valid construct and can be used to handle finalization in C functions. Consider: int foo(char *bar, int baz) { sometype_t *obj = NULL; int fd = -1; if ((obj = sometype_new(bar, baz)) == NULL) { goto fail; } if ((fd = open(sometype_path(obj), O_RDONLY)) < 0) { goto fail; } /* ... */ return 0; fail: if (fd < 0) { close(fd); } if (obj != NULL) { sometype_free(obj); } return -1; } There's nothing inherently wrong about that.
    - Normal_gaussian 10y ago
      It is often much clearer to use goto than using a wrapper and switching on enum'ed return value to destruct a failed transaction.
neoeldex 10y ago
I can't wait untill the linux kernel is ported to Rust ^^
- bsdnoob 10y ago
  Its never going to happen
  - disconnected 10y ago
    In the meantime, there's Redox OS: https://www.redox-os.org/ https://www.redox-os.org/
vasili111 10y ago
Does the Gentoo hardened vulnerable too?
unmole 10y ago
Here's an overview of DCCP I wrote if anyone is interested: https://www.anmolsarma.in/post/dccp/ https://www.anmolsarma.in/post/dccp/
arca_vorago 10y ago
DCCP is something even a basic hardening should already have taken care of... but of course many people don't do those. Quick solution: "echo "install dccp /bin/true" >> /etc/modprobe.d/modprobe.conf"
- frederikvs 10y ago
  what would be included in a "basic hardening"?
  - jlgaddis 10y ago
    The "Center for Internet Security" Benchmarks [0] -- such as the one for Ubuntu 16.04 (PDF) [1] -- address your question. The DISA IASE [2] publishes hundreds of "Security Technical Implementation Guides" (STIGs) for various operating systems (including several Linux distributions [3]), software applications, networking devices, and so on. The OpenSCAP [4] Security Guides [5] are also a good reference. They are primarily aimed at compliance w/ security requirements (C2S, PCI-DSS, USGCB) -- for example, the "U.S. Government Commercial Cloud Services (C2S)" [6]. I don't 100% fully implement any of these, but I have a lot of RHEL and CentOS boxes publicly accessible on the Internet and they don't become accessible until they've had the majority of these recommendations implemented. P.S. Look around. There are tons of shell scripts, Ansible roles, Puppet modules, etc., that will take care of 90% of this for you. There's no excuse for having public-facing machines that aren't locked down. [0]: https://benchmarks.cisecurity.org/downloads/benchmarks/ https://benchmarks.cisecurity.org/downloads/benchmarks/ [1]: https://benchmarks.cisecurity.org/tools2/linux/cis_ubuntu_linux_16.04_lts_benchmark_v1.0.0.pdf https://benchmarks.cisecurity.org/tools2/linux/cis_ubuntu_li... [2]: http://iase.disa.mil/Pages/index.aspx http://iase.disa.mil/Pages/index.aspx [3]: http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx [4]: https://github.com/OpenSCAP/scap-security-guide/ https://github.com/OpenSCAP/scap-security-guide/ [5]: https://www.open-scap.org/security-policies/choosing-policy/ https://www.open-scap.org/security-policies/choosing-policy/ [6]: http://static.open-scap.org/ssg-guides/ssg-rhel7-guide-C2S.html http://static.open-scap.org/ssg-guides/ssg-rhel7-guide-C2S.h...
    - 10y ago
lossolo 10y ago
Already fixed on ubuntu linux (4.4.0-64.85) xenial; urgency=low * CVE-2017-6074 (LP: #1665935) - dccp: fix freeing skb too early for IPV6_RECVPKTINFO -- Stefan Bader <stefan.bader@canonical.com> Mon, 20 Feb 2017 10:06:47
nyiihahah 10y ago
Why isn't there any Cryptocurrency for fuzzing well-known softwares? https://security.stackexchange.com/questions/152036/why-isnt-there-any-cryptocurrency-for-fuzzing-well-known-softwares https://security.stackexchange.com/questions/152036/why-isnt...
- infogulch 10y ago
  Cryptocurrencies need a relatively stable coin generation scheme. Hits from fuzzing is typically very bursty, often produces nothing, and changing the fuzzing scheme slightly can reveal completely different results. It's just too variable.
DannyBee 10y ago
syzkaller strikes again!
jlgaddis 10y ago
$ echo "install dccp /bin/true" >> /etc/modprobe.d/dccp.conf $ sudo rmmod dccp # in case it's already loaded This is a good idea for any modules you don't expect to ever need. In my case: $ cat /etc/modprobe.d/disabled_modules.conf install appletalk /bin/true install bluetooth /bin/true install cramfs /bin/true install dccp /bin/true install firewire-core /bin/true *snipped* install tipc /bin/true install udf /bin/true install usb-storage /bin/true install vfat /bin/true The original -- to me -- recommendations for this were found in some "hardening guide" for RHEL (CIS, NSA, etc.), although I don't remember which. See also the "modprobe.blacklist=" kernel parameter, which you'll have to use for "modules" that are compiled into the kernel itself (i.e., they are not actually loadable kernel modules). 15 years ago, when building your own kernels was a normal everyday thing, I simply built my kernels with everything compiled in and modules disabled. This (would have) prevented attacks such as kernel-level rootkits. In addition, "one neat trick" was that you could halt (not poweroff) the machine (!) -- such as in the case of a Linux box simply acting as a router/firewall -- and the kernel would still be running. Good luck compromising that! :-)
- tptacek 10y ago
  This is a useful post. I'm going to nerd out at you though and point out that disabling LKMs doesn't really do anything to disable kernel-resident rootkits; any kernel memory corruption vulnerability can be used to create an ad-hoc module loader. If you Google for amodload, you can find (uuencoded, in a Bugtraq message --- it's 2017 and I just uudecoded something!) Josh Daymont's old SunOS 4.1.3 modloader hack, which overwrote a kernel socket callback and used socket buffers to hold module text.
  - jlgaddis 10y ago
    > This is a useful post. I'm going to nerd out at you though and point out that disabling LKMs doesn't really do anything to disable kernel-resident rootkits; ... I really hate to question you but... are you sure? The particular case that I'm thinking of was probably ~15 years ago. There was some 0-day or worm or something (details are a little vague now, obviously) that would install a kernel module and then loaded it to hide itself. I can recall a discussion at the time and this was a recommendation. It wasn't just disabling individual modules -- it was actually disabling support for loading kernel modules. That is, whatever the kernel itself needed in order to support dynamic loading of modules at run-time was needed; the kernel was not able to load a module. Like I said, it's been probably 15 years ago and I'm sure I'm not remembering everything 100% correctly so you may very well be correct... but I'm almost certain you could entirely disable loading of kernel modules (the kernel itself didn't support loading them). Googling "amodload" now, thanks for the pointer...

182 points by QUFB 10y ago

m00dy 10y ago

It looks legit.

0x0 10y ago

Status in Debian: https://security-tracker.debian.org/tracker/CVE-2017-6074 https://security-tracker.debian.org/tracker/CVE-2017-6074

yourcelf 10y ago
Status in Ubuntu: https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-6074.html https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2...
- ptrincr 10y ago
  The below should be followed at the users own risk. Perhaps someone can confirm if the following is sane. For Ubuntu versions: Ubuntu 12.04.3 LTS Ubuntu 14.04.5 LTS The following should get you patched up, you will need a reboot though: sudo apt-get update sudo apt-get install linux-headers-3.13.0-110 linux-headers-3.13.0-110-generic linux-image-3.13.0-110-generic After reboot: uname -a Linux hostname 3.13.0-110-generic #157-Ubuntu Any Digital Ocean users may need to power down their droplet and switch the kernel to the following version: DigitalOcean GrubLoader v0.2 (20160714) Ubuntu Without this the new kernel may not be used.
  - lobster_johnson 10y ago
    Digital Ocean hasn't required that you change the kernel through the UI for some time now. Are you sure that's necessary?
    - jsamuel 10y ago
      It's only necessary for older servers (e.g. Ubuntu 12.04 and 14.04) where people haven't done this already.
      - vdloo 10y ago
        you can also use the API for this https://developers.digitalocean.com/documentation/v2/#change-the-kernel https://developers.digitalocean.com/documentation/v2/#change... for example for precise the kernel ID is 7515 for the "DigitalOcean GrubLoader v0.2 (20160714) Ubuntu" kernel. If you do this be sure to double-check the id by listing the kernels using the API though. You can also do this with libcloud using 'ex_change_kernel' from the 'DigitalOcean_v2_NodeDriver'
sp332 10y ago
RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1423071 https://bugzilla.redhat.com/show_bug.cgi?id=1423071 Edit: I'm looking for something for CentOS but I can't even find a tracker where they put CVE's?
- Operyl 10y ago
  CentOS should get their stuff when RedHat is finished, as is usually the case, I think.
  - kbenson 10y ago
    Yeah, just look for a kernel package the same name (including minor version numbers) as the upsteam redhat one. You can find info on Redhat Errata here[1]. CentOS looks to have some form of errata listing (possibly non-official) here[2]. You could theoretically locate teh SRPM for the kernel and build from that, but I haven't done that in years and the last I heard RedHat was going to make that harder because they weren't happy Oracle was copying their work wholesale and then selling it as a competitor, so that may be harder now? Redhat is finished, CentOS is probably just lagging a little bit. 1: https://rhn.redhat.com/errata/ https://rhn.redhat.com/errata/ 2: http://centoserrata.nagater.net/list.html http://centoserrata.nagater.net/list.html
    - Operyl 10y ago
      I use RHEL6 at work, so we already get errata notifications :).
gghh 10y ago
Status in SLES: https://www.suse.com/security/cve/CVE-2017-6074.html https://www.suse.com/security/cve/CVE-2017-6074.html

Wheaties466 10y ago

Let me see if I got this right, This can be used to DOS a system by consuming all free memory? In the CVE it almost hints that this specifically is UDP related. Am I right in thinking this?

0x0 10y ago
It says in the post that you can execute arbitrary code in the kernel. So, full compromise of the system. (In the case of Docker, perhaps you can even escape to the root system?)
- andrewstuart2 10y ago
  AFAIK Docker is still not considered ready to run untrusted code on shared machines. If you want to run untrusted code, you should just use a VM anyway.
  - raesene6 10y ago
    Even with a VM you need to be somewhat careful as hypervisor breakouts are not unknown.
    - jeffmcjunkin 10y ago
      Absolutely. That said, the Linux kernel is a helluva lot more attack surface than the relatively few hypercalls provided by most Type 1 hypervisors.
- staticassertion 10y ago
  Should be able to escape docker with this. Docker provides host kernel access, so if you get the kernel you're good to go.
geofft 10y ago
This is a double-free vulnerability. In userspace, this would basically be void *x = malloc(16); free(x); ... free(x); When malloc makes the allocation, it actually allocates a bit more than 16 bytes so it knows how much to free. Usually what it'll do is store a structure right before the pointer it returns; for instance, it might allocate 24 bytes, use the first 8 bytes to store the number 24, and then return the rest of that allocation. Then, when free is called, it subtracts 8 from what it was given, and frees that many bytes. (More complicated malloc implementations will have more complicated structures, possibly including pointers to other, shared structures.) If you call free a second time on the same pointer, a lot of things could happen. In particular, if there was another call to malloc() in between, it might reuse that same location, and you might free that. Or if some other sequence of allocations happened, there might be a completely nonsensical number stored at x-8. If the second call "frees" data that's still in use, two parts of the program will be writing to the same memory. Maybe one thing is storing the return value of a call, and the other thing is storing the current UID. So when the first thing writes 0, now you're UID 0. Alternatively, if the second call frees something nonsensical, you might "free" memory that was never the allocator's in the first place - and cause the next call to malloc() to return a pointer to something important elsewhere in memory, perhaps even the program's stack frame. If the program then reads attacker-controlled data into that newly-allocated memory, the attacker takes over the program's control flow. DCCP is a protocol that is kind of like UDP, in that it's message-oriented, but kind of like TCP, in that it's reliable and implements congestion control. It's not very common, and uncommon networking protocols have been a historic good source of vulnerabilities in the Linux kernel.

geofft 10y ago

This is a good reason for systems running untrusted code to disable module automatic loading. Almost nobody uses DCCP, and as a result, almost nobody looks at the DCCP code, writes bad userspace apps that trigger kernel bugs that get debugged, etc. We rarely see double-frees in the TCP or UDP implementations. On my Debian kernel, CONFIG_IP_DCCP is set to "m" (in /boot/config-`uname -r`), which means that DCCP support is built as a module. The code isn't loaded until the first program tries to call socket(...IPPROTO_DCCP). At that point, the kernel will look at /proc/sys/kernel/modprobe and run that program, /sbin/modprobe by default, to load dccp.ko. Automatic module loading is great when e.g. udev runs and detects what hardware you have, but it's probably not something you'd ever need once a system has completed boot. A very simple hardening measure for machines running untrusted unprivileged code is to echo /bin/false > /proc/sys/kernel/modprobe, late in the boot process (e.g., in /etc/rc.local). The downside is that system administrator won't be able to run tools that require loading modules, of which iptables is probably the most notable one. A better option than /bin/false is a shell script that logs its arguments to syslog, e.g., `logger -p authpriv.info -- "Refused modprobe $*"`. The sysadmin can manually run modprobe on whatever module name got syslogged (or temporarily set /proc/sys/kernel/modprobe back to /sbin/modprobe). And you can alert on that syslog line to see if there's an attack in progress. (Does anyone know if it's possible to disable module auto-loading for a tree/namespace of processes, e.g. a Docker container, but keep it working for the base system?)

amluto 10y ago
There's a patchset called "Timgad" floating around to do exactly this.
youdontknowtho 10y ago
That's really good advice, thank you.
sdeziel 10y ago
root can undo that with echo /sbin/modprobe > /proc/sys/kernel/modprobe at any time so you are better off using: echo 1 > /proc/sys/kernel/modules_disabled

wronskian 10y ago

The diff from the patch: - goto discard; + consume_skb(skb); + return 0; One of the rare cases in the wild where a goto really was considered harmful! ;-)

sidarape 10y ago
Tbf, the return acts like a goto.
deleted 10y ago
[deleted]
IshKebab 10y ago
Rare? What about goto fail?
- sp332 10y ago
  That was 3 years ago. And kernel code is covered in gotos.
- sebcat 10y ago
  in 'goto fail', the problem looked like: if (foo() != 0) goto fail; goto fail; That extra line of code could just as likely have been a return statement or anything else. The problem was not with the goto statement itself. Edited to add: 'goto fail' is a valid construct and can be used to handle finalization in C functions. Consider: int foo(char *bar, int baz) { sometype_t *obj = NULL; int fd = -1; if ((obj = sometype_new(bar, baz)) == NULL) { goto fail; } if ((fd = open(sometype_path(obj), O_RDONLY)) < 0) { goto fail; } /* ... */ return 0; fail: if (fd < 0) { close(fd); } if (obj != NULL) { sometype_free(obj); } return -1; } There's nothing inherently wrong about that.
  - Normal_gaussian 10y ago
    It is often much clearer to use goto than using a wrapper and switching on enum'ed return value to destruct a failed transaction.

neoeldex 10y ago

I can't wait untill the linux kernel is ported to Rust ^^

bsdnoob 10y ago
Its never going to happen
- disconnected 10y ago
  In the meantime, there's Redox OS: https://www.redox-os.org/ https://www.redox-os.org/

vasili111 10y ago

Does the Gentoo hardened vulnerable too?

unmole 10y ago

Here's an overview of DCCP I wrote if anyone is interested: https://www.anmolsarma.in/post/dccp/ https://www.anmolsarma.in/post/dccp/

arca_vorago 10y ago

DCCP is something even a basic hardening should already have taken care of... but of course many people don't do those. Quick solution: "echo "install dccp /bin/true" >> /etc/modprobe.d/modprobe.conf"

frederikvs 10y ago
what would be included in a "basic hardening"?
- jlgaddis 10y ago
  The "Center for Internet Security" Benchmarks [0] -- such as the one for Ubuntu 16.04 (PDF) [1] -- address your question. The DISA IASE [2] publishes hundreds of "Security Technical Implementation Guides" (STIGs) for various operating systems (including several Linux distributions [3]), software applications, networking devices, and so on. The OpenSCAP [4] Security Guides [5] are also a good reference. They are primarily aimed at compliance w/ security requirements (C2S, PCI-DSS, USGCB) -- for example, the "U.S. Government Commercial Cloud Services (C2S)" [6]. I don't 100% fully implement any of these, but I have a lot of RHEL and CentOS boxes publicly accessible on the Internet and they don't become accessible until they've had the majority of these recommendations implemented. P.S. Look around. There are tons of shell scripts, Ansible roles, Puppet modules, etc., that will take care of 90% of this for you. There's no excuse for having public-facing machines that aren't locked down. [0]: https://benchmarks.cisecurity.org/downloads/benchmarks/ https://benchmarks.cisecurity.org/downloads/benchmarks/ [1]: https://benchmarks.cisecurity.org/tools2/linux/cis_ubuntu_linux_16.04_lts_benchmark_v1.0.0.pdf https://benchmarks.cisecurity.org/tools2/linux/cis_ubuntu_li... [2]: http://iase.disa.mil/Pages/index.aspx http://iase.disa.mil/Pages/index.aspx [3]: http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx [4]: https://github.com/OpenSCAP/scap-security-guide/ https://github.com/OpenSCAP/scap-security-guide/ [5]: https://www.open-scap.org/security-policies/choosing-policy/ https://www.open-scap.org/security-policies/choosing-policy/ [6]: http://static.open-scap.org/ssg-guides/ssg-rhel7-guide-C2S.html http://static.open-scap.org/ssg-guides/ssg-rhel7-guide-C2S.h...
  - 10y ago

lossolo 10y ago

Already fixed on ubuntu linux (4.4.0-64.85) xenial; urgency=low * CVE-2017-6074 (LP: #1665935) - dccp: fix freeing skb too early for IPV6_RECVPKTINFO -- Stefan Bader <stefan.bader@canonical.com> Mon, 20 Feb 2017 10:06:47

nyiihahah 10y ago

Why isn't there any Cryptocurrency for fuzzing well-known softwares? https://security.stackexchange.com/questions/152036/why-isnt-there-any-cryptocurrency-for-fuzzing-well-known-softwares https://security.stackexchange.com/questions/152036/why-isnt...

infogulch 10y ago
Cryptocurrencies need a relatively stable coin generation scheme. Hits from fuzzing is typically very bursty, often produces nothing, and changing the fuzzing scheme slightly can reveal completely different results. It's just too variable.

DannyBee 10y ago

syzkaller strikes again!

jlgaddis 10y ago

$ echo "install dccp /bin/true" >> /etc/modprobe.d/dccp.conf $ sudo rmmod dccp # in case it's already loaded This is a good idea for any modules you don't expect to ever need. In my case: $ cat /etc/modprobe.d/disabled_modules.conf install appletalk /bin/true install bluetooth /bin/true install cramfs /bin/true install dccp /bin/true install firewire-core /bin/true *snipped* install tipc /bin/true install udf /bin/true install usb-storage /bin/true install vfat /bin/true The original -- to me -- recommendations for this were found in some "hardening guide" for RHEL (CIS, NSA, etc.), although I don't remember which. See also the "modprobe.blacklist=" kernel parameter, which you'll have to use for "modules" that are compiled into the kernel itself (i.e., they are not actually loadable kernel modules). 15 years ago, when building your own kernels was a normal everyday thing, I simply built my kernels with everything compiled in and modules disabled. This (would have) prevented attacks such as kernel-level rootkits. In addition, "one neat trick" was that you could halt (not poweroff) the machine (!) -- such as in the case of a Linux box simply acting as a router/firewall -- and the kernel would still be running. Good luck compromising that! :-)

tptacek 10y ago
This is a useful post. I'm going to nerd out at you though and point out that disabling LKMs doesn't really do anything to disable kernel-resident rootkits; any kernel memory corruption vulnerability can be used to create an ad-hoc module loader. If you Google for amodload, you can find (uuencoded, in a Bugtraq message --- it's 2017 and I just uudecoded something!) Josh Daymont's old SunOS 4.1.3 modloader hack, which overwrote a kernel socket callback and used socket buffers to hold module text.
- jlgaddis 10y ago
  > This is a useful post. I'm going to nerd out at you though and point out that disabling LKMs doesn't really do anything to disable kernel-resident rootkits; ... I really hate to question you but... are you sure? The particular case that I'm thinking of was probably ~15 years ago. There was some 0-day or worm or something (details are a little vague now, obviously) that would install a kernel module and then loaded it to hide itself. I can recall a discussion at the time and this was a recommendation. It wasn't just disabling individual modules -- it was actually disabling support for loading kernel modules. That is, whatever the kernel itself needed in order to support dynamic loading of modules at run-time was needed; the kernel was not able to load a module. Like I said, it's been probably 15 years ago and I'm sure I'm not remembering everything 100% correctly so you may very well be correct... but I'm almost certain you could entirely disable loading of kernel modules (the kernel itself didn't support loading them). Googling "amodload" now, thanks for the pointer...