Now, distribution vendors, including us, have released kernel updates that customers/users can download and install but as always a regular kernel upgrade requires a reboot. We have had ksplice as a service for Oracle Linux support customers for quite a few years now and we also support Ubuntu and Fedora for free for anyone (see here).

One thing that is not often talked about but, I believe is very powerful and I wanted to point out here, is the following:

Typically the distribution vendors (including us) will release an update kernel that's the 'latest' version with these CVEs fixed, but many customers run older versions of both the distribution and kernels. We now see some other vendors trying to provide the basics for some online patching but by and far it's based on one-offs and for specific kernels. A big part of the ksplice service is the backend infrastructure to easily build updates for literally a few 1000 kernels. This gives customers great flexibility. You can be on one of many dot-releases of the OS and you can use ksplice. Here is a list of example kernel versions for Oracle Linux that you could be running today and we provide updates for with ksplice,for ,for instance, this DCCP bug. That's a big difference with what other folks have been trying to mimic now that online patching has become more and more important for availability.

Here is an example kernel 2.6.32-573.7.1.el6.x86_64 #1 SMP Tue Sep 22 08:34:17 PDT 2015 So that's a kernel built back in September of 2015, a random 'dot release' I run on one of my machines, and there's a ksplice patch available for these recent CVEs. I don't have to worry about having to install the 'latest' kernel, nor doing a reboot.

# uptrack-upgrade 
The following steps will be taken:
Install [f4muxalm] CVE-2017-6074: Denial-of-service when using IPV6_RECVPKTINFO socket option.
Install [5ncctcgz] CVE-2016-9555: Remote denial-of-service due to SCTP state machine memory corruption.

Go ahead [y/N]? y
Installing [f4muxalm] CVE-2017-6074: Denial-of-service when using IPV6_RECVPKTINFO socket option.
Installing [5ncctcgz] CVE-2016-9555: Remote denial-of-service due to SCTP state machine memory corruption.
Your kernel is fully up to date.
Effective kernel version is 2.6.32-642.15.1.el6

and done. That easy. My old 2.6.32-573.7.1 kernel looks like 2.6.32-642.15.1 in terms of critical fixes and CVEs.

# uptrack-show
Installed updates:
[cct5dnbf] Clear garbage data on the kernel stack when handling signals.
[ektd95cj] Reduce usage of reserved percpu memory.
[uuhgbl3e] Remote denial-of-service in Brocade Ethernet driver.
[kg3f16ii] CVE-2015-7872: Denial-of-service when garbage collecting uninstantiated keyring.
[36ng2h1l] CVE-2015-7613: Privilege escalation in IPC object initialization.
[33jwvtbb] CVE-2015-5307: KVM host denial-of-service in alignment check.
[38gzh9gl] CVE-2015-8104: KVM host denial-of-service in debug exception.
[6wvrdj93] CVE-2015-2925: Privilege escalation in bind mounts inside namespaces.
[1l4i9dfh] CVE-2016-0774: Information leak in the pipe system call on failed atomic read.
[xu4auj49] CVE-2015-5157: Disable modification of LDT by userspace processes.
[554ck5nl] CVE-2015-8767: Denial-of-service in SCTP heartbeat timeout.
[adgeye5p] CVE-2015-8543: Denial-of-service on out of range protocol for raw sockets.
[5ojkw9lv] CVE-2015-7550: Denial-of-service when reading and revoking a key concurrently.
[gfr93o7j] CVE-2015-8324: NULL pointer dereference in ext4 on mount error.
[ft01zrkg] CVE-2013-2015, CVE-2015-7509: Possible privilege escalation when mounting an non-journaled ext4 filesystem.
[87lw5yyy] CVE-2015-8215: Remote denial-of-service of network traffic when changing the MTU.
[2bby9cuy] CVE-2010-5313, CVE-2014-7842: Denial of service in KVM L1 guest from L2 guest.
[orjsp65y] CVE-2015-5156: Denial-of-service in Virtio network device.
[5j4hp0ot] Device Mapper logic error when reloading the block multi-queue.
[a1e5kxp6] CVE-2016-4565: Privilege escalation in Infiniband ioctl.
[gfpg64bh] CVE-2016-5696: Session hijacking in TCP connections.
[b4ljcwin] Message corruption in pseudo terminal output.
[prijjgt5] CVE-2016-4470: Denial-of-service in the keyring subsystem.
[4y2f30ch] CVE-2016-5829: Memory corruption in unknown USB HID devices.
[j1mivn4f] Denial-of-service when resetting a Fibre Channel over Ethernet interface.
[nawv8jdu] CVE-2016-5195: Privilege escalation when handling private mapping copy-on-write.
[97fe0h7s] CVE-2016-1583: Privilege escalation in eCryptfs.
[fdztfgcv] Denial-of-service when sending a TCP reset from the netfilter.
[gm4ldjjf] CVE-2016-6828: Use after free during TCP transmission.
[s8pymcf8] CVE-2016-7117: Denial-of-service in recvmmsg() error handling.
[1ktf7029] CVE-2016-4997, CVE-2016-4998: Privilege escalation in the Netfilter driver.
[f4muxalm] CVE-2017-6074: Denial-of-service when using IPV6_RECVPKTINFO socket option.
[5ncctcgz] CVE-2016-9555: Remote denial-of-service due to SCTP state machine memory corruption.

Effective kernel version is 2.6.32-642.15.1.el6

Here is the list of kernels we build modules for as part of Oracle Linux customers kernel choices:

