A flaw was found in the way pppol2tp_setsockopt() and pppol2tp_getsockopt() functions in the Linux kernel's PPP over L2TP implementation handled non-SOL_PPPOL2TP level. A local, unprivileged user could use this flaw to escalate their privileges on the system. Acknowledgements: Red Hat would like to thank Sasha Levin for reporting this issue.
Statement: This issue does not affect the Linux kernel packages as shipped with Red Hat Enterprise Linux 5 and Red Hat Enterprise MRG 2. Please note that on Red Hat Enterprise Linux 6 pppol2tp module is not automatically loaded when AF_PPPOX/PX_PROTO_OL2TP socket is created as Red Hat Enterprise Linux 6 lacks upstream commit 9395a09d05a23bb and default modprobe configuration as shipped with module-init-tools package does not contain the alias for pppol2tp protocol either. As a result, pppol2tp module has to be explicitly enabled and/or loaded by the system administrator.
Mitigation: For Red Hat Enterprise Linux 6 do -- ]# echo "install pppol2tp /bin/true" > /etc/modprobe.d/pppol2tp.conf For Red Hat Enterprise Linux 7 do -- ]# echo "install l2tp_ppp /bin/true" > /etc/modprobe.d/l2t_pppp.conf Or, alternatively, when pppol2tp/l2tp_ppp module can't be blacklisted and needs to be loaded, you can use the following systemtap script -- 1) On the host, save the following in a file with the ".stp" extension -- probe module("*l2tp*").function("pppol2tp_*etsockopt").call { $level = 273; } 2) Install the "systemtap" package and any required dependencies. Refer to the "2. Using SystemTap" chapter in the Red Hat Enterprise Linux 6 "SystemTap Beginners Guide" document, available from docs.redhat.com, for information on installing the required -debuginfo packages. 3) Run the "stap -g [filename-from-step-1].stp" command as root. If the host is rebooted, the changes will be lost and the script must be run again. Alternatively, build the systemtap script on a development system with "stap -g -p 4 [filename-from-step-1].stp", distribute the resulting kernel module to all affected systems, and run "staprun -L <module>" on those. When using this approach only systemtap-runtime package is required on the affected systems. Please notice that the kernel version must be the same across all systems.
This issue is public: http://www.openwall.com/lists/oss-security/2014/07/17/1 https://git.kernel.org/linus/3cf521f7dc87c031617fd47e4b7aa2593c2f3daf
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 1120542]
kernel-3.15.6-200.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in following products: Red Hat Enterprise Linux 7 Via RHSA-2014:0923 https://rhn.redhat.com/errata/RHSA-2014-0923.html
This issue has been addressed in following products: Red Hat Enterprise Linux 6.4 EUS - Server and Compute Node Only Via RHSA-2014:0925 https://rhn.redhat.com/errata/RHSA-2014-0925.html
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2014:0924 https://rhn.redhat.com/errata/RHSA-2014-0924.html
IssueDescription: A flaw was found in the way the pppol2tp_setsockopt() and pppol2tp_getsockopt() functions in the Linux kernel's PPP over L2TP implementation handled requests with a non-SOL_PPPOL2TP socket option level. A local, unprivileged user could use this flaw to escalate their privileges on the system.
kernel-3.14.13-100.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in following products: Red Hat Enterprise Linux 6.2 AUS Via RHSA-2014:1025 https://rhn.redhat.com/errata/RHSA-2014-1025.html