Search the Community

A bug in Linux kernel that was discovered two years ago, but was not considered a security threat at that time, has now been recognised as a potential local privilege escalation flaw. Identified as CVE-2017-1000253, the bug was initially discovered by Google researcher Michael Davidson in April 2015. Since it was not recognised as a serious bug at that time, the patch for this kernel flaw was not backported to long-term Linux distributions in kernel 3.10.77. However, researchers at Qualys Research Labs has now found that this vulnerability could be exploited to escalate privileges and it affects all major Linux distributions, including Red Hat, Debian, and CentOS. The vulnerability left "all versions of CentOS 7 before 1708 (released on September 13, 2017), all versions of Red Hat Enterprise Linux 7 before 7.4 (released on August 1, 2017), and all versions of CentOS 6 and Red Hat Enterprise Linux 6 are exploitable," Qualys said in an advisory published yesterday. The vulnerability, which has been given a CVSS3 Base Score of 7.8 out of 10, resides in the way Linux kernel loads ELF executables, which potentially results in memory corruption. Researchers find that an unprivileged local user with access to SUID (or otherwise privileged) Position Independent Executable (PIE) binary could use this vulnerability to escalate their privileges on the affected system. In order to mitigate this issue, users can switch to the legacy mmap layout by setting vm.legacy_va_layout to 1, which will effectively disable the exploitation of this security flaw. Since the mmap allocations start much lower in the process address space and follow the bottom-up allocation model, "the initial PIE executable mapping is far from the reserved stack area and cannot interfere with the stack." Qualys says this flaw is not limited to the PIEs whose read-write segment is larger than 128MB, which is the minimum distance between the mmap_base and the highest address of the stack, not the lowest address of the stack. So, when passing 1.5GB of argument strings to execve(), any PIE can be mapped directly below the stack and trigger the vulnerability. Linux distributions, including Red Hat, Debian, and CentOS, have released security updates to address the vulnerability. The Qualys team has promised to publish a proof-of-concept soon exploit that works on CentOS-7 kernel versions "3.10.0-514.21.2.el7.x86_64" and "3.10.0-514.26.1.el7.x86_64," once a maximum number of users have had time to patch their systems against the flaw. Via https://thehackernews.com/2017/09/linux-kernel-hacking.html

Default, pe CentOS, in loc de driverul 8168 este incarcat 8169 iar 8168 este inexistent. Cand utilizarea pe retea creste, apar probleme diverse: intreruperi pe retea, kernel panic. Placa de retea afisata la lspci: [root@static89 ~]# lspci|grep Eth 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 09) Driverul incarcat: [root@static89 ~]# lsmod|grep 816 r8169 74378 0 Din dmesg: r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded r8169 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 r8169 0000:03:00.0: setting latency timer to 64 r8169 0000:03:00.0: irq 34 for MSI/MSI-X Pentru a instala driverul corect (8168): rpm -Uvh http://www.elrepo.org/elrepo-release-6-6.el6.elrepo.noarch.rpm yum update yum install kmod-r8168 Dupa instalare, va trebui sa dati un reboot. [root@static89 ~]# dmesg |grep 8168 r8168 Gigabit Ethernet driver 8.040.00-NAPI loaded r8168 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 r8168 0000:03:00.0: setting latency timer to 64 r8168 0000:03:00.0: irq 34 for MSI/MSI-X r8168: This product is covered by one or more of the following patents: US6,570,884, US6,115,776, and US6,327,625. r8168 Copyright (C) 2015 Realtek NIC software team <nicfae@realtek.com> r8168: eth0: link up

Why MariaDB Replication? source : Setup MariaDB Master-Slave Replication In CentOS 7

Salutare din nou, Am la birou un "server" Linux (CentOS) care are asa: 2 placi gigabit onboard si alte 2 separata pe PCI sau PCIe. Se fac destule transferuri pe zi si am decis sa schimbam cele 2 placi de retea separata cu alte 2 tot gigabit dar profi (gasisem de la Intel la 160 lei/buc). Acuma sunt tot gigabit dar ceva la 30 de lei .... Daca inlocuiesc cele 2 placi de retea, mai trebuie sa fac ceva modificari in server la networking sau le vede si atat ? Ramane tot ifconfig-ul, eth-uri tot ? PS: am pus server intre " " deoarece este un desktop facut server. Multumesc.