oracle-2.6.18-238.0.0.0.1.el5
oracle-2.6.18-238.1.1.0.1.el5
oracle-2.6.18-238.5.1.0.1.el5
oracle-2.6.18-238.9.1.0.1.el5
oracle-2.6.18-238.12.1.0.1.el5
oracle-2.6.18-238.19.1.0.1.el5
oracle-2.6.18-274.0.0.0.1.el5
oracle-2.6.18-274.3.1.0.1.el5
oracle-2.6.18-274.7.1.0.1.el5
oracle-2.6.18-274.12.1.0.1.el5
oracle-2.6.18-274.17.1.0.1.el5
oracle-2.6.18-274.18.1.0.1.el5
oracle-2.6.18-308.0.0.0.1.el5
oracle-2.6.18-308.1.1.0.1.el5
oracle-2.6.18-308.4.1.0.1.el5
oracle-2.6.18-308.8.1.0.1.el5
oracle-2.6.18-308.8.2.0.1.el5
oracle-2.6.18-308.11.1.0.1.el5
oracle-2.6.18-308.13.1.0.1.el5
oracle-2.6.18-308.16.1.0.1.el5
oracle-2.6.18-308.20.1.0.1.el5
oracle-2.6.18-308.24.1.0.1.el5
oracle-2.6.18-348.0.0.0.1.el5
oracle-2.6.18-348.1.1.0.1.el5
oracle-2.6.18-348.2.1.0.1.el5
oracle-2.6.18-348.3.1.0.1.el5
oracle-2.6.18-348.4.1.0.1.el5
oracle-2.6.18-348.6.1.0.1.el5
oracle-2.6.18-348.12.1.0.1.el5
oracle-2.6.18-348.16.1.0.1.el5
oracle-2.6.18-348.18.1.0.1.el5
oracle-2.6.18-371.0.0.0.1.el5
oracle-2.6.18-371.1.2.0.1.el5
oracle-2.6.18-371.3.1.0.1.el5
oracle-2.6.18-371.4.1.0.1.el5
oracle-2.6.18-371.6.1.0.1.el5
oracle-2.6.18-371.8.1.0.1.el5
oracle-2.6.18-371.9.1.0.1.el5
oracle-2.6.18-371.11.1.0.1.el5
oracle-2.6.18-371.12.1.0.1.el5
oracle-2.6.18-398.0.0.0.1.el5
oracle-2.6.18-400.0.0.0.1.el5
oracle-2.6.18-400.1.1.0.1.el5
oracle-2.6.18-402.0.0.0.1.el5
oracle-2.6.18-404.0.0.0.1.el5
oracle-2.6.18-406.0.0.0.1.el5
oracle-2.6.18-407.0.0.0.1.el5
oracle-2.6.18-408.0.0.0.1.el5
oracle-2.6.18-409.0.0.0.1.el5
oracle-2.6.18-410.0.0.0.1.el5
oracle-2.6.18-411.0.0.0.1.el5
oracle-2.6.18-412.0.0.0.1.el5
oracle-2.6.18-416.0.0.0.1.el5
oracle-2.6.18-417.0.0.0.1.el5
oracle-2.6.18-418.0.0.0.1.el5
oracle-2.6.32-642.0.0.0.1.el6
oracle-3.10.0-514.6.1.0.1.el7
oracle-3.10.0-514.6.2.0.1.el7
oracle-uek-2.6.39-100.5.1
oracle-uek-2.6.39-100.6.1
oracle-uek-2.6.39-100.7.1
oracle-uek-2.6.39-100.10.1
oracle-uek-2.6.39-200.24.1
oracle-uek-2.6.39-200.29.1
oracle-uek-2.6.39-200.29.2
oracle-uek-2.6.39-200.29.3
oracle-uek-2.6.39-200.31.1
oracle-uek-2.6.39-200.32.1
oracle-uek-2.6.39-200.33.1
oracle-uek-2.6.39-200.34.1
oracle-uek-2.6.39-300.17.1
oracle-uek-2.6.39-300.17.2
oracle-uek-2.6.39-300.17.3
oracle-uek-2.6.39-300.26.1
oracle-uek-2.6.39-300.28.1
oracle-uek-2.6.39-300.32.4
oracle-uek-2.6.39-400.17.1
oracle-uek-2.6.39-400.17.2
oracle-uek-2.6.39-400.21.1
oracle-uek-2.6.39-400.21.2
oracle-uek-2.6.39-400.23.1
oracle-uek-2.6.39-400.24.1
oracle-uek-2.6.39-400.109.1
oracle-uek-2.6.39-400.109.3
oracle-uek-2.6.39-400.109.4
oracle-uek-2.6.39-400.109.5
oracle-uek-2.6.39-400.109.6
oracle-uek-2.6.39-400.209.1
oracle-uek-2.6.39-400.209.2
oracle-uek-2.6.39-400.210.2
oracle-uek-2.6.39-400.211.1
oracle-uek-2.6.39-400.211.2
oracle-uek-2.6.39-400.211.3
oracle-uek-2.6.39-400.212.1
oracle-uek-2.6.39-400.214.1
oracle-uek-2.6.39-400.214.3
oracle-uek-2.6.39-400.214.4
oracle-uek-2.6.39-400.214.5
oracle-uek-2.6.39-400.214.6
oracle-uek-2.6.39-400.215.1
oracle-uek-2.6.39-400.215.2
oracle-uek-2.6.39-400.215.3
oracle-uek-2.6.39-400.215.4
oracle-uek-2.6.39-400.215.6
oracle-uek-2.6.39-400.215.7
oracle-uek-2.6.39-400.215.10
oracle-uek-2.6.39-400.215.11
oracle-uek-2.6.39-400.215.12
oracle-uek-2.6.39-400.215.13
oracle-uek-2.6.39-400.215.14
oracle-uek-2.6.39-400.215.15
oracle-uek-2.6.39-400.243.1
oracle-uek-2.6.39-400.245.1
oracle-uek-2.6.39-400.246.2
oracle-uek-2.6.39-400.247.1
oracle-uek-2.6.39-400.248.3
oracle-uek-2.6.39-400.249.1
oracle-uek-2.6.39-400.249.3
oracle-uek-2.6.39-400.249.4
oracle-uek-2.6.39-400.250.2
oracle-uek-2.6.39-400.250.4
oracle-uek-2.6.39-400.250.5
oracle-uek-2.6.39-400.250.6
oracle-uek-2.6.39-400.250.7
oracle-uek-2.6.39-400.250.9
oracle-uek-2.6.39-400.250.10
oracle-uek-2.6.39-400.250.11
oracle-uek-2.6.39-400.264.1
oracle-uek-2.6.39-400.264.4
oracle-uek-2.6.39-400.264.5
oracle-uek-2.6.39-400.264.6
oracle-uek-2.6.39-400.264.13
oracle-uek-2.6.39-400.276.1
oracle-uek-2.6.39-400.277.1
oracle-uek-2.6.39-400.278.1
oracle-uek-2.6.39-400.278.2
oracle-uek-2.6.39-400.278.3
oracle-uek-2.6.39-400.280.1
oracle-uek-2.6.39-400.281.1
oracle-uek-2.6.39-400.282.1
oracle-uek-2.6.39-400.283.1
oracle-uek-2.6.39-400.283.2
oracle-uek-2.6.39-400.284.1
oracle-uek-2.6.39-400.284.2
oracle-uek-2.6.39-400.286.2
oracle-uek-2.6.39-400.286.3
oracle-uek-2.6.39-400.290.1
oracle-uek-2.6.39-400.290.2
oracle-uek-2.6.39-400.293.1
oracle-uek-2.6.39-400.293.2
oracle-uek-2.6.39-400.294.1
oracle-uek-2.6.39-400.294.2
oracle-uek-2.6.39-400.128.21
oracle-uek-3.8.13-16
oracle-uek-3.8.13-16.1.1
oracle-uek-3.8.13-16.2.1
oracle-uek-3.8.13-16.2.2
oracle-uek-3.8.13-16.2.3
oracle-uek-3.8.13-16.3.1
oracle-uek-3.8.13-26
oracle-uek-3.8.13-26.1.1
oracle-uek-3.8.13-26.2.1
oracle-uek-3.8.13-26.2.2
oracle-uek-3.8.13-26.2.3
oracle-uek-3.8.13-26.2.4
oracle-uek-3.8.13-35
oracle-uek-3.8.13-35.1.1
oracle-uek-3.8.13-35.1.2
oracle-uek-3.8.13-35.1.3
oracle-uek-3.8.13-35.3.1
oracle-uek-3.8.13-35.3.2
oracle-uek-3.8.13-35.3.3
oracle-uek-3.8.13-35.3.4
oracle-uek-3.8.13-35.3.5
oracle-uek-3.8.13-44
oracle-uek-3.8.13-44.1.1
oracle-uek-3.8.13-44.1.3
oracle-uek-3.8.13-44.1.4
oracle-uek-3.8.13-44.1.5
oracle-uek-3.8.13-55
oracle-uek-3.8.13-55.1.1
oracle-uek-3.8.13-55.1.2
oracle-uek-3.8.13-55.1.5
oracle-uek-3.8.13-55.1.6
oracle-uek-3.8.13-55.1.8
oracle-uek-3.8.13-55.2.1
oracle-uek-3.8.13-68
oracle-uek-3.8.13-68.1.2
oracle-uek-3.8.13-68.1.3
oracle-uek-3.8.13-68.2.2
oracle-uek-3.8.13-68.2.2.1
oracle-uek-3.8.13-68.2.2.2
oracle-uek-3.8.13-68.3.1
oracle-uek-3.8.13-68.3.2
oracle-uek-3.8.13-68.3.3
oracle-uek-3.8.13-68.3.4
oracle-uek-3.8.13-68.3.5
oracle-uek-3.8.13-98
oracle-uek-3.8.13-98.1.1
oracle-uek-3.8.13-98.1.2
oracle-uek-3.8.13-98.2.1
oracle-uek-3.8.13-98.2.2
oracle-uek-3.8.13-98.4.1
oracle-uek-3.8.13-98.5.2
oracle-uek-3.8.13-98.6.1
oracle-uek-3.8.13-98.7.1
oracle-uek-3.8.13-98.8.1
oracle-uek-3.8.13-118
oracle-uek-3.8.13-118.2.1
oracle-uek-3.8.13-118.2.2
oracle-uek-3.8.13-118.2.4
oracle-uek-3.8.13-118.2.5
oracle-uek-3.8.13-118.3.1
oracle-uek-3.8.13-118.3.2
oracle-uek-3.8.13-118.4.1
oracle-uek-3.8.13-118.4.2
oracle-uek-3.8.13-118.6.1
oracle-uek-3.8.13-118.6.2
oracle-uek-3.8.13-118.7.1
oracle-uek-3.8.13-118.8.1
oracle-uek-3.8.13-118.9.1
oracle-uek-3.8.13-118.9.2
oracle-uek-3.8.13-118.10.2
oracle-uek-3.8.13-118.11.2
oracle-uek-3.8.13-118.13.2
oracle-uek-3.8.13-118.13.3
oracle-uek-3.8.13-118.14.1
oracle-uek-3.8.13-118.14.2
oracle-uek-3.8.13-118.15.1
oracle-uek-3.8.13-118.15.2
oracle-uek-3.8.13-118.15.3
oracle-uek-3.8.13-118.16.2
oracle-uek-3.8.13-118.16.3
oracle-uek-4.1.12-32
oracle-uek-4.1.12-32.1.2
oracle-uek-4.1.12-32.1.3
oracle-uek-4.1.12-32.2.1
oracle-uek-4.1.12-32.2.3
oracle-uek-4.1.12-37.2.1
oracle-uek-4.1.12-37.2.2
oracle-uek-4.1.12-37.3.1
oracle-uek-4.1.12-37.4.1
oracle-uek-4.1.12-37.5.1
oracle-uek-4.1.12-37.6.1
oracle-uek-4.1.12-37.6.2
oracle-uek-4.1.12-37.6.3
oracle-uek-4.1.12-61.1.6
oracle-uek-4.1.12-61.1.9
oracle-uek-4.1.12-61.1.10
oracle-uek-4.1.12-61.1.13
oracle-uek-4.1.12-61.1.14
oracle-uek-4.1.12-61.1.16
oracle-uek-4.1.12-61.1.17
oracle-uek-4.1.12-61.1.18
oracle-uek-4.1.12-61.1.19
oracle-uek-4.1.12-61.1.21
oracle-uek-4.1.12-61.1.22
oracle-uek-4.1.12-61.1.23
oracle-uek-4.1.12-61.1.24
oracle-uek-4.1.12-61.1.25
oracle-uek-4.1.12-61.1.27
rhel-2.6.32-71.el6
rhel-2.6.32-71.7.1.el6
rhel-2.6.32-71.14.1.el6
rhel-2.6.32-71.18.1.el6
rhel-2.6.32-71.18.2.el6
rhel-2.6.32-71.24.1.el6
rhel-2.6.32-71.29.1.el6
rhel-2.6.32-131.0.15.el6
rhel-2.6.32-131.2.1.el6
rhel-2.6.32-131.4.1.el6
rhel-2.6.32-131.6.1.el6
rhel-2.6.32-131.12.1.el6
rhel-2.6.32-131.17.1.el6
rhel-2.6.32-131.21.1.el6
rhel-2.6.32-220.el6
rhel-2.6.32-220.2.1.el6
rhel-2.6.32-220.4.1.el6
rhel-2.6.32-220.4.2.el6
rhel-2.6.32-220.7.1.el6
rhel-2.6.32-220.13.1.el6
rhel-2.6.32-220.17.1.el6
rhel-2.6.32-220.23.1.el6
rhel-2.6.32-279.el6
rhel-2.6.32-279.1.1.el6
rhel-2.6.32-279.2.1.el6
rhel-2.6.32-279.5.1.el6
rhel-2.6.32-279.5.2.el6
rhel-2.6.32-279.9.1.el6
rhel-2.6.32-279.11.1.el6
rhel-2.6.32-279.14.1.el6
rhel-2.6.32-279.19.1.el6
rhel-2.6.32-279.22.1.el6
rhel-2.6.32-358.el6
rhel-2.6.32-358.0.1.el6
rhel-2.6.32-358.2.1.el6
rhel-2.6.32-358.6.1.el6
rhel-2.6.32-358.6.2.el6
rhel-2.6.32-358.6.2.el6.x86_64.crt1
rhel-2.6.32-358.11.1.el6
rhel-2.6.32-358.14.1.el6
rhel-2.6.32-358.18.1.el6
rhel-2.6.32-358.23.2.el6
rhel-2.6.32-431.el6
rhel-2.6.32-431.1.2.el6
rhel-2.6.32-431.3.1.el6
rhel-2.6.32-431.5.1.el6
rhel-2.6.32-431.11.2.el6
rhel-2.6.32-431.17.1.el6
rhel-2.6.32-431.20.3.el6
rhel-2.6.32-431.20.5.el6
rhel-2.6.32-431.23.3.el6
rhel-2.6.32-431.29.2.el6
rhel-2.6.32-504.el6
rhel-2.6.32-504.1.3.el6
rhel-2.6.32-504.3.3.el6
rhel-2.6.32-504.8.1.el6
rhel-2.6.32-504.12.2.el6
rhel-2.6.32-504.16.2.el6
rhel-2.6.32-504.23.4.el6
rhel-2.6.32-504.30.3.el6
rhel-2.6.32-573.el6
rhel-2.6.32-573.1.1.el6
rhel-2.6.32-573.3.1.el6
rhel-2.6.32-573.7.1.el6
rhel-2.6.32-573.8.1.el6
rhel-2.6.32-573.12.1.el6
rhel-2.6.32-573.18.1.el6
rhel-2.6.32-573.22.1.el6
rhel-2.6.32-573.26.1.el6
rhel-2.6.32-642.el6
rhel-2.6.32-642.1.1.el6
rhel-2.6.32-642.3.1.el6
rhel-2.6.32-642.4.2.el6
rhel-2.6.32-642.6.1.el6
rhel-2.6.32-642.6.2.el6
rhel-2.6.32-642.11.1.el6
rhel-2.6.32-642.13.1.el6
rhel-2.6.32-642.13.2.el6
rhel-3.10.0-123.el7
rhel-3.10.0-123.1.2.el7
rhel-3.10.0-123.4.2.el7
rhel-3.10.0-123.4.4.el7
rhel-3.10.0-123.6.3.el7
rhel-3.10.0-123.8.1.el7
rhel-3.10.0-123.9.2.el7
rhel-3.10.0-123.9.3.el7
rhel-3.10.0-123.13.1.el7
rhel-3.10.0-123.13.2.el7
rhel-3.10.0-123.20.1.el7
rhel-3.10.0-229.el7
rhel-3.10.0-229.1.2.el7
rhel-3.10.0-229.4.2.el7
rhel-3.10.0-229.7.2.el7
rhel-3.10.0-229.11.1.el7
rhel-3.10.0-229.14.1.el7
rhel-3.10.0-229.20.1.el6.x86_64.knl2
rhel-3.10.0-229.20.1.el7
rhel-3.10.0-327.el7
rhel-3.10.0-327.3.1.el7
rhel-3.10.0-327.4.4.el7
rhel-3.10.0-327.4.5.el7
rhel-3.10.0-327.10.1.el7
rhel-3.10.0-327.13.1.el7
rhel-3.10.0-327.18.2.el7
rhel-3.10.0-327.22.2.el7
rhel-3.10.0-327.28.2.el7
rhel-3.10.0-327.28.3.el7
rhel-3.10.0-327.36.1.el7
rhel-3.10.0-327.36.2.el7
rhel-3.10.0-327.36.3.el7
rhel-3.10.0-514.el7
rhel-3.10.0-514.2.2.el7
rhel-3.10.0-514.6.1.el7
rhel-3.10.0-514.6.2.el7
rhel-2.6.18-92.1.10.el5
rhel-2.6.18-92.1.13.el5
rhel-2.6.18-92.1.17.el5
rhel-2.6.18-92.1.18.el5
rhel-2.6.18-92.1.22.el5
rhel-2.6.18-128.el5
rhel-2.6.18-128.1.1.el5
rhel-2.6.18-128.1.6.el5
rhel-2.6.18-128.1.10.el5
rhel-2.6.18-128.1.14.el5
rhel-2.6.18-128.1.16.el5
rhel-2.6.18-128.2.1.el5
rhel-2.6.18-128.4.1.el5
rhel-2.6.18-128.7.1.el5
rhel-2.6.18-149.el5
rhel-2.6.18-164.el5
rhel-2.6.18-164.2.1.el5
rhel-2.6.18-164.6.1.el5
rhel-2.6.18-164.9.1.el5
rhel-2.6.18-164.10.1.el5
rhel-2.6.18-164.11.1.el5
rhel-2.6.18-164.15.1.el5
rhel-2.6.18-194.el5
rhel-2.6.18-194.3.1.el5
rhel-2.6.18-194.8.1.el5
rhel-2.6.18-194.11.1.el5
rhel-2.6.18-194.11.3.el5
rhel-2.6.18-194.11.4.el5
rhel-2.6.18-194.17.1.el5
rhel-2.6.18-194.17.4.el5
rhel-2.6.18-194.26.1.el5
rhel-2.6.18-194.32.1.el5
rhel-2.6.18-238.el5
rhel-2.6.18-238.1.1.el5
rhel-2.6.18-238.5.1.el5
rhel-2.6.18-238.9.1.el5
rhel-2.6.18-238.12.1.el5
rhel-2.6.18-238.19.1.el5
rhel-2.6.18-274.el5
rhel-2.6.18-274.3.1.el5
rhel-2.6.18-274.7.1.el5
rhel-2.6.18-274.12.1.el5
rhel-2.6.18-274.17.1.el5
rhel-2.6.18-274.18.1.el5
rhel-2.6.18-308.el5
rhel-2.6.18-308.1.1.el5
rhel-2.6.18-308.4.1.el5
rhel-2.6.18-308.8.1.el5
rhel-2.6.18-308.8.2.el5
rhel-2.6.18-308.11.1.el5
rhel-2.6.18-308.13.1.el5
rhel-2.6.18-308.16.1.el5
rhel-2.6.18-308.20.1.el5
rhel-2.6.18-308.24.1.el5
rhel-2.6.18-348.el5
rhel-2.6.18-348.1.1.el5
rhel-2.6.18-348.2.1.el5
rhel-2.6.18-348.3.1.el5
rhel-2.6.18-348.4.1.el5
rhel-2.6.18-348.6.1.el5
rhel-2.6.18-348.12.1.el5
rhel-2.6.18-348.16.1.el5
rhel-2.6.18-348.18.1.el5
rhel-2.6.18-371.el5
rhel-2.6.18-371.1.2.el5
rhel-2.6.18-371.3.1.el5
rhel-2.6.18-371.4.1.el5
rhel-2.6.18-371.6.1.el5
rhel-2.6.18-371.8.1.el5
rhel-2.6.18-371.9.1.el5
rhel-2.6.18-371.11.1.el5
rhel-2.6.18-371.12.1.el5
rhel-2.6.18-398.el5
rhel-2.6.18-400.el5
rhel-2.6.18-400.1.1.el5
rhel-2.6.18-402.el5
rhel-2.6.18-404.el5
rhel-2.6.18-406.el5
rhel-2.6.18-407.el5
rhel-2.6.18-408.el5
rhel-2.6.18-409.el5
rhel-2.6.18-410.el5
rhel-2.6.18-411.el5
rhel-2.6.18-412.el5
rhel-2.6.18-416.el5
rhel-2.6.18-417.el5
rhel-2.6.18-418.el5

compare that to kpatch or kgraft or so.

I published the following diary on isc.sans.org: “Analysis of a Simple PHP Backdoor“.

With the huge surface attack provided by CMS like Drupal or WordPress, webshells remain a classic attack scenario. A few months ago, I wrote a diary about the power of webshells. A few days ago, a friend of mine asked me some help about an incident he was investigating. A website was compromised (no magic – very bad admin password) and a backdoor was dropped. He sent a copy of the malicious file… [Read more]

[The post [SANS ISC Diary] Analysis of a Simple PHP Backdoor has been first published on /dev/random]

The post Mitigating PHP’s long standing issue with OPCache leaking sensitive data appeared first on ma.ttias.be.

A very old security vulnerability has been fixed in PHP regarding the way it handles its OPCaches in environments where a single master process shares multiple PHP-FPM pools. This is the most common way to run PHP nowadays and might affect you, too.

The vulnerability

PHP has a method to speed up the dynamic nature of its interpreter, called bytecode caching. PHP gets interpreted on every pageload, meaning the PHP gets translated to bytecode which the server understands and can execute. Since most PHP pages don't change every second, PHP caches that bytecode in memory and can serve that as the response instead of having to compile (or "interpret") the PHP scripts every time.

In a default PHP-FPM setup, the process tree looks like this.

php-fpm: master process (/etc/php-fpm.conf)
\_ php-fpm: pool site1 (uid: 701)
\_ php-fpm: pool site2 (uid: 702)
\_ php-fpm: pool site3 (uid: 703)

There is a single PHP-FPM master process that gets started as the root user. It then spawns additional FPM pools, that can each run as their own user, to serve websites. The PHP OPCache (that bytecode cache) is held in the master process.

So here's the problem: PHP does not validate the userid when it fetches a script from memory, stored in its bytecode. The concept of a "shared memory" in PHP means everything is stored in the same memory segment, and including a file just checks if a version already exists in bytecode.

If a version of the script exists in bytecode, it's served without additional check.

If a version of the script does not exist in bytecode, the FPM pool (running as an unprivileged uid) will try to read it from disk, and Linux will prevent reads from files that the process has no access to. You know, like it's supposed to happen.

This is the one of the primary reasons I've advocated running multiple masters instead of multiple pools for years.

The solution: upgrade PHP & set additional configurations

After a way too long period, this bug is now resolved and you can fix it with additional master configurations.

$ cat /etc/php-fpm.conf
...
opcache.validate_permission (default "0")
       Leads OPcache to check file readability on each access to cached file.
       This directive should be enabled in shared hosting environment, when few
       users (PHP-FPM pools) reuse the common OPcache shared memory.

opcache.validate_root (default "0")
       This directive prevents file name collisions in different "chroot"
       environments. It should be enabled for sites that may serve requests in
       different "chroot" environments.

The introduction of the opcache.validate_permission and opcache.validate_root means you can now force PHP's OPCache to also check the permissions of the file and force a validation of the root path of the file, to avoid chrooted environments from reading eachothers' files (more on that in the original bugreport).

The default values, however, are insecure.

I understand why they are like this, to keep compatibility with previous versions and avoid breaking changes in minor versions, but you have to explicitly enable them to prevent this behaviour.

Minimum versions: PHP 5.6.29, 7.0.14, 7.1.0

This fix didn't get much attention and I only noticed it after someone posted to the oss-security mailing list. To mitigate this properly, you'll need at least;

• 5.6.29
• 7.0.14
• 7.1.0

Anything lower than 5.6 is already end of life and won't get this fix, even though OPCache got introduced in PHP 5.5. You'll need a recent 5.6 or newer to mitigate this.

If you still run PHP 5.5 (which many do) and want to be safe, your best bet is to either run multiple PHP masters (a single master per pool) or disable OPCache entirely.

Indirect local privilege escalation to root

This has been a long standing issue with PHP that's actually more serious than it looks at first glance.

If you manage to compromise a single website (which for most CMS's in PHP that don't get updated, isn't very hard), this shared memory allows you access to all other websites, if their pages have been cached in the OPCache.

You can effectively use this shared memory buffer as a passage way to read other website's PHP files, read their configs, get access to their database and steal all their data. To do so, you usually need root access to a server, but PHP's OPCache gives you a convenient shortcut to accomplish similar things.

All you need is the path to their files, which can either be retrieved via opcache_get_status() (if enabled, which again -- it is by default), or you can guess the paths, which on shared hosting environments usually isn't hard either.

This actually makes this shared memory architecture almost as bad as a local privilege escalation vulnerability, depending on what you want to accomplish. If your goal is to steal data from a server that normally requires root privileges, you got it.

If your goal is to actually get root and run root-only scripts (aka: bind on lower ports etc.), that won't be possible.

The good part is, there's now a fix with the new PHP configurations. The bad news is, you need to update to the latest releases to get it and explicitly enable it.

Additional sources

For your reading pleasure:

• #69090 add prefix/xor to cache keys/check permissions or separate caches
• #69090 readme commit
• CVE Request: PHP with Zend OPCache code permission/sensitive data protection vulnerability

The post Mitigating PHP’s long standing issue with OPCache leaking sensitive data appeared first on ma.ttias.be.

Nellio, Eva, Max et Junior sont dans la zone contrôlée par le conglomérat industriel.

Dans un silence religieux, nous descendons tous les quatre de la voiture. Tout autour de nous, des immeubles s’élancent dans une architecture torturée donnant une impression d’espace et de vide. Pas la moindre fissure, pas la moindre poussière. Même les plantes ornementales semblent se cantonner dans le rôle restreint et artificiel de nature morte. J’ai l’étrange impression d’être dans une simulation, un rendu 3D d’un projet d’architecture comme on en trouve sur les affiches jouxtant des terrains vagues d’où doivent, bientôt, naître de merveilleux projets immobiliers aux noms évocateurs.

Il me faut un certain temps avant de réaliser qu’aucune publicité n’est visible. Pourtant, les formes des bâtiments s’éloignent avec une certaine élégance d’un fonctionnalisme trop strict. Les murs s’élancent avec une certaine recherche esthétique où les motifs en fractale semblent occuper une place prépondérante.

Une brise un peu brusque dépose soudainement une fine feuille de plastique sur laquelle se distingue difficilement le logo d’une marque de chocolat.

La feuille se pose sur le trottoir et semble s’y enfoncer doucement, comme un fin navire de papier sombrant dans une écume solide.

Je pousse une exclamation de surprise. Junior s’accroupit.

— Du smart sand ! Tout le complexe est en smart sand !

D’un geste de la main, il donne quelques instructions à Max. Obtempérant, celui-ci donne un violent coup dans le mur de béton en utilisant une partie métallique de son corps. Le mur semble s’effriter légèrement. Un trou bien visible se dessine et le sable se met à couler avant de s’arrêter et, sous mes yeux ébahis, de se mettre à escalader le mur pour reboucher le trou. Quelques secondes s’écoulent et le mur semble comme neuf !

Je me tourne vers mes compagnons :

– Je croyais que ce smartsand n’était encore qu’à l’état de prototype. Mais si tout le complexe en est construit, cela a des implications profondes.

Junior me lance un regard étonné.

— C’est impressionnant mais je ne vois pas trop…
— Cela signifie que le bâtiment s’est imprimé tout seul. Un architecte a dessiné les plans et le bâtiment est sorti de terre sans aucune assistance humaine.
— Oui mais où est le problème ?
— Que tout ce complexe peut avoir existé depuis des années ou n’être qu’un leurre, créé de toutes pièces dans les dernières vingt-quatre heures.
— Quel genre de piège ? interroge Max.
— Le bâtiment peut se modifier en fonction de certains stimuli pré-programmés. Nous pouvons très bien nous retrouver enfermés.
— Nous le serions déjà, murmure Eva. Toute la route est dans la même matière et aurait pu nous engloutir.

Je me tourne vers elle.

— Eva, tu m’as dit que tu connaissais FatNerdz. C’est lui qui nous a emmené ici. Peut-on lui faire confiance ?

— Confiance ?

Elle bégaie légèrement, sa lèvre inférieure tremble.

— Il ne s’agit pas de confiance mais uniquement de logique. Tu n’es pas mort, Nellio. Cette seule information devrait te suffire.

Bravement, elle s’avance vers une porte vitrée et, sous mes yeux ahuris, passe simplement à travers comme s’il s’agissait d’un hologramme. Junior exulte !

– Wow ! Du smart glass ! Génial ! Il fond instantanément et se reforme. C’est impressionnant.

Sans hésiter, nous emboitons le pas à Eva. Après tout, nous sommes désormais sous le contrôle total du bâtiment. S’il doit nous arriver quelque chose, il est déjà trop tard.

En franchissant la porte, j’ai l’impression de passer sous une fine chute d’eau. Un léger contact qui s’estompe immédiatement.

Je rejoins Eva, talonné par Max et Junior. Je sens comme une légère vibration et un pincement au creux de l’estomac.

— Nous montons ! Le bâtiment nous pousse vers le haut sans avoir besoin d’un ascenseur. C’est aaaaaah…

Sans prendre la peine de finir sa phrase, Junior se met à hurler. Paniqué, il nous désigne à grand renfort de geste ses pieds. Où plutôt l’endroit où aurait du se trouver ses pieds. À lieu et place de ses chaussures, je vois deux tibias s’enfoncer parfaitement dans le sol.

— Tu t’enfonces ! crie Eva.
— Non, le sol monte mais sans lui, corrige Max de sa voix artificiellement calme et posée.
— Ce n’est vraiment pas le moment d’argumenter à ce sujet, fais-je en me ruant sur Junior.
— Merde ! Merde ! crie ce dernier. Je sens que ça monte.

En effet, le sol est désormais dans la partie supérieure de ses mollets.

— Mais c’est quoi ? Une sorte de sable mouvant ?
— Non, répond Eva. Le bâtiment sais exactement ce qu’il fait.

Comme en écho, une image se forme sur un mur. Une fiche d’identité apparaît avec une photo de Junior, en uniforme, un numéro de matricule et un ensemble de méta-données sur sa vie et sa carrière. En rouge clignote une ligne « Policier déserteur. Dangereux. Protection totale requise. »

Je sens la panique me gagner. Machinalement, je m’approche de Junior pour tenter de le tirer vers le haut. Il hurle de douleur. Sans dire un mot, nous nous affairons tous les trois mais sans succès. Le sol arrive désormais presqu’à la taille de Junior qui se calme subitement.

— Cela devait finir comme cela. Protection totale. Je suis donc à ce point dangereux que toute action est justifiée pour me mettre hors d’état de nuire.
— Il faut faire quelque chose, dis-je. Max, ne peux-tu pas tenter de creuser le béton et que nous le portons au-dessus de nous ?

Eva, qui s’est reculée, me regarde froidement.
— C’est inutile, Nellio. Nous sommes complètement sous l’emprise du bâtiment. Il n’y a rien à faire.
— Mais…

Je tourne la tête vers Junior. Celui-ci tente de me rendre un regard brave. Le sol a désormais dépassé son nombril. Sa respiration se fait plus difficile.

— Je le savais, murmure-t-il. J’étais en sursis. Je suis néanmoins fier. Mais il y’a une chose que je ne comprends pas. Pourquoi suis-je le seul ? Qu’avez-vous de différent ?

Eva s’accroupit pour se mettre à son niveau.
— Cet immeuble est confiant et n’utilise qu’une protection positive : seuls les cas confirmés sont éliminés. Les autres peuvent circuler sans autorisation particulière.
— Ça ne tient pas debout ! Pourquoi serais-je le seul listé ?

Eva réfléchit un instant avant de répondre.

— Parce que tu es un policier déserteur, tu as été repéré. Mais pour les bases de données civiles, Max et Nellio sont morts. Moi, je n’existe tout simplement pas. Ces deux cas ne rentrent probablement dans aucune des conditions du programme de l’immeuble et, par défaut, il prend le programme automatique du personnel autorisé. C’est une énorme faille de sécurité, le programmeur a du pondre ça avec les pieds mais son bug serait passé inaperçu si deux morts et un non-être ne s’étaient pas pointés.

Je pousse une exclamation de surprise mais je n’ai pas le temps d’aller plus loin que Junior pousse un cri. Il vient de constate que sa main droite, qu’il a bougé en parlant, a également commencé à s’enfoncer. Les doigts sont désormais pris dans le sol. Désespérément il tente de lever le bras gauche et de faire des mouvements pour se dégager. Son corps est désormais enfoncé au delà du plexus solaire. Il se débat laborieusement en poussant des petits cris.

— On ne peut pas rester là sans rien faire à le regarder crever d’une mort horrible ? fais-je en tentant de secouer les bras de Max et Eva.
— Visiblement si, répond laconiquement Max.
— Mais…

Paralysé par l’angoisse, j’observe le niveau du sol engloutir les épaules de mon ami, commencer à monter au niveau du cou. Il penche la tête en arrière dans un ultime espoir de gagner du temps. La pression sur ses poumons doit être énorme, il halète en poussant de petits cris aigus.

— Junior, fais-je. Je… Je… Tu es mon ami !

Le visage est désormais au niveau même du sol, comme un hideux bas-relief. Le smart sand commence à emplir la bouche de Junior dont les yeux reflètent une terreur pure, brute. Une terreur abjectes qui me figent et arrêtent les battements de mon cœur.

Le souffle coupé, je reste immobile, paralysé, les yeux rivés sur un sol propre et lisse.

Photo par Frans de Wit.

Ce texte est a été publié grâce à votre soutien régulier sur Tipeee et sur Paypal. Je suis @ploum, blogueur, écrivain, conférencier et futurologue. Vous pouvez me suivre sur Facebook, Medium ou me contacter.

Ce texte est publié sous la licence CC-By BE.

The post DNS Spy enters public beta appeared first on ma.ttias.be.

Here's an exciting announcement I've been dying to make: DNS Spy, a new DNS monitoring and alerting tool I've been working on, has entered public beta!

After several months of development and a 3 month private, invite-only, alpha period, DNS Spy is now publicly available to anyone to try it out.

What is DNS Spy?

I'm glad you ask!

DNS Spy is a custom solution for monitoring, alerting and tracking your DNS changes. It was built primarily out of convenience for the following use cases;

• Get notified when a project I'm working on changes its DNS (usually for the go-live of a new website or application)
• Get notified when one of my domains has nameserver records that are out-of-sync because zone transfers failed or the SOA didn't get updated properly
• Get a back-up of all my DNS records per domain in a convenient format, a necessity that became clear after the massive Dyn DNS DDoS attacks

DNS Spy will never be a tool for the masses. It's a tool for sysadmins, developers and managers that are paranoid about their DNS.

In fact, it's built upon a tool I created more than 6 years ago that did one, simple thing: send me an e-mail whenever a DNS record I cared about, changes value. This is the same tool, on steroids.

Free for Open Source projects

One thing I'm very paranoid about, is the current state of our Open Source projects. While a lot of them have big companies supporting them, the majority is run by volunteers doing everything they can to keep things running.

But due to the nature of Open Source, those projects might become hugely popular on purpose or by accident. Imagine operating a project that's used as a library in an OS, a popular tool or a framework. Suddenly your code gets used in thousands if not millions of applications or hardware.

What would happen if someone managed to hijack your DNS records and set up a phishing site, similar to yours? Would you know? Would your auto-updaters know? Or the package builders that download your .tar.gz files and include your code in their own projects?

I seriously worry about the current state of our DNS and domain names for open source projects. That's why I offer a lifetime premium account to DNS Spy for any open source project maintainer to help secure and monitor their projects.

If someone hijacks your DNS or you make modifications with unexpected results, I hope DNS Spy can offer a solution or guidance.

Feedback, please!

Since it's still in active development, I'm very much looking for feedback, bug reports and enhancements! If you spot anything, do let me know!

And if you'd like to do me a favor, spread word of DNS Spy to colleagues, open source maintainers and internet geeks -- I can use all the publicity in the world. ;-)

The post DNS Spy enters public beta appeared first on ma.ttias.be.

At Config Management Camp, James was once again presenting mgmt. He presented the project one year ago, on his blog. There are multiple ideas behind mgmt (as you can read on his blog):

• Parallel execution
• Event driven
• Distributed topology

And all of that makes a lot of sense. I really like it. I do really think that this might become a huge deal in the future. But there are a couple of concerns I would like to raise.

It is James’ project

James has been developing it since 2013. His ideas are great, however the project is still at its very beginning, not usable yet, even for the more brave out there. The fact that it is so early and that even early adopters have a lot to do, makes it difficult to contribute. Even if there are 20 code contributors to the project, James is the one that does most of the job.

I do like the fact that James knows Puppet very well. It means we speak the same languages, he knows the problem Puppet users face, and is one of the best people to challenge the config management community.

How to improve that: get involved, code, try… We need to bring this to a more stable and usable shape before we can drag more and more contributors.

It is scary because it is fast

With traditional configuration management, when you screw up some thing, you still have the time to fix your configuration before it is applied everywhere. Puppet running every 30 minutes is a good example. You have a chance to fix some things in emergency before everyone gets them.

Even ansible is an order of magnitude slower than mgmt. And that makes it scary.

How to improve that: we might be able to tell mgmt to do canary releases. That would be awesome, something really great for the future of mgmt. It is quite hard to do so with traditional config management, but it might become native in the future with mgmt. That would be awesome.

It is hard to understand

mgmt internals are not as easy to understand as other tools. You can be scary at first sight. It is using directed acyclic graphes, which enables it do do things in parallel. Even if other config management use something close to that, in mgmt you need to have a deep understanding of them, especially when you want to contribute (which is the only thing you can do now). It is not hard, it is just a price we do not have to pay with the other tools.

How to improve that: continue improving mgmt, remove bugs in that graph so we are not badly affected by bugs in that graph, and we do not need to understand everything to contribute (e.g to write new resource types or fix bugs in resources). You can deal with Puppet, and know nothing about its internals.

Golang is challenging

mgmt is written in go. Whether it is a great language or not is not what matters here. What matters is that in the Ops world, go is not so popular. I am afraid that go is not as extensible as Ruby, and the fact that you need to recompile it to extend it is also a pain.

How to improve that: nothing mgmt can do. The core open-source infrastructure tools nowadays are mainly written in go. Sysadmins need to evolve here.

The AGPL license

I love copyleft. However, most of the world does not. This part of mgmt will be one of the things that will slow down its adoption. Ansible is GPL-Licensed, but the difference with Ansible and mgmt is that the last one is written in go, as a library. You could use mgmt just as a lib, backed into other softwares. But the licencing makes it too hard.

For a lot of other projects, the license will be the first thing they will see. They will not ever look deeper to see if mgmt firs their needs or not.

For now I am afraid mgmt would just become a thing in the Red Hat world, where by default lots of things are copyleft, so there would be no problem with including mgmt.

How to improve that: we need to speak with the community, and decide if we want to speed up the adoption, or to try to get more people to contribute.

The name

Naming things is hard. But mgmt is probably not the best name. It does not sell a dream, it does not stand out. It is impossible to do some internet searches about it.

How to improve that: we need to start thinking about a better name, that would reflect the community.

containers

I am not sure about what will be the future of mgmt in a container world. Not everything is moving to that world nowadays, but a lot of things actually is. I just don’t know. Need to think further about it.

But, is there anything positive?

You can read the list above as bad things. But I see that list a my initial ideas about how we can bring the project to the next level, how we can making it more appealing for external contributors.

mgmt is one of the projects that I would qualify as unique and really creative. Creativity is a gift nowadays. It is just awesome, just give it a bit more time.

We look forward to see it more stable, and to see a language that will take advantage of it, and enable us to easily write mgmt catalogs (currently it is all yaml). Stay tuned!

Last week, I joined the mgmt hackathon, just after Config Management Camp Ghent. It helped me understanding how mgmt actually works and that helped me to introduce two improvements in the codebase: prometheus support, and an augeas resource.

I will blog later about the prometheus support, today I will focus about the Augeas resource.

Defining a resource

Currently, mgmt does not have a DSL, it only uses plain yaml.

Here is how you define an Augeas resource:

---
graph: mygraph
resources:
  augeas:
  - name: sshd_config
    lens: Sshd.lns
    file: "/etc/ssh/sshd_config"
    sets:
      - path: X11Forwarding
        value: no
edges:

As you can see, the augeas resource takes several parameters:

• lens: the lens file to load
• file: the path to the file that we want to change
• sets: the paths/values that we want to change

Setting file will create a Watcher, which means that each time you change that file, mgmt will check if it is still aligned with what you want.

Code

The code can be found there: https://github.com/purpleidea/mgmt/pull/128/files

We are using go bindings for Augeas: https://github.com/dominikh/go-augeas/ Unfortunately, those bindings only support a recent version of Augeas. It was needed to vendor it to make it build on travis.

Future plans

Future plans regarding this resource is to add some parameters, probably a parameter to use as Puppet “onlyif” parameter, and a “rm” parameter.

After a long time of getting too little attention from me, I decided to make a new cvechecker release. There are few changes in it, but I am planning on making a new release soon with lots of clean-ups.

What has been changed

So, what has changed? With this release (now at version 3.7) two bugs have been fixed, one having a wrong URL in the CVE download and the other about the CVE sequence numbers.

The first bug was an annoying one, which I should have fixed a long time ago. Well, it was fixed in the repository, but I didn't make a new release for it. When downloading the nvdcve-2.0-Modified.xml file, the pullcves command used the lowercase filename, which doesn't exist.

The second bug is about parsing the CVE sequence. On (Januar 2014)[https://cve.mitre.org/cve/identifiers/syntaxchange.html] the syntax changed to allow for sequence identifiers longer than 4 digits. The cvechecker tool however did a hard validation on the length of the identifier, and cut off longer fields.

That means that some CVE reports failed to parse in cvechecker, and thus cvechecker didn't "know" about these vulnerabilities. This has been fixed in this release, although I am not fully satisfied...

What still needs to be done

The codebase for cvechecker is from 2010, and is actually based on a prototype that I wrote which I decided not to rewrite into proper code. As a result, the code is not up to par.

I'm going to gradually improve and clean up the code in the next few [insert timeperiod here]. I don't know if there will be feature improvements in the next few releases (not that there aren't many feature enhancements needed) but I hope that, once the code is improved, new functionality can be added more easily.

But that's for another time. Right now, enjoy the new release.

The post Log all queries in a Laravel CLI command appeared first on ma.ttias.be.

For most web-based Laravel projects, you can use the excellent laravel-debugbar package to have an in-browser overview of all your queries being executed per page. For commands run via Artisan at the command line, you need an alternative.

This is a method I've used quite often while working on DNS Spy, since most of the application logic is inside worker jobs, executed only via the CLI.

So here's a quick method of logging all your DNS queries to the console output instead.

<php

use Illuminate\Support\Facades\DB;

public function handle()
{
      \DB::listen(function($sql) {
          var_dump($sql->sql);
      });
}
?>

First, import the DB Facade.

Next, add a new listener for every query being executed, and let it var_dump() the query. Alternatively, you can use dump() or dd(), too.

The result;

$ php artisan queue:work
...
string(170) "select * from `xxx` where `xxx`.`record_id` = ? and `xxx`.`record_id` is not null ..."
string(146) "insert into `xxx` (`value`, `nameserver_id`, `ttl`, ... ) values (?, ?, ?, ...)"

Adding a DB listener is a convenient way of seeing all your queries right at the console, for times when the debugbar can't be used!

The post Log all queries in a Laravel CLI command appeared first on ma.ttias.be.

I published the following diary on isc.sans.org: “How your pictures may affect your website reputation“.

In a previous diary, I explained why the automatic processing of IOC’s (“Indicator of Compromise”) could lead to false positives. Here is a practical example found yesterday. I captured the following malicious HTML page (MD5: b55a034d8e4eb4504dfce27c3dfc4ac3)[2]. It is part of a phishing campaign and tries to lure the victim to provide his/her credentials to get access to an Excel sheet… (Read more)

[The post [SANS ISC Diary] How your pictures may affect your website reputation has been first published on /dev/random]

You may have backupped your music cd’s using a single flac file instead of a file for each track. In case you need to split the cd-flac, do this:

Install the needed software:

$ sudo apt-get install cuetools shntool

Split the album flac file into separate tracks:

$ cuebreakpoints sample.cue | shnsplit -o flac sample.flac

Copy the flac tags (if present):

$ cuetag sample.cue split-track*.flac

The full howto can be found here (aidanjm).

Update (April 18th, 2009):
In case the cue file is not a separate file, but included in the flac file itself do this as the first step:

$ metaflac --show-tag=CUESHEET sample.flac | grep -v ^CUESHEET > sample.cue

(NB: The regular syntax is “metaflac –export-cuesheet-to=sample.cue sample.flac“, however often the cue file in embedded in a tag instead of the cuesheet block).

Update (March 5th, 2017):
In case the source file is one unsplitted ape file, you can convert it to flac first.

$ sudo apt-get install ffmpeg


$ ffmpeg -i sample.ape sample.flac

I recently created a new article on the Gentoo Wiki titled Certificates which talks about how to handle certificate stores on Gentoo Linux. The write-up of the article (which might still change name later, because it does not handle everything about certificates, mostly how to handle certificate stores) was inspired by the observation that I had to adjust the certificate stores of both Chromium and Firefox separately, even though they both use NSS.

Certificates?

Well, when a secure communication is established from a browser to a site (or any other interaction that uses SSL/TLS, but let's stay with the browser example for now) part of the exchange is to ensure that the target site is actually the site it claims to be. Don't want someone else to trick you into giving your e-mail credentials do you?

To establish this, the certificate presented by the remote site is validated (alongside other handshake steps). A certificate contains a public key, as well as information about what the certificate can be used for, and who (or what) the certificate represents. In case of a site, the identification is (or should be) tied to the fully qualified domain name.

Of course, everyone could create a certificate for accounts.google.com and try to trick you into leaving your credentials. So, part of the validation of a certificate is to verify that it is signed by a third party that you trust to only sign certificates that are trustworthy. And to validate this signature, you hence need the certificate of this third party as well.

So, what about this certificate? Well, turns out, this one is also often signed by another certificate, and so on, until you reach the "top" of the certificate tree. This top certificate is called the "root certificate". And because we still have to establish that this certificate is trustworthy, we need another way to accomplish this.

Enter certificate stores

The root certificates of these trusted third parties (well, let us call them "Certificate Authorities" from now onward, because they sometimes will lose your trust) need to be reachable by the browser. The location where they are stored in is (often) called the truststore (a naming that I came across when dealing with Java and which stuck).

So, what I wanted to accomplish was to remove a particular CA certificate from the certificate store. I assumed that, because Chromium and Firefox both use NSS as the library to support their cryptographic uses, they would also both use the store location at ~/.pki/nssdb. That was wrong.

Another assumption I had was that NSS also uses the /etc/pki/nssdb location as a system-wide one. Wrong again (not that NSS doesn't allow this, but it seems that it is very much up to, and often ignored by, the NSS-implementing applications).

Oh, and I also assumed that there wouldn't be a hard-coded list in the application. Yup. Wrong again.

How NSS tracks root CA

Basically, NSS has a hard-coded root CA list inside the libnssckbi.so file. On Gentoo, this file is provided by the dev-libs/nss package. Because it is hard-coded, it seemed like there was little I could do to remove it, yet still through the user interfaces offered by Firefox and Chromium I was able to remove the trust bits from the certificate.

Turns out that Firefox (inside ~/.mozilla/firefox/*.default) and Chromium (inside ~/.pki/nssdb) store the (modified) trust bits for those locations, so that the hardcoded list does not need to be altered if all I want to do was revoke the trust on a specific CA. And it isn't that this hard-coded list is a bad list: Mozilla has a CA Certificate Program which controls the CAs that are accepted inside this store.

Still, I find it sad that the system-wide location (at /etc/pki/nssdb) is not by default used as well (or I have something wrong on my system that makes it so). On a multi-user system, administrators who want to have some control over the certificate stores might need to either use login scripts to manipulate the user certificate stores, or adapt the user files directly currently.

I published the following diary on isc.sans.org: “Not All Malware Samples Are Complex“.

Everyday we hear about new pieces of malware which implement new techniques to hide themselves and defeat analysts. But they are still people who write simple code that just “do the job”. The sample that I’m reviewing today had a very short lifetime because it was quickly detected by most antivirus. Its purpose is to steal information from the infected computers like credentials… [Read more]

[The post [SANS ISC Diary] Not All Malware Samples Are Complex has been first published on /dev/random]

One of the key reasons that Drupal has been successful is because we always made big, forward-looking changes. As a result, Drupal is one of very few CMSes that has stayed relevant for 15+ years. The downside is that with every major release of Drupal, we've gone through a lot of pain adjusting to these changes. The learning curve and difficult upgrade path from one major version of Drupal to the next (e.g. from Drupal 7 to Drupal 8) has also held back Drupal's momentum. In an ideal world, we'd be able to innovate fast yet provide a smooth learning curve and upgrade path from Drupal 8 to Drupal 9. We believe we've found a way to do both!

Upgrading from Drupal 8.2 to Drupal 8.3

Before we can talk about the upgrade path to Drupal 9, it's important to understand how we do releases in Drupal 8. With the release of Drupal 8, we moved Drupal core to use a continuous innovation model. Rather than having to wait for years to get new features, users now get sizable advances in functionality every six months. Furthermore, we committed to providing a smooth upgrade for modules, themes, and distributions from one six-month release to the next.

This new approach is starting to work really well. With the 8.1 and 8.2 updates behind us and 8.3 close to release, we have added some stable improvements like BigPipe and a new status report page, as well as experimental improvements for outside-in, workflows, layouts, and more. We also plan to add important media improvements in 8.4.

Most importantly, upgrading from 8.2 to 8.3 for these new features is not much more complicated than simply updating for a bugfix or security release.

Upgrading from Drupal 8 to Drupal 9

After a lot of discussion among the Drupal core committers and developers, and studying projects like Symfony, we believe that the advantages of Drupal's minor upgrade model (e.g. from Drupal 8.2 to Drupal 8.3) can be translated to major upgrades (e.g. from Drupal 8 to Drupal 9). We see a way to keep innovating while providing a smooth upgrade path and learning curve from Drupal 8 to Drupal 9.

Here is how we will accomplish this: we will continue to introduce new features and backwards-compatible changes in Drupal 8 releases. In the process, we sometimes have to deprecate old systems. Instead of removing old systems, we will keep them in place and encourage module maintainers to update to the new systems. This means that modules and custom code will continue to work. The more we innovate, the more deprecated code there will be in Drupal 8. Over time, maintaining backwards compatibility will become increasingly complex. Eventually, we will reach a point where we simply have too much deprecated code in Drupal 8. At that point, we will choose to remove the deprecated systems and release that as Drupal 9.

This means that Drupal 9.0 should be almost identical to the last Drupal 8 release, minus the deprecated code. It means that when modules take advantage of the latest Drupal 8 APIs and avoid using deprecated code, they should work on Drupal 9. Updating from Drupal 8's latest version to Drupal 9.0.0 should be as easy as updating between minor versions of Drupal 8. It also means that Drupal 9 gives us a clean slate to start innovating more rapidly again.

Why would you upgrade to Drupal 9 then? For the great new features in 9.1. No more features will be added to Drupal 8 after Drupal 9.0. Instead, they will go into Drupal 9.1, 9.2, and so on.

To get the most out of this new approach, we need to make two more improvements. We need to change core so that the exact same module can work with Drupal 8 and 9 if the module developer uses the latest APIs. We also need to provide full data migration from Drupal 6, 7 and 8 to any future release. So long as we make these changes before Drupal 9 and contributed or custom modules take advantage of the latest Drupal 8 APIs, up-to-date sites and modules may just begin using 9.0.0 the day it is is released.

What does this mean for Drupal 7 users?

If you are one of the more than a million sites successfully running on Drupal 7, you might only have one more big upgrade ahead of you.

If you are planning to migrate directly from Drupal 7 to Drupal 9, you should reconsider that approach. In this new model, it might be more beneficial to upgrade to Drupal 8. Once you’ve migrated your site to Drupal 8, subsequent upgrades will be much simpler.

We have more work to do to complete the Drupal 7 to Drupal 8 data migration, but the first Drupal 8 minor release that fully supports it could be 8.4.0, scheduled to be released in October 2017.

What does this mean for Drupal developers?

If you are a module or theme developer, you can continually update to the latest APIs each minor release. Avoid using deprecated code and your module will be compatible with Drupal 9 the day Drupal 9 is released. We have plans to make it easy for developers to identify and update deprecated code.

What does this mean for Drupal core contributors?

If you are a Drupal core contributor and want to introduce new improvements in Drupal core, Drupal 8 is the place to do it! With backwards compatibility layers, even pretty big changes are possible in Drupal 8.

When will Drupal 9 will be released?

We don't know yet, but it shouldn't matter as much either. Innovative Drupal 8 releases will go out on schedule every six months and upgrading to Drupal 9 should become easy. I don't believe we will release Drupal 9 any time soon; we have plenty of features in the works for Drupal 8. Once we know more, we'll follow up with more details.

Thank you

Special thanks to Alex Bronstein, Alex Pott, Gábor Hojtsy, Nathaniel Catchpole and Jess (xjm) for their contributions to this post.

The post CVE-2017-2636: Linux local privilege escalation flaw in ‘n_hdlc’ appeared first on ma.ttias.be.

This comes just weeks after the previous local root exploit (CVE-2017-6074 – local privilege escalation in DCCP).

This is an announcement of CVE-2017-2636, which is a race condition in the n_hdlc Linux kernel driver (drivers/tty/n_hdlc.c). It can be exploited to gain a local privilege escalation.

This driver provides HDLC serial line discipline and comes as a kernel module in many Linux distributions, which have CONFIG_N_HDLC=m in the kernel config.

Source: Linux kernel: CVE-2017-2636: local privilege escalation flaw in n_hdlc

Patching is, luckily, relatively trivial, as was the DCCP vulnerability.

$ echo "install n_hdlc /bin/true">> /etc/modprobe.d/disable-n_hdlc.conf

Make sure to roll that one to your fleet of servers today!

The post CVE-2017-2636: Linux local privilege escalation flaw in ‘n_hdlc’ appeared first on ma.ttias.be.

The post WordPress on PHP 7.1 appeared first on ma.ttias.be.

Since I care about performance, features and security, I decided to upgrade my webservers' PHP version from 5.6 to the latest PHP 7.1.2. I run mostly WordPress websites, so what's the impact of such a PHP version upgrade on WordPress?

At the time of writing, PHP 5.6 is in extended support, meaning it'll still get security updates, but no more bugfixes. The PHP 7.x release is the only actively support PHP version, of which PHP 7.1 is the latest version.

Let's start with some benchmarks.

Performance improvements with WordPress on PHP 7.1

First, some numbers, before I go all graph on you.

I took a fairly big page on this blog (and a popular one, too) to run the ab benchmark against: Google’s QUIC protocol: moving the web from TCP to UDP.

The goal is to execute 300 requests as quickly as possible, 2 at a time (concurrency = 2).

$ ab -c 2 -n 300 https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp/

For the sake of this test, I decided to disable the static HTML caching, I want the raw PHP performance.

The results (averaged out, as I did the test several times) -- lower is better;

• PHP 5.6: 94.3 seconds
• PHP 7.1: 74.5 seconds (22% faster)

For comparison, I also took a Laravel application I made called DNS Spy and did the same benchmark.

• PHP 5.6: 40.1 seconds
• PHP 7.1: 30.2 seconds (25% faster)

It's safe to assume PHP 7.1 is considerably faster than 5.6 with about 25% raw speed improvements. And this isn't counting the memory savings you get, because the 7.x branch is much more memory efficient than 5.6 (I just didn't accurately measure that to benchmark).

In a graph, the above timings are actually rather boring. In absolute numbers, it's the difference between an average response time of 350ms vs 250ms. Yes, it matters, but in a graph with spikes, it doesn't say much.

Things get more interesting when you look at pages that take more time to load, like the RSS feed in WordPress. This graph shows the RSS timings for the posts and the comments (2 separate requests).

In that graph, it's gone from an average response time of 610ms (for both feeds) to 280 ms. That's a 200% speed improvement over PHP 5.6!

WordPress compatibility on PHP 7.1

The million dollar question is, of course: what did I break by upgrading?

So far: nothing.

But I should point out, most of my blogs have a very limited set of plugins and are simple in both design and functionality.

• cron.weekly blog: roughly 7 plugins
• ma.ttias.be (this blog): around 15 plugins
• syscast podcast: only 3 plugins

WordPress itself will run, as a minimum requirement, on PHP 5.2.4 or higher. That's a bug, not a feature. That old PHP version should've been buried and forgotten a long time ago.

But there's an upside, too: because they still support PHP 5.2.x, they can't use any of the newer features of PHP 5.3 (namespacing), PHP 5.4 (anonymous functions), 5.5 (OPCache instead of APC), ... so WordPress core is really boring PHP. That boring PHP will run on pretty much any PHP version, including the 7.x branches.

Plugins are a different matter: popular plugins, like the Yoast SEO Plugin, will actively begin to encourage users to upgrade to a later PHP version. This is excellent news. It also means plugins are going to be your risk when upgrading PHP versions, as their supported PHP versions may vary.

Functionality testing on PHP 7.1

Limited, but this is what I tested (by writing this post) and what still works, flawlessly;

• Post writing & editing
• File uploads
• GUI & text editor
• Dashboard, WordPress statistics & widgets
• Plugin updates & auto-updates

Seems to be the biggest pieces of functionality, to me.

PHP warnings & errors

This won't show in the GUI, but your error logs from PHP-FPM may start to show things like this;

$ tail -f php/error.log
[09-Mar-2017 20:41:54 UTC] PHP Warning:  A non-numeric value encountered in /var/www/vhosts/ma.ttias.be/htdocs/wp-content/plugins/.../Abstract.php on line 371
[09-Mar-2017 20:42:17 UTC] PHP Warning:  A non-numeric value encountered in /var/www/vhosts/ma.ttias.be/htdocs/wp-content/plugins/.../Abstract.php on line 371
[09-Mar-2017 20:43:54 UTC] PHP Warning:  A non-numeric value encountered in /var/www/vhosts/ma.ttias.be/htdocs/wp-content/plugins/.../Abstract.php on line 371

Since I have no interest in maintaining plugins and lack the time to learn how SVN works again to submit a PR or patch, I simply disabled warnings in PHP.

Conclusion: WordPress + PHP 7.1 = ❤️

For me, it just works. No quirks, faster performance & a fully supported PHP version.

What's stopping you from upgrading?

The post WordPress on PHP 7.1 appeared first on ma.ttias.be.

I published the following diary on isc.sans.org: “The Side Effect of GeoIP Filters“.

IP location, GeoIP or Geolocalization are terms used to describe techniques to assign geographic locations to IP addresses.  Databases are built and maintained to link the following details to IP addresses:

• Country
• Region
• City
• Postal code
• Internet Service Provider
• Coordinates (Longitude, Latitude)
• Autonomous system (BGP)

There are many IP location service providers like Maxmind or DB-IP… [Read more]

[The post [SANS ISC Diary] The Side Effect of GeoIP Filters has been first published on /dev/random]

Funny how even the software developers at the CIA have problems with idiots who want to put binaries in git. They also know about Git-Flow, my preferred git branching workflow. I kind of wonder how come, if they know about Git-Flow, we see so few leaked NSA and CIA tools with correct semver versioning. Sometimes it’s somewhat okayish, like you can see here. But v1.0-RC3 is not really semver if you see how they got there here. To start with, your alpha versions start with 0.0.x. So where are all those versions under 0.0.x that happened before release candidate 3? 1.0, 1.1-beta, 1.0-phase2, 1.0-beta1-, 1.0-beta-7. WTF guys. That’s not a good versioning scheme. Just call it 0.0.1, 0.0.2, 0.1.0, 0.1.1, 0.1.2 for the betas. And when the thing sees first usage, start calling it 1.0.0, 1.0.1, 1.0.2, 1.1.0, 1.1.1, 1.2.0 etc. What’s wrong with that? And how are all these words like alha-1, beta-2, phase2, etc any better? Maybe just fire your release maintainer! Admittedly for that 2.0.x series they at least tried to get it right.

The point is that packaging tools can be configured to let other packages depend on these version numbers. In x.y.z the x number has implications on API incompatibility whereas the y number can be used for compatible feature additions.

I can imagine that different malwares, exploits, rootkits, intrusion tools they develop would pose incompatibilities with each other, and that for example the NSA and CIA want to share libraries and link without having to recompile or repackage. So versioning to indicate ABI and API compatibility wouldn’t be a bad idea. Let’s hope in the next round of massive leaks we see them having learned good software development processes and practices.

They are doing Scrum sprints and do retrospectives, though. That’s not so bad.

Now, that doesn't mean that there won't be anything new added over time, of course security fixes and critical bugfixes get backported from new versions into these various packages and a good number of enhancements/features also get backported over the years. Very much so on the kernel side but in some cases or in a number of cases also in the various userspace packages. However for the most part the focus is on stability and consistency. This is also the case with the different tools and compiler/languages. A concrete example would be, OL7 provides Python 2.7.5. This base release of python will not change in OL7 in newer updates, doing a big chance would break compatibility etc so it's kept stable at 2.7.5.

A very important thing to keep reminding people of, however, again, is the fact that CVEs do get backported into these versions. I often hear someone ask if we ship a newer version of, say, openssl, because some CVE or other is fixed in that newer version - but typically that CVE would also be fixed in the versions we ship with OL. There is a difference between openssl the open source project and CVE's fixed 'upstream' and openssl shipped as part of Oracle Linux versions and maintained and bug fixed overtime with backports from upstream. We take care of critical bugs and security fixes in the current shipping versions.

Anyway - there are other Linux distributions out there that 'evolve' much more frequently and by doing so, out of the box tend to come with newer versions of libraries and tools and packages and that makes it very attractive for developers that are not bound to longer term stability and compatibility. So the developer goes off and installs the latest version of everything and writes their apps using that. That's a fine model in some cases but when you have enterprise apps that might be deployed for many years and have a dependency on certain versions of scripting languages or libraries or what have you, you can't just replace those with something that's much newer, in particular much newer major versions. I am sure many people will agree that if you have an application written in python using 2.7.5 and run that in production, you're not going to let the sysadmin or so just go rip that out and replace it with python 3.5 and assume it all just works and is transparently compatible....

So does that mean we are stuck? No... there is a yum repository called Software Collections Library which we make available to everyone on our freely accessible yum server. That Library gets updated on a regular basis, we are at version 2.3 right now, and it containers newer versions of many popular packages, typically newer compilers, toolkits etc, (such as GCC, Python, PHP, Ruby...) Things that developers want to use and are looking for more recent versions.

The channel is not enabled by default, you have to go in and edit /etc/yum.repos.d/public-yum-ol7.repo and set the ol7_software_collections' repo to enabled=1. When you do that, you can then go and install the different versions that are offered. You can just browse the repo using yum or just look online. (similar channels exist for Oracle Linux 6). When you go and install these different versions, they get installed in /opt and they won't replace the existing versions. So if you have python installed by default with OL7 (2.7.5) and install Python 3.5 from the software collections, this new version goes into /opt/rh/rh-python35. You can then use the scl utility to selectively enable which application uses which version.
An example :

scl enable rh-python35 -- bash 

One little caveat to keep in mind, if you have an early version of OL7 or OL6 installed, we do not modify the /etc/yum.repo.d/public-yum-ol7.repo file after initial installation (because we might overwrite changes you made) so it is always a good idea to get the latest version from our yum server. (You can find them here.) The channel/repo name might have changed or a new one could have been added or so...

As you can see, Oracle Linux is/can be a very current developer platform. The packages are there, they are just provided in a model that keeps stability and consistency. There is no need to go download upstream package source code and compile it yourself and replacing system toolkits/compilers that can cause incompatibilities.