VARIoT IoT vulnerabilities database
| VAR-201706-0497 | CVE-2017-2842 | Foscam C1 Indoor HD Camera Web Command injection vulnerability in management interface |
CVSS V2: 6.5 CVSS V3: 8.8 Severity: HIGH |
In the web management interface in Foscam C1 Indoor HD Camera running application firmware 2.52.2.37, a specially crafted HTTP request can allow for a user to inject arbitrary data in the "msmtprc" configuration file resulting in command execution. An attacker can simply send an HTTP request to the device to trigger this vulnerability. The FoscamIndoorIPCameraC1Series is a C1 series wireless IP camera from Foscam, China. A security vulnerability exists in the web management interface in FoscamIndoorIPCameraC1Series using 2.52.2.37 application firmware. Foscam IP Video Camera is prone to multiple command-injection vulnerabilities.
Exploiting these issues could allow an attacker to execute arbitrary commands in context of the affected device
| VAR-201706-0498 | CVE-2017-2843 | Foscam C1 Indoor HD Camera Web Command injection vulnerability in management interface |
CVSS V2: 6.5 CVSS V3: 8.8 Severity: HIGH |
In the web management interface in Foscam C1 Indoor HD Camera running application firmware 2.52.2.37, a specially crafted HTTP request can allow for a user to inject arbitrary data in the "msmtprc" configuration file resulting in command execution. An attacker can simply send an HTTP request to the device to trigger this vulnerability. The FoscamIndoorIPCameraC1Series is a C1 series wireless IP camera from Foscam, China. A security vulnerability exists in the web management interface in FoscamIndoorIPCameraC1Series using 2.52.2.37 application firmware. Foscam IP Video Camera is prone to multiple command-injection vulnerabilities.
Exploiting these issues could allow an attacker to execute arbitrary commands in context of the affected device
| VAR-201706-0505 | CVE-2017-2850 | Foscam C1 Indoor HD Camera Web In the management interface HTTP Request smuggling vulnerability |
CVSS V2: 6.5 CVSS V3: 8.8 Severity: HIGH |
In the web management interface in Foscam C1 Indoor HD cameras with application firmware 2.52.2.37, a specially crafted HTTP request can allow for a user to inject arbitrary characters in the pureftpd.passwd file during a username change, which in turn allows for bypassing chroot restrictions in the FTP server. An attacker can simply send an HTTP request to the device to trigger this vulnerability. FoscamC1IndoorHDCamera is a wireless HD IP camera from China Foscam. A security vulnerability exists in the web management interface in FoscamC1IndoorHDCamera using version 2.52.2.37 of the application firmware. Foscam IP Video Camera is prone to multiple command-injection vulnerabilities.
Exploiting these issues could allow an attacker to execute arbitrary commands in context of the affected device
| VAR-201804-0578 | CVE-2017-2832 | Foscam C1 Indoor HD Camera In OS Command injection vulnerability |
CVSS V2: 9.0 CVSS V3: 7.2 Severity: HIGH |
An exploitable command injection vulnerability exists in the web management interface used by the Foscam C1 Indoor HD Camera running application firmware 2.52.2.37. A specially crafted HTTP request can allow for a user to inject arbitrary shell characters during a password change resulting in command injection. An attacker can simply send an HTTP request to the device to trigger this vulnerability. FoscamC1IndoorHDCamera is a wireless HD IP camera from China Foscam. Foscam IP Video Camera is prone to multiple command-injection vulnerabilities.
Exploiting these issues could allow an attacker to execute arbitrary commands in context of the affected device. ### Tested Versions ``` Foscam, Inc. Indoor IP Camera C1 Series System Firmware Version: 1.9.3.17 Application Firmware Version: 2.52.2.37 Web Version: 2.0.1.1 Plug-In Version: 3.3.0.5 ``` ### Product URLs Foscam ### CVSSv3 Score 8.8 - CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H ### CWE CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') ### Details Foscam produces a series of IP-capable surveillance devices, network video recorders, and baby monitors for the end-user. Foscam produces a range of cameras for both indoor and..
| VAR-201804-0579 | CVE-2017-2833 | Foscam C1 Indoor HD Camera In OS Command injection vulnerability |
CVSS V2: 8.5 CVSS V3: 7.5 Severity: HIGH |
An exploitable command injection vulnerability exists in the web management interface used by the Foscam C1 Indoor HD Camera running application firmware 2.52.2.37. A specially crafted HTTP request can allow for a user to inject arbitrary shell characters resulting in command injection during the boot process. To trigger this vulnerability, an attacker needs to send an HTTP request and reboot the device. FoscamC1IndoorHDCamera is a wireless HD IP camera from China Foscam. Foscam IP Video Camera is prone to multiple command-injection vulnerabilities.
Exploiting these issues could allow an attacker to execute arbitrary commands in context of the affected device
| VAR-201706-0334 | CVE-2017-1000366 | glibc Buffer error vulnerability |
CVSS V2: 7.2 CVSS V3: 7.8 Severity: HIGH |
glibc contains a vulnerability that allows specially crafted LD_LIBRARY_PATH values to manipulate the heap/stack, causing them to alias, potentially resulting in arbitrary code execution. Please note that additional hardening changes have been made to glibc to prevent manipulation of stack and heap memory but these issues are not directly exploitable, as such they have not been given a CVE. This affects glibc 2.25 and earlier. glibc Contains a buffer error vulnerability.Information is obtained, information is altered, and service operation is disrupted (DoS) There is a possibility of being put into a state. GNU glibc is prone to local memory-corruption vulnerability.
An attacker could exploit this issue to execute arbitrary code in the context of the application.
GNU glibc 2.25 and prior versions are vulnerable.
===========================================================================
Ubuntu Security Notice USN-3323-1
June 19, 2017
eglibc, glibc vulnerability
===========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 17.04
- Ubuntu 16.10
- Ubuntu 16.04 LTS
- Ubuntu 14.04 LTS
Summary:
Gnu C library could be made to run programs as an administrator.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 17.04:
libc6 2.24-9ubuntu2.2
Ubuntu 16.10:
libc6 2.24-3ubuntu2.2
Ubuntu 16.04 LTS:
libc6 2.23-0ubuntu9
Ubuntu 14.04 LTS:
libc6 2.19-0ubuntu6.13
After a standard system update you need to reboot your computer to make
all the necessary changes.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=====================================================================
Red Hat Security Advisory
Synopsis: Important: glibc security update
Advisory ID: RHSA-2017:1480-01
Product: Red Hat Enterprise Linux
Advisory URL: https://access.redhat.com/errata/RHSA-2017:1480
Issue date: 2017-06-19
CVE Names: CVE-2017-1000366
=====================================================================
1. Summary:
An update for glibc is now available for Red Hat Enterprise Linux 6.
Red Hat Product Security has rated this update as having a security impact
of Important. A Common Vulnerability Scoring System (CVSS) base score,
which gives a detailed severity rating, is available for each vulnerability
from the CVE link(s) in the References section.
2. Relevant releases/architectures:
Red Hat Enterprise Linux Desktop (v. 6) - i386, x86_64
Red Hat Enterprise Linux Desktop Optional (v. 6) - i386, x86_64
Red Hat Enterprise Linux HPC Node (v. 6) - x86_64
Red Hat Enterprise Linux HPC Node Optional (v. 6) - x86_64
Red Hat Enterprise Linux Server (v. 6) - i386, ppc64, s390x, x86_64
Red Hat Enterprise Linux Server Optional (v. 6) - i386, ppc64, s390x, x86_64
Red Hat Enterprise Linux Workstation (v. 6) - i386, x86_64
Red Hat Enterprise Linux Workstation Optional (v. 6) - i386, x86_64
3. Description:
The glibc packages provide the standard C libraries (libc), POSIX thread
libraries (libpthread), standard math libraries (libm), and the name
service cache daemon (nscd) used by multiple programs on the system.
Without these libraries, the Linux system cannot function correctly. This is glibc-side mitigation which blocks
processing of LD_LIBRARY_PATH for programs running in secure-execution mode
and reduces the number of allocations performed by the processing of
LD_AUDIT, LD_PRELOAD, and LD_HWCAP_MASK, making successful exploitation of
this issue more difficult. (CVE-2017-1000366)
Red Hat would like to thank Qualys Research Labs for reporting this issue.
4. Solution:
For details on how to apply this update, which includes the changes
described in this advisory, refer to:
https://access.redhat.com/articles/11258
For the update to take effect, all services linked to the glibc library
must be restarted, or the system rebooted.
5. Bugs fixed (https://bugzilla.redhat.com/):
1452543 - CVE-2017-1000366 glibc: heap/stack gap jumping via unbounded stack allocations
6. Package List:
Red Hat Enterprise Linux Desktop (v. 6):
Source:
glibc-2.12-1.209.el6_9.2.src.rpm
i386:
glibc-2.12-1.209.el6_9.2.i686.rpm
glibc-common-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.i686.rpm
glibc-devel-2.12-1.209.el6_9.2.i686.rpm
glibc-headers-2.12-1.209.el6_9.2.i686.rpm
glibc-utils-2.12-1.209.el6_9.2.i686.rpm
nscd-2.12-1.209.el6_9.2.i686.rpm
x86_64:
glibc-2.12-1.209.el6_9.2.i686.rpm
glibc-2.12-1.209.el6_9.2.x86_64.rpm
glibc-common-2.12-1.209.el6_9.2.x86_64.rpm
glibc-debuginfo-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-2.12-1.209.el6_9.2.x86_64.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.x86_64.rpm
glibc-devel-2.12-1.209.el6_9.2.i686.rpm
glibc-devel-2.12-1.209.el6_9.2.x86_64.rpm
glibc-headers-2.12-1.209.el6_9.2.x86_64.rpm
glibc-utils-2.12-1.209.el6_9.2.x86_64.rpm
nscd-2.12-1.209.el6_9.2.x86_64.rpm
Red Hat Enterprise Linux Desktop Optional (v. 6):
i386:
glibc-debuginfo-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.i686.rpm
glibc-static-2.12-1.209.el6_9.2.i686.rpm
x86_64:
glibc-debuginfo-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-2.12-1.209.el6_9.2.x86_64.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.x86_64.rpm
glibc-static-2.12-1.209.el6_9.2.i686.rpm
glibc-static-2.12-1.209.el6_9.2.x86_64.rpm
Red Hat Enterprise Linux HPC Node (v. 6):
Source:
glibc-2.12-1.209.el6_9.2.src.rpm
x86_64:
glibc-2.12-1.209.el6_9.2.i686.rpm
glibc-2.12-1.209.el6_9.2.x86_64.rpm
glibc-common-2.12-1.209.el6_9.2.x86_64.rpm
glibc-debuginfo-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-2.12-1.209.el6_9.2.x86_64.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.x86_64.rpm
glibc-devel-2.12-1.209.el6_9.2.i686.rpm
glibc-devel-2.12-1.209.el6_9.2.x86_64.rpm
glibc-headers-2.12-1.209.el6_9.2.x86_64.rpm
glibc-utils-2.12-1.209.el6_9.2.x86_64.rpm
nscd-2.12-1.209.el6_9.2.x86_64.rpm
Red Hat Enterprise Linux HPC Node Optional (v. 6):
x86_64:
glibc-debuginfo-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-2.12-1.209.el6_9.2.x86_64.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.x86_64.rpm
glibc-static-2.12-1.209.el6_9.2.i686.rpm
glibc-static-2.12-1.209.el6_9.2.x86_64.rpm
Red Hat Enterprise Linux Server (v. 6):
Source:
glibc-2.12-1.209.el6_9.2.src.rpm
i386:
glibc-2.12-1.209.el6_9.2.i686.rpm
glibc-common-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.i686.rpm
glibc-devel-2.12-1.209.el6_9.2.i686.rpm
glibc-headers-2.12-1.209.el6_9.2.i686.rpm
glibc-utils-2.12-1.209.el6_9.2.i686.rpm
nscd-2.12-1.209.el6_9.2.i686.rpm
ppc64:
glibc-2.12-1.209.el6_9.2.ppc.rpm
glibc-2.12-1.209.el6_9.2.ppc64.rpm
glibc-common-2.12-1.209.el6_9.2.ppc64.rpm
glibc-debuginfo-2.12-1.209.el6_9.2.ppc.rpm
glibc-debuginfo-2.12-1.209.el6_9.2.ppc64.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.ppc.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.ppc64.rpm
glibc-devel-2.12-1.209.el6_9.2.ppc.rpm
glibc-devel-2.12-1.209.el6_9.2.ppc64.rpm
glibc-headers-2.12-1.209.el6_9.2.ppc64.rpm
glibc-utils-2.12-1.209.el6_9.2.ppc64.rpm
nscd-2.12-1.209.el6_9.2.ppc64.rpm
s390x:
glibc-2.12-1.209.el6_9.2.s390.rpm
glibc-2.12-1.209.el6_9.2.s390x.rpm
glibc-common-2.12-1.209.el6_9.2.s390x.rpm
glibc-debuginfo-2.12-1.209.el6_9.2.s390.rpm
glibc-debuginfo-2.12-1.209.el6_9.2.s390x.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.s390.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.s390x.rpm
glibc-devel-2.12-1.209.el6_9.2.s390.rpm
glibc-devel-2.12-1.209.el6_9.2.s390x.rpm
glibc-headers-2.12-1.209.el6_9.2.s390x.rpm
glibc-utils-2.12-1.209.el6_9.2.s390x.rpm
nscd-2.12-1.209.el6_9.2.s390x.rpm
x86_64:
glibc-2.12-1.209.el6_9.2.i686.rpm
glibc-2.12-1.209.el6_9.2.x86_64.rpm
glibc-common-2.12-1.209.el6_9.2.x86_64.rpm
glibc-debuginfo-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-2.12-1.209.el6_9.2.x86_64.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.x86_64.rpm
glibc-devel-2.12-1.209.el6_9.2.i686.rpm
glibc-devel-2.12-1.209.el6_9.2.x86_64.rpm
glibc-headers-2.12-1.209.el6_9.2.x86_64.rpm
glibc-utils-2.12-1.209.el6_9.2.x86_64.rpm
nscd-2.12-1.209.el6_9.2.x86_64.rpm
Red Hat Enterprise Linux Server Optional (v. 6):
i386:
glibc-debuginfo-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.i686.rpm
glibc-static-2.12-1.209.el6_9.2.i686.rpm
ppc64:
glibc-debuginfo-2.12-1.209.el6_9.2.ppc.rpm
glibc-debuginfo-2.12-1.209.el6_9.2.ppc64.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.ppc.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.ppc64.rpm
glibc-static-2.12-1.209.el6_9.2.ppc.rpm
glibc-static-2.12-1.209.el6_9.2.ppc64.rpm
s390x:
glibc-debuginfo-2.12-1.209.el6_9.2.s390.rpm
glibc-debuginfo-2.12-1.209.el6_9.2.s390x.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.s390.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.s390x.rpm
glibc-static-2.12-1.209.el6_9.2.s390.rpm
glibc-static-2.12-1.209.el6_9.2.s390x.rpm
x86_64:
glibc-debuginfo-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-2.12-1.209.el6_9.2.x86_64.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.x86_64.rpm
glibc-static-2.12-1.209.el6_9.2.i686.rpm
glibc-static-2.12-1.209.el6_9.2.x86_64.rpm
Red Hat Enterprise Linux Workstation (v. 6):
Source:
glibc-2.12-1.209.el6_9.2.src.rpm
i386:
glibc-2.12-1.209.el6_9.2.i686.rpm
glibc-common-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.i686.rpm
glibc-devel-2.12-1.209.el6_9.2.i686.rpm
glibc-headers-2.12-1.209.el6_9.2.i686.rpm
glibc-utils-2.12-1.209.el6_9.2.i686.rpm
nscd-2.12-1.209.el6_9.2.i686.rpm
x86_64:
glibc-2.12-1.209.el6_9.2.i686.rpm
glibc-2.12-1.209.el6_9.2.x86_64.rpm
glibc-common-2.12-1.209.el6_9.2.x86_64.rpm
glibc-debuginfo-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-2.12-1.209.el6_9.2.x86_64.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.x86_64.rpm
glibc-devel-2.12-1.209.el6_9.2.i686.rpm
glibc-devel-2.12-1.209.el6_9.2.x86_64.rpm
glibc-headers-2.12-1.209.el6_9.2.x86_64.rpm
glibc-utils-2.12-1.209.el6_9.2.x86_64.rpm
nscd-2.12-1.209.el6_9.2.x86_64.rpm
Red Hat Enterprise Linux Workstation Optional (v. 6):
i386:
glibc-debuginfo-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.i686.rpm
glibc-static-2.12-1.209.el6_9.2.i686.rpm
x86_64:
glibc-debuginfo-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-2.12-1.209.el6_9.2.x86_64.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.i686.rpm
glibc-debuginfo-common-2.12-1.209.el6_9.2.x86_64.rpm
glibc-static-2.12-1.209.el6_9.2.i686.rpm
glibc-static-2.12-1.209.el6_9.2.x86_64.rpm
These packages are GPG signed by Red Hat for security. Our key and
details on how to verify the signature are available from
https://access.redhat.com/security/team/key/
7. References:
https://access.redhat.com/security/cve/CVE-2017-1000366
https://access.redhat.com/security/updates/classification/#important
https://access.redhat.com/security/vulnerabilities/stackguard
8. Contact:
The Red Hat security contact is <secalert@redhat.com>. More contact
details at https://access.redhat.com/security/team/contact/
Copyright 2017 Red Hat, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iD8DBQFZSDWHXlSAg2UNWIIRAuhpAJ4uBm5IvSaX4vl7aeqKx4OoRTuvRgCdGBjo
maI5Dz0nZVRbUM/HVd/qJrI=
=sa7X
-----END PGP SIGNATURE-----
--
RHSA-announce mailing list
RHSA-announce@redhat.com
https://www.redhat.com/mailman/listinfo/rhsa-announce
.
Here are the details from the Slackware 14.2 ChangeLog:
+--------------------------+
patches/packages/glibc-2.23-i586-2_slack14.2.txz: Rebuilt.
Applied upstream security hardening patches from git.
For more information, see:
https://sourceware.org/git/?p=glibc.git;a=commit;h=3c7cd21290cabdadd72984fb69bc51e64ff1002d
https://sourceware.org/git/?p=glibc.git;a=commit;h=46703a3995aa3ca2b816814aa4ad05ed524194dd
https://sourceware.org/git/?p=glibc.git;a=commit;h=c69d4a0f680a24fdbe323764a50382ad324041e9
https://sourceware.org/git/?p=glibc.git;a=commit;h=3776f38fcd267c127ba5eb222e2c614c191744aa
https://sourceware.org/git/?p=glibc.git;a=commit;h=adc7e06fb412a2a1ee52f8cb788caf436335b9f3
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000366
(* Security fix *)
patches/packages/glibc-i18n-2.23-i586-2_slack14.2.txz: Rebuilt.
patches/packages/glibc-profile-2.23-i586-2_slack14.2.txz: Rebuilt.
(* Security fix *)
patches/packages/glibc-solibs-2.23-i586-2_slack14.2.txz: Rebuilt.
(* Security fix *)
+--------------------------+
Where to find the new packages:
+-----------------------------+
Thanks to the friendly folks at the OSU Open Source Lab
(http://osuosl.org) for donating FTP and rsync hosting
to the Slackware project! :-)
Also see the "Get Slack" section on http://slackware.com for
additional mirror sites near you.
Updated packages for Slackware 14.2:
ftp://ftp.slackware.com/pub/slackware/slackware-14.2/patches/packages/glibc-2.23-i586-2_slack14.2.txz
ftp://ftp.slackware.com/pub/slackware/slackware-14.2/patches/packages/glibc-i18n-2.23-i586-2_slack14.2.txz
ftp://ftp.slackware.com/pub/slackware/slackware-14.2/patches/packages/glibc-profile-2.23-i586-2_slack14.2.txz
ftp://ftp.slackware.com/pub/slackware/slackware-14.2/patches/packages/glibc-solibs-2.23-i586-2_slack14.2.txz
Updated packages for Slackware x86_64 14.2:
ftp://ftp.slackware.com/pub/slackware/slackware64-14.2/patches/packages/glibc-2.23-x86_64-2_slack14.2.txz
ftp://ftp.slackware.com/pub/slackware/slackware64-14.2/patches/packages/glibc-i18n-2.23-x86_64-2_slack14.2.txz
ftp://ftp.slackware.com/pub/slackware/slackware64-14.2/patches/packages/glibc-profile-2.23-x86_64-2_slack14.2.txz
ftp://ftp.slackware.com/pub/slackware/slackware64-14.2/patches/packages/glibc-solibs-2.23-x86_64-2_slack14.2.txz
Updated packages for Slackware -current:
ftp://ftp.slackware.com/pub/slackware/slackware-current/slackware/a/glibc-solibs-2.25-i586-3.txz
ftp://ftp.slackware.com/pub/slackware/slackware-current/slackware/l/glibc-2.25-i586-3.txz
ftp://ftp.slackware.com/pub/slackware/slackware-current/slackware/l/glibc-i18n-2.25-i586-3.txz
ftp://ftp.slackware.com/pub/slackware/slackware-current/slackware/l/glibc-profile-2.25-i586-3.txz
Updated packages for Slackware x86_64 -current:
ftp://ftp.slackware.com/pub/slackware/slackware64-current/slackware64/a/glibc-solibs-2.25-x86_64-3.txz
ftp://ftp.slackware.com/pub/slackware/slackware64-current/slackware64/l/glibc-2.25-x86_64-3.txz
ftp://ftp.slackware.com/pub/slackware/slackware64-current/slackware64/l/glibc-i18n-2.25-x86_64-3.txz
ftp://ftp.slackware.com/pub/slackware/slackware64-current/slackware64/l/glibc-profile-2.25-x86_64-3.txz
MD5 signatures:
+-------------+
Slackware 14.2 packages:
663f47dc7d0dfedb2ebf7c61d3f2272c glibc-2.23-i586-2_slack14.2.txz
078372f057f25a9208065ab79057e177 glibc-i18n-2.23-i586-2_slack14.2.txz
f071cea4355537664e48208f4af62eaf glibc-profile-2.23-i586-2_slack14.2.txz
ab57d435ca54b173a9e68f71212fc461 glibc-solibs-2.23-i586-2_slack14.2.txz
Slackware x86_64 14.2 packages:
1133b60a4c0ce35878a10bd4315fb648 glibc-2.23-x86_64-2_slack14.2.txz
089ce46a9649272054b9677a545db1e2 glibc-i18n-2.23-x86_64-2_slack14.2.txz
5ac5d520b831cd7f905302feab8d0e75 glibc-profile-2.23-x86_64-2_slack14.2.txz
b8457b979d2a6652ce3c0362c2ec5638 glibc-solibs-2.23-x86_64-2_slack14.2.txz
Slackware -current packages:
4dc6a08ad5905dcab5dba980b57d6b84 a/glibc-solibs-2.25-i586-3.txz
48c6c4a925eda4dc598470721edced9c l/glibc-2.25-i586-3.txz
1afd5bdb86c5450b1429e5c3ce7c8fd1 l/glibc-i18n-2.25-i586-3.txz
55908b021b0fdf6f00027579b885eea0 l/glibc-profile-2.25-i586-3.txz
Slackware x86_64 -current packages:
1e479e2e03e837f66c95cacb2b7649f7 a/glibc-solibs-2.25-x86_64-3.txz
ec307efb44585984181c4fe0ce01ce30 l/glibc-2.25-x86_64-3.txz
6503ac6fe173da8a2da47dcbd9c24bb1 l/glibc-i18n-2.25-x86_64-3.txz
22bc7dc3ec5b8b2bc0ca7aa2226a3094 l/glibc-profile-2.25-x86_64-3.txz
Installation instructions:
+------------------------+
Upgrade the packages as root:
# upgradepkg glibc-*.txz
+-----+
Slackware Linux Security Team
http://slackware.com/gpg-key
security@slackware.com
+------------------------------------------------------------------------+
| To leave the slackware-security mailing list: |
+------------------------------------------------------------------------+
| Send an email to majordomo@slackware.com with this text in the body of |
| the email message: |
| |
| unsubscribe slackware-security |
| |
| You will get a confirmation message back containing instructions to |
| complete the process. Please do not reply to this email address.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 201706-19
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
https://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Severity: High
Title: GNU C Library: Multiple vulnerabilities
Date: June 20, 2017
Bugs: #608698, #608706, #622220
ID: 201706-19
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Synopsis
========
Multiple vulnerabilities have been found in the GNU C Library, the
worst of which may allow execution of arbitrary code.
Background
==========
The GNU C library is the standard C library used by Gentoo Linux
systems.
Workaround
==========
There is no known workaround at this time.
Resolution
==========
All GNU C Library users should upgrade to the latest version:
# emerge --sync
# emerge --ask --oneshot --verbose ">=sys-libs/glibc-2.23-r4"
References
==========
[ 1 ] CVE-2015-5180
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-5180
[ 2 ] CVE-2016-6323
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-6323
[ 3 ] CVE-2017-1000366
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-1000366
[ 4 ] Qualys Security Advisory - The Stack Clash
https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
Availability
============
This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:
https://security.gentoo.org/glsa/201706-19
Concerns?
=========
Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users' machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.
License
=======
Copyright 2017 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).
The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.
http://creativecommons.org/licenses/by-sa/2.5
--cxbO5eT2swQBqr8k9tc6wcfapgLAJb4xR--
.
Qualys Security Advisory
The Stack Clash
========================================================================
Contents
========================================================================
I. Introduction
II. Problem
II.1. Automatic stack expansion
II.2. Stack guard-page
II.3. Stack-clash exploitation
III. Solutions
IV. Results
IV.1. Linux
IV.2. OpenBSD
IV.3. NetBSD
IV.4. FreeBSD
IV.5. Solaris
V. Acknowledgments
========================================================================
I. Introduction
========================================================================
Our research started with a 96-megabyte surprise:
b97bb000-b97dc000 rw-p 00000000 00:00 0 [heap]
bf7c6000-bf806000 rw-p 00000000 00:00 0 [stack]
and a 12-year-old question: "If the heap grows up, and the stack grows
down, what happens when they clash? Is it exploitable? How?"
- In 2005, Gael Delalleau presented "Large memory management
vulnerabilities" and the first stack-clash exploit in user-space
(against mod_php 4.3.0 on Apache 2.0.53):
http://cansecwest.com/core05/memory_vulns_delalleau.pdf
- In 2010, Rafal Wojtczuk published "Exploiting large memory management
vulnerabilities in Xorg server running on Linux", the second
stack-clash exploit in user-space (CVE-2010-2240):
http://www.invisiblethingslab.com/resources/misc-2010/xorg-large-memory-attacks.pdf
- Since 2010, security researchers have exploited several stack-clashes
in the kernel-space; for example:
https://jon.oberheide.org/blog/2010/11/29/exploiting-stack-overflows-in-the-linux-kernel/
https://jon.oberheide.org/files/infiltrate12-thestackisback.pdf
https://googleprojectzero.blogspot.com/2016/06/exploiting-recursion-in-linux-kernel_20.html
In user-space, however, this problem has been greatly underestimated;
the only public exploits are Gael Delalleau's and Rafal Wojtczuk's, and
they were written before Linux introduced a protection against
stack-clashes (a "guard-page" mapped below the stack):
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-2240
In this advisory, we show that stack-clashes are widespread in
user-space, and exploitable despite the stack guard-page; we discovered
multiple vulnerabilities in guard-page implementations, and devised
general methods for:
- "Clashing" the stack with another memory region: we allocate memory
until the stack reaches another memory region, or until another memory
region reaches the stack;
- "Jumping" over the stack guard-page: we move the stack-pointer from
the stack and into the other memory region, without accessing the
stack guard-page;
- "Smashing" the stack, or the other memory region: we overwrite the
stack with the other memory region, or the other memory region with
the stack.
To illustrate our findings, we developed the following exploits and
proofs-of-concepts:
- a local-root exploit against Exim (CVE-2017-1000369, CVE-2017-1000376)
on i386 Debian;
- a local-root exploit against Sudo (CVE-2017-1000367, CVE-2017-1000366)
on i386 Debian, Ubuntu, CentOS;
- an independent Sudoer-to-root exploit against CVE-2017-1000367 on any
SELinux-enabled distribution;
- a local-root exploit against ld.so and most SUID-root binaries
(CVE-2017-1000366, CVE-2017-1000370) on i386 Debian, Fedora, CentOS;
- a local-root exploit against ld.so and most SUID-root PIEs
(CVE-2017-1000366, CVE-2017-1000371) on i386 Debian, Ubuntu, Fedora;
- a local-root exploit against /bin/su (CVE-2017-1000366,
CVE-2017-1000365) on i386 Debian;
- a proof-of-concept that gains eip control against Sudo on i386
grsecurity/PaX (CVE-2017-1000367, CVE-2017-1000366, CVE-2017-1000377);
- a local proof-of-concept that gains rip control against Exim
(CVE-2017-1000369) on amd64 Debian;
- a local-root exploit against ld.so and most SUID-root binaries
(CVE-2017-1000366, CVE-2017-1000379) on amd64 Debian, Ubuntu, Fedora,
CentOS;
- a proof-of-concept against /usr/bin/at on i386 OpenBSD, for
CVE-2017-1000372 in OpenBSD's stack guard-page implementation and
CVE-2017-1000373 in OpenBSD's qsort() function;
- a proof-of-concept for CVE-2017-1000374 and CVE-2017-1000375 in
NetBSD's stack guard-page implementation;
- a proof-of-concept for CVE-2017-1085 in FreeBSD's setrlimit()
RLIMIT_STACK implementation;
- two proofs-of-concept for CVE-2017-1083 and CVE-2017-1084 in FreeBSD's
stack guard-page implementation;
- a local-root exploit against /usr/bin/rsh (CVE-2017-3630,
CVE-2017-3629, CVE-2017-3631) on Solaris 11.
========================================================================
II. Problem
========================================================================
Note: in this advisory, the "start of the stack" is the lowest address
of its memory region, and the "end of the stack" is the highest address
of its memory region; we do not use the ambiguous terms "top of the
stack" and "bottom of the stack".
========================================================================
II.1. Automatic stack expansion
========================================================================
The user-space stack of a process is automatically expanded by the
kernel:
- if the stack-pointer (the esp register, on i386) reaches the start of
the stack and the unmapped memory pages below (the stack grows down,
on i386),
- then a "page-fault" exception is raised and caught by the kernel,
- and the page-fault handler transparently expands the user-space stack
of the process (it decreases the start address of the stack),
- or it terminates the process with a SIGSEGV if the stack expansion
fails (for example, if the RLIMIT_STACK is reached).
Unfortunately, this stack expansion mechanism is implicit and fragile:
it relies on page-fault exceptions, but if another memory region is
mapped directly below the stack, then the stack-pointer can move from
the stack into the other memory region without raising a page-fault,
and:
- the kernel cannot tell that the process needed more stack memory;
- the process cannot tell that its stack-pointer moved from the stack
into another memory region.
In contrast, the heap expansion mechanism is explicit and robust: the
process uses the brk() system-call to tell the kernel that it needs more
heap memory, and the kernel expands the heap accordingly (it increases
the end address of the heap memory region -- the heap always grows up).
========================================================================
II.2. Stack guard-page
========================================================================
The fragile stack expansion mechanism poses a security threat: if the
stack-pointer of a process can move from the stack into another memory
region (which ends exactly where the stack starts) without raising a
page-fault, then:
- the process uses this other memory region as if it were an extension
of the stack;
- a write to this stack extension smashes the other memory region;
- a write to the other memory region smashes the stack extension.
To protect against this security threat, the kernel maps a "guard-page"
below the start of the stack: one or more PROT_NONE pages (or unmappable
pages) that:
- raise a page-fault exception if accessed (before the stack-pointer can
move from the stack into another memory region);
- terminate the process with a SIGSEGV (because the page-fault handler
cannot expand the stack if another memory region is mapped directly
below).
Unfortunately, a stack guard-page of a few kilobytes is insufficient
(CVE-2017-1000364): if the stack-pointer "jumps" over the guard-page --
if it moves from the stack into another memory region without accessing
the guard-page -- then no page-fault exception is raised and the stack
extends into the other memory region.
This theoretical vulnerability was first described in Gael Delalleau's
2005 presentation (slides 24-29). In the present advisory, we discuss
its practicalities, and multiple vulnerabilities in stack guard-page
implementations (in OpenBSD, NetBSD, and FreeBSD), but we exclude
related vulnerabilities such as unbounded alloca()s and VLAs
(Variable-Length Arrays) that have been exploited in the past:
http://phrack.org/issues/63/14.html
http://blog.exodusintel.com/2013/01/07/who-was-phone/
========================================================================
II.3. Stack-clash exploitation
========================================================================
Must be a clash, there's no alternative.
--The Clash, "Kingston Advice"
Our exploits follow a series of four sequential steps -- each step
allocates memory that must not be freed before all steps are complete:
Step 1: Clash (the stack with another memory region)
Step 2: Run (move the stack-pointer to the start of the stack)
Step 3: Jump (over the stack guard-page, into the other memory region)
Step 4: Smash (the stack, or the other memory region)
========================================================================
II.3.1. Step 1: Clash the stack with another memory region
========================================================================
Have the boys found the leak yet?
--The Clash, "The Leader"
Allocate memory until the start of the stack reaches the end of another
memory region, or until the end of another memory region reaches the
start of the stack.
- The other memory region can be, for example:
. the heap;
. an anonymous mmap();
. the read-write segment of ld.so;
. the read-write segment of a PIE, a Position-Independent Executable.
- The memory allocated in this Step 1 can be, for example:
. stack and heap memory;
. stack and anonymous mmap() memory;
. stack memory only.
- The heap and anonymous mmap() memory can be:
. temporarily allocated, but not freed before the stack guard-page is
jumped over in Step 3 and memory is smashed in Step 4;
. permanently leaked. On Linux, a general method for allocating
anonymous mmap()s is the LD_AUDIT memory leak that we discovered in
the ld.so part of the glibc, the GNU C Library (CVE-2017-1000366).
- The stack memory can be allocated, for example:
. through megabytes of command-line arguments and environment
variables.
On Linux, this general method for allocating stack memory is limited
by the kernel to 1/4 of the current RLIMIT_STACK (1GB on i386 if
RLIMIT_STACK is RLIM_INFINITY -- man execve, "Limits on size of
arguments and environment").
However, as we were drafting this advisory, we realized that the
kernel imposes this limit on the argument and environment strings,
but not on the argv[] and envp[] pointers to these strings, and we
developed alternative versions of our Linux exploits that do not
depend on application-specific memory leaks (CVE-2017-1000365). through recursive function calls.
On BSD, we discovered a general method for allocating megabytes of
stack memory: a vulnerability in qsort() that causes this function
to recurse N/4 times, given a pathological input array of N elements
(CVE-2017-1000373 in OpenBSD, CVE-2017-1000378 in NetBSD, and
CVE-2017-1082 in FreeBSD).
- In a few rare cases, Step 1 is not needed, because another memory
region is naturally mapped directly below the stack (for example,
ld.so in our Solaris exploit).
========================================================================
II.3.2. Step 2: Move the stack-pointer to the start of the stack
========================================================================
Run, run, run, run, run, don't you know?
--The Clash, "Three Card Trick"
Consume the unused stack memory that separates the stack-pointer from
the start of the stack. This Step 2 is similar to Step 3 ("Jump over the
stack guard-page") but is needed because:
- the stack-pointer is usually several kilobytes higher than the start
of the stack (functions that allocate a large stack-frame decrease the
start address of the stack, but this address is never increased
again); moreover:
. the FreeBSD kernel automatically expands the user-space stack of a
process by multiples of 128KB (SGROWSIZ, in vm_map_growstack());
. the Linux kernel initially expands the user-space stack of a process
by 128KB (stack_expand, in setup_arg_pages()).
- in Step 3, the stack-based buffer used to jump over the guard-page:
. is usually not large enough to simultaneously move the stack-pointer
to the start of the stack, and then into another memory region;
. must not be fully written to (a full write would access the stack
guard-page and terminate the process) but the stack memory consumed
in this Step 2 can be fully written to (for example, strdupa() can
be used in Step 2, but not in Step 3).
The stack memory consumed in this Step 2 can be, for example:
- large stack-frames, alloca()s, or VLAs (which can be detected by
grsecurity/PaX's STACKLEAK plugin for GCC,
https://grsecurity.net/features.php);
- recursive function calls (which can be detected by GNU cflow,
http://www.gnu.org/software/cflow/);
- on Linux, we discovered that the argv[] and envp[] arrays of pointers
can be used to consume the 128KB of initial stack expansion, because
the kernel allocates these arrays on the stack long after the call to
setup_arg_pages(); this general method for completing Step 2 is
exploitable locally, but the initial stack expansion poses a major
obstacle to the remote exploitation of stack-clashes, as mentioned in
IV.1.1.
In a few rare cases, Step 2 is not needed, because the stack-pointer is
naturally close to the start of the stack (for example, in Exim's main()
function, the 256KB group_list[] moves the stack-pointer to the start of
the stack and beyond).
========================================================================
II.3.3. Step 3: Jump over the stack guard-page, into another memory
region
========================================================================
You need a little jump of electrical shockers.
--The Clash, "Clash City Rockers"
Move the stack-pointer from the stack and into the memory region that
clashed with the stack in Step 1, but without accessing the guard-page.
To complete this Step 3, a large stack-based buffer, alloca(), or VLA is
needed, and:
- it must be larger than the guard-page;
- it must end in the stack, above the guard-page;
- it must start in the memory region below the stack guard-page;
- it must not be fully written to (a full write would access the
guard-page, raise a page-fault exception, and terminate the process,
because the memory region mapped directly below the stack prevents the
page-fault handler from expanding the stack).
In a few cases, Step 3 is not needed:
- on FreeBSD, a stack guard-page is implemented but disabled by default
(CVE-2017-1083);
- on OpenBSD, NetBSD, and FreeBSD, we discovered implementation
vulnerabilities that eliminate the stack guard-page (CVE-2017-1000372,
CVE-2017-1000374, CVE-2017-1084).
On Linux, we devised general methods for jumping over the stack
guard-page (CVE-2017-1000366):
- The glibc's __dcigettext() function alloca()tes single_locale, a
stack-based buffer of up to 128KB (MAX_ARG_STRLEN, man execve), the
length of the LANGUAGE environment variable (if the current locale is
neither "C" nor "POSIX", but distributions install default locales
such as "C.UTF-8" and "en_US.utf8").
If LANGUAGE is mostly composed of ':' characters, then single_locale
is barely written to, and can be used to jump over the stack
guard-page.
Moreover, if __dcigettext() finds the message to be translated, then
_nl_find_msg() strdup()licates the OUTPUT_CHARSET environment variable
and allows a local attacker to immediately smash the stack and gain
control of the instruction pointer (the eip register, on i386), as
detailed in Step 4a.
We exploited this stack-clash against Sudo and su, but most of the
SUID (set-user-ID) and SGID (set-group-ID) binaries that call
setlocale(LC_ALL, "") and __dcigettext() or its derivatives (the
*gettext() functions, the _() convenience macro, the strerror()
function) are exploitable.
- The glibc's vfprintf() function (called by the *printf() family of
functions) alloca()tes a stack-based work buffer of up to 64KB
(__MAX_ALLOCA_CUTOFF) if a width or precision is greater than 1KB
(WORK_BUFFER_SIZE).
If the corresponding format specifier is %s then this work buffer is
never written to and can be used to jump over the stack guard-page.
None of our exploits is based on this method, but it was one of our
ideas to exploit Exim remotely, as mentioned in IV.1.1.
- The glibc's getaddrinfo() function calls gaih_inet(), which
alloca()tes tmpbuf, a stack-based buffer of up to 64KB
(__MAX_ALLOCA_CUTOFF) that may be used to jump over the stack
guard-page.
Moreover, gaih_inet() calls the gethostbyname*() functions, which
malloc()ate a heap-based DNS response of up to 64KB (MAXPACKET) that
may allow a remote attacker to immediately smash the stack, as
detailed in Step 4a.
None of our exploits is based on this method, but it may be the key to
the remote exploitation of stack-clashes.
- The glibc's run-time dynamic linker ld.so alloca()tes llp_tmp, a
stack-based copy of the LD_LIBRARY_PATH environment variable. If
LD_LIBRARY_PATH contains Dynamic String Tokens (DSTs), they are first
expanded: llp_tmp can be larger than 128KB (MAX_ARG_STRLEN) and not
fully written to, and can therefore be used to jump over the stack
guard-page and smash the memory region mapped directly below, as
detailed in Step 4b.
We exploited this ld.so stack-clash in two data-only attacks that
bypass NX (No-eXecute) and ASLR (Address Space Layout Randomization)
and obtain a privileged shell through most SUID and SGID binaries on
most i386 Linux distributions.
- Several local and remote applications allocate a 256KB stack-based
"gid_t buffer[NGROUPS_MAX];" that is not fully written to and can be
used to move the stack-pointer to the start of the stack (Step 2) and
jump over the guard-page (Step 3). For example, Exim's main() function
and older versions of util-linux's su.
None of our exploits is based on this method, but an experimental
version of our Exim exploit unexpectedly gained control of eip after
the group_list[] buffer had jumped over the stack guard-page.
========================================================================
II.3.4. Step 4: Either smash the stack with another memory region (Step
4a) or smash another memory region with the stack (Step 4b)
========================================================================
Smash and grab, it's that kind of world.
--The Clash, "One Emotion"
In Step 3, a function allocates a large stack-based buffer and jumps
over the stack guard-page into the memory region mapped directly below;
in Step 4, before this function returns and jumps back into the stack:
- Step 4a: a write to the memory region mapped below the stack (where
esp still points to) effectively smashes the stack. We exploit this
general method for completing Step 4 in Exim, Sudo, and su:
. we overwrite a return-address on the stack and gain control of eip;
. we return-into-libc (into system() or __libc_dlopen()) to defeat NX;
. we brute-force ASLR (8 bits of entropy) if CVE-2016-3672 is patched;
. we bypass SSP (Stack-Smashing Protector) because we overwrite the
return-address of a function that is not protected by a stack canary
(the memcpy() that smashes the stack usually overwrites its own
stack-frame and return-address).
- Step 4b: a write to the stack effectively smashes the memory region
mapped below (where esp still points to). This second method for
completing Step 4 is application-specific (it depends on the contents
of the memory region that we smash) unless we exploit the run-time
dynamic linker ld.so:
. on Solaris, we devised a general method for smashing ld.so's
read-write segment, overwriting one of its function pointers, and
executing our own shell-code;
. on Linux, we exploited most SUID and SGID binaries through ld.so:
our "hwcap" exploit smashes an mmap()ed string, and our ".dynamic"
exploit smashes a PIE's read-write segment before it is mprotect()ed
read-only by Full RELRO (Full RELocate Read-Only -- GNU_RELRO and
BIND_NOW).
========================================================================
III. Solutions
========================================================================
Based on our research, we recommend that the affected operating systems:
- Increase the size of the stack guard-page to at least 1MB, and allow
system administrators to easily modify this value (for example,
grsecurity/PaX introduced /proc/sys/vm/heap_stack_gap in 2010).
This first, short-term solution is cheap, but it can be defeated by a
very large stack-based buffer.
- Recompile all userland code (ld.so, libraries, binaries) with GCC's
"-fstack-check" option, which prevents the stack-pointer from moving
into another memory region without accessing the stack guard-page (it
writes one word to every 4KB page allocated on the stack).
This second, long-term solution is expensive, but it cannot be
defeated (even if the stack guard-page is only 4KB, one page) --
unless a vulnerability is discovered in the implementation of the
stack guard-page or the "-fstack-check" option.
========================================================================
IV. Results
========================================================================
========================================================================
IV.1. Linux
========================================================================
========================================================================
IV.1.1. Exim
========================================================================
Debian 8.5
Crude exploitation
Our first exploit, a Local Privilege Escalation against Exim's SUID-root
PIE (Position-Independent Executable) on i386 Debian 8.5, simply follows
the four sequential steps outlined in II.3.
Step 1: Clash the stack with the heap
To reach the start of the stack with the end of the heap (man brk), we
permanently leak memory through multiple -p command-line arguments that
are malloc()ated by Exim but never free()d (CVE-2017-1000369) -- we call
such a malloc()ated chunk of heap memory a "memleak-chunk".
Because the -p argument strings are originally allocated on the stack by
execve(), we must cover half of the initial heap-stack distance (between
the start of the heap and the end of the stack) with stack memory, and
half of this distance with heap memory.
If we set the RLIMIT_STACK to 136MB (MIN_GAP, arch/x86/mm/mmap.c) then
the initial heap-stack distance is minimal (randomized in a [96MB,137MB]
range), but we cannot reach the stack with the heap because of the 1/4
limit imposed by the kernel on the argument and environment strings (man
execve): 136MB/4=34MB of -p argument strings cannot cover 96MB/2=48MB,
half of the minimum heap-stack distance.
Moreover, if we increase the RLIMIT_STACK, the initial heap-stack
distance also increases and we still cannot reach the stack with the
heap. However, if we set the RLIMIT_STACK to RLIM_INFINITY (4GB on i386)
then the kernel switches from the default top-down mmap() layout to a
legacy bottom-up mmap() layout, and:
- the initial heap-stack distance is approximately 2GB, because the
start of the heap (the initial brk()) is randomized above the address
0x40000000, and the end of the stack is randomized below the address
0xC0000000;
- we can reach the stack with the heap, despite the 1/4 limit imposed by
the kernel on the argument and environment strings, because 4GB/4=1GB
of -p argument strings can cover 2GB/2=1GB, half of the initial
heap-stack distance;
- we clash the stack with the heap around the address 0x80000000.
Step 2: Move the stack-pointer (esp) to the start of the stack
The 256KB stack-based group_list[] in Exim's main() naturally consumes
the 128KB of initial stack expansion, as mentioned in II.3.2.
Step 3: Jump over the stack guard-page and into the heap
To move esp from the start of the stack into the heap, without accessing
the stack guard-page, we use a malformed -d command-line argument that
is written to the 32KB (STRING_SPRINTF_BUFFER_SIZE) stack-based buffer
in Exim's string_sprintf() function. This buffer is not fully written to
and hence does not access the stack guard-page, because our -d argument
string is much shorter than 32KB.
Step 4a: Smash the stack with the heap
Before string_sprintf() returns (and moves esp from the heap back into
the stack) it calls string_copy(), which malloc()ates and memcpy()es our
-d argument string to the end of the heap, where esp still points to --
we call this malloc()ated chunk of heap memory the "smashing-chunk".
This call to memcpy() therefore smashes its own stack-frame (which is
not protected by SSP) with the contents of our smashing-chunk, and we
overwrite memcpy()'s return-address with the address of libc's system()
function (which is not randomized by ASLR because Debian 8.5 is
vulnerable to CVE-2016-3672):
- instead of smashing memcpy()'s stack-frame with an 8-byte pattern (the
return-address to system() and its argument) we smash it with a simple
4-byte pattern (the return-address to system()), append "." to the
PATH environment variable, and symlink() our exploit to the string
that begins at the address of libc's system() function;
- system() does not drop our escalated root privileges, because Debian's
/bin/sh is dash, not bash and its -p option (man bash).
This first version of our Exim exploit obtained a root-shell after
nearly a week of failed attempts; to improve this result, we analyzed
every step of a successful run.
Refined exploitation
Step 1: Clash the stack with the heap
+ The heap must be able to reach the stack [Condition 1]
The start of the heap is randomized in the 32MB range above the end of
Exim's PIE (the end of its .bss section), but the growth of the heap is
sometimes blocked by libraries that are mmap()ed within the same range
(because of the legacy bottom-up mmap() layout). On Debian 8.5, Exim's
libraries occupy about 8MB and thus block the growth of the heap with a
probability of 8MB/32MB = 1/4.
When the heap is blocked by the libraries, malloc() switches from brk()
to mmap()s of 1MB (MMAP_AS_MORECORE_SIZE), and our memory leak reaches
the stack with mmap()s instead of the heap. Such a stack-clash is also
exploitable, but its probability of success is low, as detailed in
IV.1.6., and we therefore discarded this approach.
+ The heap must always reach the stack, when not blocked by libraries
Because the initial heap-stack distance (between the start of the heap
and the end of the stack) is a random variable:
- either we allocate the exact amount of heap memory to cover the mean
heap-stack distance, but the probability of success of this approach
is low and we therefore discarded it;
- or we allocate enough heap memory to always reach the stack, even when
the initial heap-stack distance is maximal; after the heap reaches the
stack, our memory leak allocates mmap()s of 1MB above the stack (below
0xC0000000) and below the heap (above the libraries), but it must not
exhaust the address-space (the 1GB below 0x40000000 is unmappable);
- the final heap-stack distance (between the end of the heap and the
start of the stack) is also a random variable:
. its minimum value is 8KB (the stack guard-page, plus a safety page
imposed by the brk() system-call in mm/mmap.c);
. its maximum value is roughly the size of a memleak-chunk, plus 128KB
(DEFAULT_TOP_PAD, malloc/malloc.c).
Step 3: Jump over the stack guard-page and into the heap
- The stack-pointer must jump over the guard-page and land into the free
chunk at the end of the heap (the remainder of the heap after malloc()
switches from brk() to mmap()), where both the smashing-chunk and
memcpy()'s stack-frame are allocated and overwritten in Step 4a
[Condition 2];
- The write (of approximately smashing-chunk bytes) to
string_sprintf()'s stack-based buffer (which starts where the
guard-page jump lands) must not crash into the end of the heap
[Condition 3].
Step 4a: Smash the stack with the heap
The smashing-chunk must be allocated into the free chunk at the end of
the heap:
- the smashing-chunk must not be allocated into the free chunks left
over at the end of the 1MB mmap()s [Condition 4];
- the memleak-chunks must not be allocated into the free chunk at the
end of the heap [Condition 5].
Intuitively, the probability of gaining control of eip depends on the
size of the smashing-chunk (the guard-page jump's landing-zone) and the
size of the memleak-chunks (which determines the final heap-stack
distance).
To maximize this probability, we wrote a helper program that imposes the
following conditions on the smashing-chunk and memleak-chunks:
- the smashing-chunk must be smaller than 32KB
(STRING_SPRINTF_BUFFER_SIZE) [Condition 3];
- the memleak-chunks must be smaller than 128KB (DEFAULT_MMAP_THRESHOLD,
malloc/malloc.c);
- the free chunk at the end of the heap must be larger than twice the
smashing-chunk size [Conditions 2 and 3];
- the free chunk at the end of the heap must be smaller than the
memleak-chunk size [Condition 5];
- when the final heap-stack distance is minimal, the 32KB
(STRING_SPRINTF_BUFFER_SIZE) guard-page jump must land below the free
chunk at the end of the heap [Condition 2];
- the free chunks at the end of the 1MB mmap()s must be:
. either smaller than the smashing-chunk [Condition 4];
. or larger than the free chunk at the end of the heap (glibc's
malloc() is a best-fit allocator) [Condition 4].
The resulting smashing-chunk and memleak-chunk sizes are:
smash: 10224 memleak: 27656 brk_min: 20464 brk_max: 24552 mmap_top: 25304
probability: 1/16 (0.06190487817)
In theory, the probability of gaining control of eip is 1/21: the
product of the 1/16 probability calculated by this helper program
(approximately (smashing-chunk / (memleak-chunk + DEFAULT_TOP_PAD))) and
the 3/4 probability of reaching the stack with the heap [Condition 1].
In practice, on Debian 8.5, our final Exim exploit:
- gains eip control in 1 run out of 28, on average;
- takes 2.5 seconds per run (on a 4GB Virtual Machine);
- has a good chance of obtaining a root-shell after 28*2.5 = 70 seconds;
- uses 4GB of memory (2GB in the Exim process, and 2GB in the process
fork()ed by system()).
Debian 8.6
Unlike Debian 8.5, Debian 8.6 is not vulnerable to CVE-2016-3672: after
gaining eip control in Step 4a (Smash), the probability of successfully
returning-into-libc's system() function is 1/256 (8 bits of entropy --
libraries are randomized in a 1MB range but aligned on 4KB).
Consequently, our final Exim exploit has a good chance of obtaining a
root-shell on Debian 8.6 after 256*28*2.5 seconds = 5 hours (256*28=7168
runs).
As we were drafting this advisory, we tried an alternative approach
against Exim on Debian 8.6: we discovered that its stack is executable,
because it depends on libgnutls-deb0, which depends on libp11-kit, which
depends on libffi, which incorrectly requires an executable GNU_STACK
(CVE-2017-1000376).
Initially, we discarded this approach because our 1GB of -p argument
strings on the stack is not executable (_dl_make_stack_executable() only
mprotect()s the stack below argv[] and envp[]):
41e00000-723d7000 rw-p 00000000 00:00 0 [heap]
802f1000-80334000 rwxp 00000000 00:00 0 [stack]
80334000-bfce6000 rw-p 00000000 00:00 0
and because the stack is randomized in an 8MB range but we do not
control the contents of any large buffer on the executable stack.
Later, we discovered that two 128KB (MAX_ARG_STRLEN) copies of the
LD_PRELOAD environment variable can be allocated onto the executable
stack by ld.so's dl_main() and open_path() functions, automatically
freed upon return from these functions, and re-allocated (but not
overwritten) by Exim's 256KB stack-based group_list[].
In theory, the probability of returning into our shell-code (into these
executable copies of LD_PRELOAD) is 1/32 (2*128KB/8MB), higher than the
1/256 probability of returning-into-libc. In practice, this alternative
Exim exploit has a good chance of obtaining a root-shell after 1174 runs
-- instead of 32*28=896 runs in theory, because the two 128KB copies of
LD_PRELOAD are never perfectly aligned with Exim's 256KB group_list[] --
or 1174*2.5 seconds = 50 minutes.
Debian 9 and 10
Unlike Debian 8, Debian 9 and 10 are not vulnerable to offset2lib, a
minor weakness in Linux's ASLR that coincidentally affects Step 1
(Clash) of our stack-clash exploits:
https://cybersecurity.upv.es/attacks/offset2lib/offset2lib.html
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d1fd836dcf00d2028c700c7e44d2c23404062c90
If we set RLIMIT_STACK to RLIM_INFINITY, the kernel still switches to
the legacy bottom-up mmap() layout, and the libraries are randomized in
the 1MB range above the address 0x40000000, but Exim's PIE is randomized
in the 1MB range above the address 0x80000000 and the heap is randomized
in the 32MB range above the PIE's .bss section. As a result:
- the heap is always able to reach the stack, because its growth is
never blocked by the libraries -- the theoretical probability of
gaining eip control is 1/16, the probability calculated by our helper
program;
- the heap clashes with the stack around the address 0xA0000000, because
the initial heap-stack distance is 1GB (0xC0000000-0x80000000) and can
be covered with 512MB of heap memory and 512MB of stack memory.
Remote exploitation
Exim's string_sprintf() or glibc's vfprintf() can be used to remotely
complete Steps 3 and 4 of the stack-clash; and the 256KB group_list[] in
Exim's main() naturally consumes the 128KB of initial stack expansion in
Step 2; but another 256KB group_list[] in Exim's exim_setugid() further
decreases the start address of the stack and prevents us from remotely
completing Step 2 and exploiting Exim.
========================================================================
IV.1.2. Sudo
========================================================================
Introduction
We discovered a vulnerability in Sudo's get_process_ttyname() for Linux:
this function opens "/proc/[pid]/stat" (man proc) and reads the device
number of the tty from field 7 (tty_nr). Unfortunately, these fields are
space-separated and field 2 (comm, the filename of the command) can
contain spaces (CVE-2017-1000367).
For example, if we execute Sudo through the symlink "./ 1 ",
get_process_ttyname() calls sudo_ttyname_dev() to search for the
non-existent tty device number "1" in the built-in search_devs[].
Next, sudo_ttyname_dev() calls the recursive function
sudo_ttyname_scan() to search for this non-existent tty device number
"1" in a breadth-first traversal of "/dev".
Last, we exploit this recursive function during its traversal of the
world-writable "/dev/shm", and allocate hundreds of megabytes of heap
memory from the filesystem (directory pathnames) instead of the stack
(the command-line arguments and environment variables allocated by our
other stack-clash exploits).
Step 1: Clash the stack with the heap
sudo_ttyname_scan() strdup()licates the pathnames of the directories and
sub-directories that it traverses, but does not free() them until it
returns. Each one of these "memleak-chunks" allocates at most 4KB
(PATH_MAX) of heap memory.
Step 2: Move the stack-pointer to the start of the stack
The recursive calls to sudo_ttyname_scan() allocate 4KB (PATH_MAX)
stack-frames that naturally consume the 128KB of initial stack
expansion.
Step 3: Jump over the stack guard-page and into the heap
If the length of a directory pathname reaches 4KB (PATH_MAX),
sudo_ttyname_scan() calls warning(), which calls strerror() and _(),
which call gettext() and allow us to jump over the stack guard-page with
an alloca() of up to 128KB (the LANGUAGE environment variable), as
explained in II.3.3.
Step 4a: Smash the stack with the heap
The self-contained gettext() exploitation method malloc()ates and
memcpy()es a "smashing-chunk" of up to 128KB (the OUTPUT_CHARSET
environment variable) that smashes memcpy()'s stack-frame and
return-address, as explained in II.3.4.
Debian 8.5
Step 1: Clash the stack with the heap
Debian 8.5 is vulnerable to CVE-2016-3672: if we set RLIMIT_STACK to
RLIM_INFINITY, the kernel switches to the legacy bottom-up mmap() layout
and disables the ASLR of Sudo's PIE and libraries, but still the initial
heap-stack distance is randomized and roughly 2GB (0xC0000000-0x40000000
-- the start of the heap is randomized in a 32MB range above 0x40000000,
and the end of the stack is randomized in the 8MB range below
0xC0000000).
To reach the start of the stack with the end of the heap, we allocate
hundreds of megabytes of heap memory from the filesystem (directory
pathnames), and:
- the heap must be able to reach the stack -- on Debian 8.5, Sudo's
libraries occupy about 3MB and hence block the growth of the heap with
a probability of 3MB/32MB ~= 1/11;
- when not blocked by the libraries, the heap must always reach the
stack, even when the initial heap-stack distance is maximal (as
detailed in IV.1.1.);
- we cover half of the initial heap-stack distance with 1GB of heap
memory (the memleak-chunks, strdup()licated directory pathnames);
- we cover the other half of this distance with 1GB of stack memory (the
maximum permitted by the kernel's 1/4 limit on the argument and
environment strings) and thus reduce our on-disk inode usage;
- we redirect sudo_ttyname_scan()'s traversal of /dev to /var/tmp
(through a symlink planted in /dev/shm) to work around the small
number of inodes available in /dev/shm.
After the heap reaches the stack and malloc() switches from brk() to
mmap()s of 1MB:
- the size of the free chunk left over at the end of the heap is a
random variable in the [0B,4KB] range -- 4KB (PATH_MAX) is the
approximate size of a memleak-chunk;
- the final heap-stack distance (between the end of the heap and the
start of the stack) is a random variable in the [8KB,4KB+128KB=132KB]
range -- the size of a memleak-chunk plus 128KB (DEFAULT_TOP_PAD);
- sudo_ttyname_scan() recurses a few more times and therefore allocates
more stack memory, but this stack expansion is blocked by the heap and
crashes into the stack guard-page after 16 recursions on average
(132KB/4KB/2, where 132KB is the maximum final heap-stack distance,
and 4KB is the size of sudo_ttyname_scan()'s stack-frame).
To solve this unexpected problem, we:
- first, redirect sudo_ttyname_scan() to a directory tree "A" in
/var/tmp that recurses and allocates stack memory, but does not
allocate heap memory (each directory level contains only one entry,
the sub-directory that is connected to the next directory level);
- second, redirect sudo_ttyname_scan() to a directory tree "B" in
/var/tmp that recurses and allocates heap memory (each directory level
contains many entries), but does not allocate more stack memory (it
simply consumes the stack memory that was already allocated by the
directory tree "A"): it does not further expand the stack, and does
not crash into the guard-page.
Finally, we increase the speed of our exploit and avoid thousands of
useless recursions:
- in each directory level traversed by sudo_ttyname_scan(), we randomly
modify the names of its sub-directories until the first call to
readdir() returns the only sub-directory that is connected to the next
level of the directory tree (all other sub-directories allocate heap
memory but are otherwise empty);
- we dup2() Sudo's stdout and stderr to a pipe with no readers that
terminates Sudo with a SIGPIPE if sudo_ttyname_scan() calls warning()
and sudo_printf() (a failed exploit attempt, usually because the final
heap-stack distance is much longer or shorter than the guard-page
jump).
Step 2: Move the stack-pointer to the start of the stack
sudo_ttyname_scan() allocates a 4KB (PATH_MAX) stack-based pathbuf[]
that naturally consumes the 128KB of initial stack expansion in fewer
than 128KB/4KB=32 recursive calls.
The recursive calls to sudo_ttyname_scan() allocate less than 8MB of
stack memory: the maximum number of recursions (PATH_MAX / strlen("/a")
= 2K) multiplied by the size of sudo_ttyname_scan()'s stack-frame (4KB).
Step 3: Jump over the stack guard-page and into the heap
The length of the guard-page jump in gettext() is the length of the
LANGUAGE environment variable (at most 128KB, MAX_ARG_STRLEN): we take a
64KB jump, well within the range of the final heap-stack distance; this
jump then lands into the free chunk at the end of the heap, where the
smashing-chunk will be allocated in Step 4a, with a probability of
(smashing-chunk / (memleak-chunk + DEFAULT_TOP_PAD)).
If available, we assign "C.UTF-8" to the LC_ALL environment variable,
and prepend "be" to our 64KB LANGUAGE environment variable, because
these minimal locales do not interfere with our heap feng-shui.
Step 4a: Smash the stack with the heap
In gettext(), the smashing-chunk (a malloc() and memcpy() of the
OUTPUT_CHARSET environment variable) must be allocated into the free
chunk at the end of the heap, where the stack-frame of memcpy() is also
allocated.
First, if the size of our memleak-chunks is exactly 4KB+8B
(PATH_MAX+MALLOC_ALIGNMENT), then:
- the size of the free chunk at the end of the heap is a random variable
in the [0B,4KB] range;
- the size of the free chunks left over at the end of the 1MB mmap()s is
roughly 1MB%(4KB+8B)=2KB.
Second, if the size of our smashing-chunk is about 2KB+256B
(PATH_MAX/2+NAME_MAX), then:
- it is always larger than (and never allocated into) the free chunks at
the end of the 1MB mmap()s;
- it is smaller than (and allocated into) the free chunk at the end of
the heap with a probability of roughly 1-(2KB+256B)/4KB.
Last, in each level of our directory tree "B", sudo_ttyname_scan()
malloc()ates and realloc()ates an array of pointers to sub-directories,
but these realloc()s prevent the smashing-chunk from being allocated
into the free chunk at the end of the heap:
- they create holes in the heap, where the smashing-chunk may be
allocated to;
- they may allocate the free chunk at the end of the heap, where the
smashing-chunk should be allocated to.
To solve these problems, we carefully calculate the number of
sub-directories in each level of our directory tree "B":
- we limit the size of the realloc()s -- and hence the size of the holes
that they create -- to 4KB+2KB:
. either a memleak-chunk is allocated into such a hole, and the
remainder is smaller than the smashing-chunk ("not a fit");
. or such a hole is not allocated, but it is larger than the largest
free chunk at the end of the heap ("a worse fit");
- we gradually reduce the final size of the realloc()s in the last
levels of our directory tree "B", and hence re-allocate the holes
created in the previous levels.
In theory, on Debian 8.5, the probability of gaining control of eip is
approximately 1/148, the product of:
- (Step 1) the probability of reaching the stack with the heap:
1-3MB/32MB;
- (Step 3) the probability of jumping over the stack guard-page and into
the free chunk at the end of the heap: (2KB+256B) / (4KB+8B + 128KB);
- (Step 4a) the probability of allocating the smashing-chunk into the
free chunk at the end of the heap: 1-(2KB+256B)/4KB.
In practice, on Debian 8.5, this Sudo exploit:
- gains eip control in 1 run out of 200, on average;
- takes 2.8 seconds per run (on a 4GB Virtual Machine);
- has a good chance of obtaining a root-shell after 200 * 2.8 seconds =
9 minutes;
- uses 2GB of memory.
Note: we do not return-into-libc's system() in Step 4a because /bin/sh
may be bash, which drops our escalated root privileges upon execution.
Instead, we:
- either return-into-libc's __gconv_find_shlib() function through
find_module(), which loads this function's argument from -0x20(%ebp);
- or return-into-libc's __libc_dlopen_mode() function through
nss_load_library(), which loads this function's argument from
-0x1c(%ebp);
- search the libc for a relative pathname that contains a slash
character (for example, "./fork.c") and pass its address to
__gconv_find_shlib() or __libc_dlopen_mode();
- symlink() our PIE exploit to this pathname, and let Sudo execute our
_init() constructor as root, upon successful exploitation.
Debian 8.6
Unlike Debian 8.5, Debian 8.6 is not vulnerable to CVE-2016-3672: Sudo's
PIE and libraries are always randomized, even if we set RLIMIT_STACK to
RLIM_INFINITY; the probability of successfully returning-into-libc,
after gaining eip control in Step 4a (Smash), is 1/256.
However, Debian 8.6 is still vulnerable to offset2lib, the minor
weakness in Linux's ASLR that coincidentally affects Step 1 (Clash) of
our stack-clash exploits:
- if we set RLIMIT_STACK to 136MB (MIN_GAP) or less (the default is
8MB), then the initial heap-stack distance (between the start of the
heap and the end of the stack) is minimal, a random variable in the
[96MB,137MB] range;
- instead of allocating 1GB of heap memory and 1GB of stack memory to
clash the stack with the heap, we merely allocate 137MB of heap memory
(directory pathnames from our directory tree "B") and no stack memory.
In theory, on Debian 8.6, the probability of gaining eip control is
1/134 (instead of 1/148 on Debian 8.5) because the growth of the heap is
never blocked by Sudo's libraries; and in practice, this Sudo exploit
takes only 0.15 second per run (instead of 2.8 on Debian 8.5).
Independent exploitation
The vulnerability that we discovered in Sudo's get_process_ttyname()
function for Linux (CVE-2017-1000367) is exploitable independently of
its stack-clash repercussions: through this vulnerability, a local user
can pretend that his tty is any character device on the filesystem, and
after two race conditions, he can pretend that his tty is any file on
the filesystem.
On an SELinux-enabled system, if a user is Sudoer for a command that
does not grant him full root privileges, he can overwrite any file on
the filesystem (including root-owned files) with this command's output,
because relabel_tty() (in src/selinux.c) calls open(O_RDWR|O_NONBLOCK)
on his tty and dup2()s it to the command's stdin, stdout, and stderr.
To exploit this vulnerability, we:
- create a directory "/dev/shm/_tmp" (to work around
/proc/sys/fs/protected_symlinks), and a symlink "/dev/shm/_tmp/_tty"
to a non-existent pty "/dev/pts/57", whose device number is 34873;
- run Sudo through a symlink "/dev/shm/_tmp/ 34873 " that spoofs the
device number of this non-existent pty;
- set the flag CD_RBAC_ENABLED through the command-line option "-r role"
(where "role" can be our current role, for example "unconfined_r");
- monitor our directory "/dev/shm/_tmp" (for an IN_OPEN inotify event)
and wait until Sudo opendir()s it (because sudo_ttyname_dev() cannot
find our non-existent pty in "/dev/pts/");
- SIGSTOP Sudo, call openpty() until it creates our non-existent pty,
and SIGCONT Sudo;
- monitor our directory "/dev/shm/_tmp" (for an IN_CLOSE_NOWRITE inotify
event) and wait until Sudo closedir()s it;
- SIGSTOP Sudo, replace the symlink "/dev/shm/_tmp/_tty" to our
now-existent pty with a symlink to the file that we want to overwrite
(for example "/etc/passwd"), and SIGCONT Sudo;
- control the output of the command executed by Sudo (the output that
overwrites "/etc/passwd"):
. either through a command-specific method;
. or through a general method such as "--\nHELLO\nWORLD\n" (by
default, getopt() prints an error message to stderr if it does not
recognize an option character).
To reliably win the two SIGSTOP races, we preempt the Sudo process: we
setpriority() it to the lowest priority, sched_setscheduler() it to
SCHED_IDLE, and sched_setaffinity() it to the same CPU as our exploit.
[john@localhost ~]$ head -n 8 /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
[john@localhost ~]$ sudo -l
[sudo] password for john:
...
User john may run the following commands on localhost:
(ALL) /usr/bin/sum
[john@localhost ~]$ ./Linux_sudo_CVE-2017-1000367 /usr/bin/sum $'--\nHELLO\nWORLD\n'
[sudo] password for john:
[john@localhost ~]$ head -n 8 /etc/passwd
/usr/bin/sum: unrecognized option '--
HELLO
WORLD
'
Try '/usr/bin/sum --help' for more information.
ogin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
========================================================================
IV.1.3. ld.so "hwcap" exploit
========================================================================
"ld.so and ld-linux.so* find and load the shared libraries needed by a
program, prepare the program to run, and then run it." (man ld.so)
Through ld.so, most SUID and SGID binaries on most i386 Linux
distributions are exploitable. For example: Debian 7, 8, 9, 10; Fedora
23, 24, 25; CentOS 5, 6, 7.
Debian 8.5
Step 1: Clash the stack with anonymous mmap()s
The minimal malloc() implementation in ld.so calls mmap(), not brk(), to
obtain memory from the system, and it never calls munmap(). To reach the
start of the stack with anonymous mmap()s, we:
- set RLIMIT_STACK to RLIM_INFINITY and switch from the default top-down
mmap() layout to the legacy bottom-up mmap() layout;
- cover half of the initial mmap-stack distance
(0xC0000000-0x40000000=2GB) with 1GB of stack memory (the maximum
permitted by the kernel's 1/4 limit on the argument and environment
strings);
- cover the other half of this distance with 1GB of anonymous mmap()s,
through multiple LD_AUDIT environment variables that permanently leak
millions of audit_list structures (CVE-2017-1000366) in
process_envvars() and process_dl_audit() (elf/rtld.c).
Step 2: Move the stack-pointer to the start of the stack
To consume the 128KB of initial stack expansion, we simply pass 128KB of
argv[] and envp[] pointers to execve(), as explained in II.3.2.
Step 3: Jump over the stack guard-page and into the anonymous mmap()s
_dl_init_paths() (elf/dl-load.c), which is called by dl_main() after
process_envvars(), alloca()tes llp_tmp, a stack-based buffer large
enough to hold the LD_LIBRARY_PATH environment variable and any
combination of Dynamic String Token (DST) replacement strings. To
calculate the size of llp_tmp, _dl_init_paths() must:
- first, scan LD_LIBRARY_PATH and count all DSTs ($LIB, $PLATFORM, and
$ORIGIN);
- second, multiply the number of DSTs by the length of the longest DST
replacement string (on Debian, $LIB is replaced by the 18-char-long
"lib/i386-linux-gnu", $PLATFORM by "i386" or "i686", and $ORIGIN by
the pathname of the program's directory, for example "/bin" or
"/usr/sbin" -- the longest DST replacement string is usually
"lib/i386-linux-gnu");
- last, add the length of the original LD_LIBRARY_PATH.
Consequently, if LD_LIBRARY_PATH contains many DSTs that are replaced by
the shortest DST replacement string, then llp_tmp is large but not fully
written to, and can be used to jump over the stack guard-page and into
the anonymous mmap()s.
Our ld.so exploits do not use $ORIGIN because it is ignored by several
distributions and glibc versions; for example:
2010-12-09 Andreas Schwab <schwab@redhat.com>
* elf/dl-object.c (_dl_new_object): Ignore origin of privileged
program.
Index: glibc-2.12-2-gc4ccff1/elf/dl-object.c
===================================================================
--- glibc-2.12-2-gc4ccff1.orig/elf/dl-object.c
+++ glibc-2.12-2-gc4ccff1/elf/dl-object.c
@@ -214,6 +214,9 @@ _dl_new_object (char *realname, const ch
out:
new->l_origin = origin;
}
+ else if (INTUSE(__libc_enable_secure) && type == lt_executable)
+ /* The origin of a privileged program cannot be trusted. */
+ new->l_origin = (char *) -1;
return new;
}
Step 4b: Smash an anonymous mmap() with the stack
Before _dl_init_paths() returns to dl_main() and jumps back from the
anonymous mmap()s into the stack, we overwrite the block of mmap()ed
memory malloc()ated by _dl_important_hwcaps() with the contents of the
stack-based buffer llp_tmp.
- The block of memory malloc()ated by _dl_important_hwcaps() is divided
in two:
. The first part (the "hwcap-pointers") is an array of r_strlenpair
structures that point to the hardware-capability strings stored in
the second part of this memory block. The second part (the "hwcap-strings") contains strings of
hardware-capabilities that are appended to the pathnames of trusted
directories, such as "/lib/" and "/lib/i386-linux-gnu/", when
open_path() searches for audit libraries (LD_AUDIT), preload
libraries (LD_PRELOAD), or dependent libraries (DT_NEEDED).
For example, on Debian, when open_path() finds "libc.so.6" in
"/lib/i386-linux-gnu/i686/cmov/", "i686/cmov/" is such a
hardware-capability string.
- To overwrite the block of memory malloc()ated by
_dl_important_hwcaps() with the contents of the stack-based buffer
llp_tmp, we divide our LD_LIBRARY_PATH environment variable in two:
. The first, static part (our "good-write") overwrites the first
hardware-capability string with characters that we do control. The second, dynamic part (our "bad-write") overwrites the last
hardware-capability strings with characters that we do not control
(the short DST replacement strings that enlarge llp_tmp and allow us
to jump over the stack guard-page).
If our 16-byte-aligned good-write overwrites the 8-byte-aligned first
hardware-capability string with the 8-byte pattern "/../tmp/", and if we
append the trusted directory "/lib" to our LD_LIBRARY_PATH, then (after
_dl_init_paths() returns to dl_main()):
- dlmopen_doit() tries to load an LD_AUDIT library "a" (our memory leak
from Step 1);
- _dl_map_object() searches for "a" in the trusted directory "/lib" from
our LD_LIBRARY_PATH;
- open_path() finds our library "a" in "/lib//../tmp//../tmp//../tmp/"
because we overwrote the first hardware-capability string with the
pattern "/../tmp/";
- dl_open_worker() executes our library's _init() constructor, as root.
In theory, this exploit's probability of success depends on:
- (event A) the size of rtld_search_dirs.dirs[0], an array of
r_search_path_elem structures that are malloc()ated by
_dl_init_paths() after the _dl_important_hwcaps(), and must be
allocated above the stack (below 0xC0000000), not below the stack
where it would interfere with Steps 3 (Jump) and 4b (Smash):
P(A) = 1 - size of rtld_search_dirs.dirs[0] / max stack randomization
- (event B) the size of the hwcap-pointers and the size of our
good-write, which must overwrite the first hardware-capability string,
but not the first hardware-capability pointer (to this string):
P(B|A) = MIN(size of hwcap-pointers, size of good-write) /
(max stack randomization - size of rtld_search_dirs.dirs[0])
- (event C) the size of the hwcap-strings and the size of our bad-write,
which must not write past the end of hwcap-strings; but we guarantee
that size of hwcap-strings >= size of good-write + size of bad-write:
P(C|B) = 1
In practice, we use the LD_HWCAP_MASK environment variable to maximize
this exploit's probability of success, because:
- the size of the hwcap-pointers -- which act as a cushion that absorbs
the excess of good-write without crashing,
- the size of the hwcap-strings -- which act as a cushion that absorbs
the excess of good-write and bad-write without crashing,
- and the size of rtld_search_dirs.dirs[0],
are all proportional to 2^N, where N is the number of supported
hardware-capabilities that we enable in LD_HWCAP_MASK.
For example, on Debian 8.5, this exploit:
- has a 1/151 probability of success;
- takes 5.5 seconds per run (on a 4GB Virtual Machine);
- has a good chance of obtaining a root-shell after 151 * 5.5 seconds =
14 minutes.
Debian 8.6
Unlike Debian 8.5, Debian 8.6 is not vulnerable to CVE-2016-3672, but
our ld.so "hwcap" exploit is a data-only attack and is not affected by
the ASLR of the libraries and PIEs.
Debian 9 and 10
Unlike Debian 8, Debian 9 and 10 are not vulnerable to offset2lib: if we
set RLIMIT_STACK to RLIM_INFINITY, the libraries are randomized above
the address 0x40000000, but the PIE is randomized above 0x80000000
(instead of 0x40000000 before the offset2lib patch).
Unfortunately, we discovered a vulnerability in the offset2lib patch
(CVE-2017-1000370): if the PIE is execve()d with 1GB of argument or
environment strings (the maximum permitted by the kernel's 1/4 limit)
then the stack occupies the address 0x80000000, and the PIE is mapped
above the address 0x40000000 instead, directly below the libraries.
This vulnerability effectively nullifies the offset2lib patch, and
allows us to reuse our Debian 8 exploit against Debian 9 and 10.
$ ./Linux_offset2lib
Run #1...
CVE-2017-1000370 triggered
40076000-40078000 r-xp 00000000 00:26 25041 /tmp/Linux_offset2lib
40078000-40079000 r--p 00001000 00:26 25041 /tmp/Linux_offset2lib
40079000-4009b000 rw-p 00002000 00:26 25041 /tmp/Linux_offset2lib
4009b000-400c0000 r-xp 00000000 fd:00 8463588 /usr/lib/ld-2.24.so
400c0000-400c1000 r--p 00024000 fd:00 8463588 /usr/lib/ld-2.24.so
400c1000-400c2000 rw-p 00025000 fd:00 8463588 /usr/lib/ld-2.24.so
400c2000-400c4000 r--p 00000000 00:00 0 [vvar]
400c4000-400c6000 r-xp 00000000 00:00 0 [vdso]
400c6000-400c8000 rw-p 00000000 00:00 0
400cf000-402a3000 r-xp 00000000 fd:00 8463595 /usr/lib/libc-2.24.so
402a3000-402a4000 ---p 001d4000 fd:00 8463595 /usr/lib/libc-2.24.so
402a4000-402a6000 r--p 001d4000 fd:00 8463595 /usr/lib/libc-2.24.so
402a6000-402a7000 rw-p 001d6000 fd:00 8463595 /usr/lib/libc-2.24.so
402a7000-402aa000 rw-p 00000000 00:00 0
7fcf1000-bfcf2000 rw-p 00000000 00:00 0 [stack]
Caveats
- On Fedora and CentOS, this ld.so "hwcap" exploit fails against
/usr/bin/passwd and /usr/bin/chage (but it works against all other
SUID-root binaries) because of SELinux:
type=AVC msg=audit(1492091008.983:414): avc: denied { execute } for pid=2169 comm="passwd" path="/var/tmp/a" dev="dm-0" ino=12828063 scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0
type=AVC msg=audit(1492092997.581:487): avc: denied { execute } for pid=2648 comm="chage" path="/var/tmp/a" dev="dm-0" ino=12828063 scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0
- It fails against recent versions of Sudo that specify an RPATH such as
"/usr/lib/sudo": _dl_map_object() first searches for our LD_AUDIT
library in RPATH, but open_path() fails to find our library in
"/usr/lib/sudo//../tmp/" and crashes as soon as it reaches an
overwritten hwcap-pointer.
This problem can be solved by a 16-byte pattern "///../../../tmp/"
(instead of the 8-byte pattern "/../tmp/") but the exploit's
probability of success would be divided by two.
- On Ubuntu, this ld.so "hwcap" exploit always fails, because of the
following patch:
Description: pro-actively disable LD_AUDIT for setuid binaries, regardless
of where the libraries are loaded from. This is to try to make sure that
CVE-2010-3856 cannot sneak back in. Upstream is unlikely to take this,
since it limits the functionality of LD_AUDIT.
Author: Kees Cook <kees@ubuntu.com>
Index: eglibc-2.15/elf/rtld.c
===================================================================
--- eglibc-2.15.orig/elf/rtld.c 2012-05-09 10:05:29.456899131 -0700
+++ eglibc-2.15/elf/rtld.c 2012-05-09 10:38:53.952009069 -0700
@@ -2529,7 +2529,7 @@
while ((p = (strsep) (&str, ":")) != NULL)
if (p[0] != '\0'
&& (__builtin_expect (! __libc_enable_secure, 1)
- || strchr (p, '/') == NULL))
+ ))
{
/* This is using the local malloc, not the system malloc. The
memory can never be freed. */
========================================================================
IV.1.4. ld.so ".dynamic" exploit
========================================================================
To exploit ld.so without the LD_AUDIT memory leak, we rely on a second
vulnerability that we discovered in the offset2lib patch
(CVE-2017-1000371):
if we set RLIMIT_STACK to RLIM_INFINITY, and allocate nearly 1GB of
stack memory (the maximum permitted by the kernel's 1/4 limit on the
argument and environment strings) then the stack grows down to almost
0x80000000, and because the PIE is mapped above 0x80000000, the minimum
distance between the end of the PIE's read-write segment and the start
of the stack is 4KB (the stack guard-page).
$ ./Linux_offset2lib 0x3f800000
Run #1...
Run #2...
Run #3...
Run #796...
Run #797...
Run #798...
CVE-2017-1000371 triggered
4007b000-400a0000 r-xp 00000000 fd:00 8463588 /usr/lib/ld-2.24.so
400a0000-400a1000 r--p 00024000 fd:00 8463588 /usr/lib/ld-2.24.so
400a1000-400a2000 rw-p 00025000 fd:00 8463588 /usr/lib/ld-2.24.so
400a2000-400a4000 r--p 00000000 00:00 0 [vvar]
400a4000-400a6000 r-xp 00000000 00:00 0 [vdso]
400a6000-400a8000 rw-p 00000000 00:00 0
400af000-40283000 r-xp 00000000 fd:00 8463595 /usr/lib/libc-2.24.so
40283000-40284000 ---p 001d4000 fd:00 8463595 /usr/lib/libc-2.24.so
40284000-40286000 r--p 001d4000 fd:00 8463595 /usr/lib/libc-2.24.so
40286000-40287000 rw-p 001d6000 fd:00 8463595 /usr/lib/libc-2.24.so
40287000-4028a000 rw-p 00000000 00:00 0
8000a000-8000c000 r-xp 00000000 00:26 25041 /tmp/Linux_offset2lib
8000c000-8000d000 r--p 00001000 00:26 25041 /tmp/Linux_offset2lib
8000d000-8002f000 rw-p 00002000 00:26 25041 /tmp/Linux_offset2lib
80030000-bf831000 rw-p 00000000 00:00 0 [heap]
Note: in this example, the "[stack]" is incorrectly displayed as the
"[heap]" by show_map_vma() (in fs/proc/task_mmu.c).
This completes Step 1: we clash the stack with the PIE's read-write
segment; we complete the remaining steps as in the "hwcap" exploit:
- Step 2: we consume the initial stack expansion with 128KB of argv[]
and envp[] pointers;
- Step 3: we jump over the stack guard-page and into the PIE's
read-write segment with llp_tmp's alloca() (in _dl_init_paths());
- Step 4b: we smash the PIE's read-write segment with llp_tmp's
good-write and bad-write (in _dl_init_paths()); we can smash the
following sections:
+ .data and .bss: but we discarded this application-specific approach;
+ .got: although protected by Full RELRO (Full RELocate Read-Only,
GNU_RELRO and BIND_NOW) the .got is still writable when we smash it
in _dl_init_paths(); however, within ld.so, the .got is written to
but never read from, and we therefore discarded this approach;
+ .dynamic: our favored approach.
On i386, the .dynamic section is an array of Elf32_Dyn structures (an
int32 d_tag, and the union of uint32 d_val and uint32 d_ptr) that
contains entries such as:
- DT_STRTAB, a pointer to the PIE's .dynstr section (a read-only string
table): its d_tag (DT_STRTAB) is read (by elf_get_dynamic_info())
before we smash it in _dl_init_paths(), but its d_ptr is read (by
_dl_map_object_deps()) after we smash it in _dl_init_paths();
- DT_NEEDED, an offset into the .dynstr section: the pathname of a
dependent library that must be loaded by _dl_map_object_deps().
If we overwrite the entire .dynamic section with the following 8-byte
pattern (an Elf32_Dyn structure):
- a DT_NEEDED d_tag,
- a d_val equal to half the address of our own string table on the stack
(16MB of argument strings, enough to defeat the 8MB stack
randomization),
then _dl_map_object_deps() reads the pathname of this dependent library
from DT_STRTAB.d_ptr + DT_NEEDED.d_val = our_strtab/2 + our_strtab/2 =
our_strtab, and loads our own library, as root. This 8-byte pattern is
simple, but poses two problems:
- DT_NEEDED is an int32 equal to 1, but we smash the .dynamic section
with a string copy that cannot contain null-bytes: to solve this first
problem we use DT_AUXILIARY instead, which is equivalent but equal to
0x7ffffffd;
- ld.so crashes before it returns from dl_main() (before it calls
_dl_init() and executes our library's _init() constructor):
. in _dl_map_object_deps() because of our DT_AUXILIARY entry;
. in version_check_doit() because we overwrote the DT_VERNEED entry;
. in _dl_relocate_object() because we overwrote the DT_REL, DT_RELSZ,
and DT_RELCOUNT entries.
To solve this second problem, we could overwrite the .dynamic section
with a more complicated pattern that repairs these entries, but our
exploit's probability of success would decrease significantly.
Instead, we take control of ld.so's execution flow as soon as
_dl_map_object_deps() loads our library:
- our library contains three executable LOAD segments,
- but only the first and last segments are sanity-checked by
_dl_map_object_from_fd() and _dl_map_segments(),
- and all segments except the first are mmap()ed with MAP_FIXED by
_dl_map_segments(),
- so we can mmap() our second segment anywhere -- we mmap() it on top of
ld.so's executable segment,
- and return into our own code (instead of ld.so's) as soon as this
second mmap() system-call returns.
Probabilities
The "hwcap" exploit taught us that this ".dynamic" exploit's probability
of success depends on:
- the size of the cushion below the .dynamic section, which can absorb
the excess of "good-write" without crashing: the padding bytes between
the start of the PIE's read-write segment and the start of its first
read-write section;
- the size of the cushion above the .dynamic section, which can absorb
the excess of "good-write" and "bad-write" without crashing: the .got,
.data, and .bss sections.
If we guarantee that (cushion above .dynamic > good-write + bad-write),
then the theoretical probability of success is approximately:
MIN(cushion below .dynamic, good-write) / max stack randomization
The maximum size of the cushion below the .dynamic section is 4KB (one
page) and hence the maximum probability of success is 4KB/8MB=1/2048.
In practice, on Ubuntu 16.04.2:
- the highest probability is 1/2589 (/bin/su) and the lowest probability
is 1/9225 (/usr/lib/eject/dmcrypt-get-device);
- each run uses 1GB of memory and takes 1.5 seconds (on a 4GB Virtual
Machine);
- this ld.so ".dynamic" exploit has a good chance of obtaining a
root-shell after 2589 * 1.5 seconds ~= 1 hour.
========================================================================
IV.1.5. /bin/su
========================================================================
As we were drafting this advisory, we discovered a general method for
completing Step 1 (Clash) of the stack-clash exploitation: the Linux
kernel limits the size of the command-line arguments and environment
variables to 1/4 of the RLIMIT_STACK, but it imposes this limit on the
argument and environment strings, not on the argv[] and envp[] pointers
to these strings (CVE-2017-1000365).
On i386, if we set RLIMIT_STACK to RLIM_INFINITY, the maximum number of
argv[] and envp[] pointers is 1G (1/4 of the RLIMIT_STACK, divided by
1B, the minimum size of an argument or environment string). In theory,
the maximum size of the initial stack is therefore 1G*(1B+4B)=5GB. In
practice, this would exhaust the address-space and allows us to clash
the stack with the memory region that is mapped below, without an
application-specific memory leak.
This discovery allowed us to write alternative versions of our
stack-clash exploits; for example:
- an ld.so "hwcap" exploit against Ubuntu: we replace the LD_AUDIT
memory leak with 2GB of stack memory (1GB of argument and environment
strings, and 1GB of argv[] and envp[] pointers) and replace the
LD_AUDIT library with an LD_PRELOAD library;
- an ld.so ".dynamic" exploit against systems vulnerable to offset2lib:
we reach the end of the PIE's read-write segment with only 128MB of
stack memory (argument and environment strings and pointers).
These proofs-of-concept demonstrate a general method for completing Step
1 (Clash), but they are much slower than their original versions (10-20
seconds per run) because they pass millions of argv[] and envp[]
pointers to execve().
Moreover, this discovery allowed us to exploit SUID binaries through
general methods that do not depend on application-specific or ld.so
vulnerabilities; if a SUID binary calls setlocale(LC_ALL, ""); and
gettext() (or a derivative such as strerror() or _()), then it is
exploitable:
- Step 1: we clash the stack with the heap through millions of argument
and environment strings and pointers;
- Step 2: we consume the initial stack expansion with 128KB of argument
and environment pointers;
- Step 3: we jump over the stack guard-page and into the heap with the
alloca()tion of the LANGUAGE environment variable in gettext();
- Step 4a: we smash the stack with the malloc()ation of the
OUTPUT_CHARSET environment variable in gettext() and thus gain control
of eip.
For example, we exploited Debian's /bin/su (from the shadow-utils): its
main() function calls setlocale() and save_caller_context(), which calls
gettext() (through _()) if its stdin is not a tty.
Debian 8.5
Debian 8.5 is vulnerable to CVE-2016-3672: we set RLIMIT_STACK to
RLIM_INFINITY and disable ASLR, clash the stack with the heap through
2GB of argument and environment strings and pointers (1GB of strings,
1GB of pointers), and return-into-libc's system() or __libc_dlopen():
- the system() version uses 4GB of memory (2GB in the /bin/su process,
and 2GB in the process fork()ed by system());
- the __libc_dlopen() version uses only 2GB of memory, but ebp must
point to our smashed data on the stack.
Debian 8.6
Debian 8.6 is vulnerable to offset2lib but not to CVE-2016-3672: we must
brute-force the libc's ASLR (8 bits of entropy), but we clash the stack
with the heap through only 128MB of argument and environment strings and
pointers -- this /bin/su exploit can be parallelized.
========================================================================
IV.1.6. Grsecurity/PaX
========================================================================
https://grsecurity.net/
In 2010, grsecurity/PaX introduced a configurable stack guard-page: its
size can be modified through /proc/sys/vm/heap_stack_gap and is 64KB by
default (unlike the hard-coded 4KB stack guard-page in the vanilla
kernel).
Unfortunately, a 64KB stack guard-page is not large enough, and can be
jumped over with ld.so or gettext() (CVE-2017-1000377); for example, we
were able to gain eip control against Sudo, but we were unable to obtain
a root-shell or gain eip control against another application, because
grsecurity/PaX imposes the following security measures:
- it restricts the RLIMIT_STACK of SUID binaries to 8MB, which prevents
us from switching to the legacy bottom-up mmap() layout (Step 1);
- it restricts the argument and environment strings to 512KB, which
prevents us from clashing the stack through megabytes of command-line
arguments and environment variables (Step 1);
- it randomizes the PIE and libraries with 16 bits of entropy (instead
of 8 bits in vanilla), which prevents us from brute-forcing the ASLR
and returning-into-libc (Step 4a);
- it implements /proc/sys/kernel/grsecurity/deter_bruteforce (enabled by
default), which limits the number of SUID crashes to 1 every 15
minutes (all Steps) and makes exploitation impossible.
Sudo
The vulnerability that we discovered in Sudo's get_process_ttyname()
(CVE-2017-1000367) allows us to:
- Step 1: clash the stack with 3GB of heap memory from the filesystem
(directory pathnames) and bypass grsecurity/PaX's 512KB limit on the
argument and environment strings;
- Step 2: consume the 128KB of initial stack expansion with 3MB of
recursive function calls and avoid grsecurity/PaX's 8MB restriction on
the RLIMIT_STACK;
- Step 3: jump over grsecurity/PaX's 64KB stack guard-page with a 128KB
(MAX_ARG_STRLEN) alloca()tion of the LANGUAGE environment variable in
gettext();
- Step 4a: smash the stack with a 128KB (MAX_ARG_STRLEN) malloc()ation
of the OUTPUT_CHARSET environment variable in gettext() -- the
"smashing-chunk" -- and thus gain control of eip.
In Step 1, we nearly exhaust the address-space until finally malloc()
switches from brk() to 1MB mmap()s and reaches the start of the stack
with the very last 1MB mmap() that we allocate. The exact amount of
memory that we must allocate to reach the stack with our last 1MB mmap()
depends on the sum of three random variables: the 256MB randomization of
the stack, the 64MB randomization of the heap, and the 1MB randomization
of the NULL region.
To maximize the probability of jumping over the stack guard-page, into
our last 1MB mmap() below the stack, and overwriting a return-address on
the stack with our smashing-chunk:
- (Step 1) we must allocate the mean amount of memory to reach the stack
with our last 1MB mmap(): the sum of three uniform random variables is
not uniform (https://en.wikipedia.org/wiki/Irwin-Hall_distribution),
but the values within the 256MB-64MB-1MB=191MB plateau at the center
of this bell-shaped probability distribution occur with a uniform and
maximum probability of (1MB*64MB)/(1MB*64MB*256MB)=1/256MB;
- (Step 1) the end of our last 1MB mmap() must be allocated at a
distance within [stack guard-page (64KB), guard-page jump (128KB)]
below the start of the stack: the guard-page jump (Step 3) then lands
at a distance d within [0, guard-page jump - stack guard-page (64KB)]
below the end of our last 1MB mmap();
- (Step 4a) the end of our smashing-chunk must be allocated at the end
of our last 1MB mmap(), above the landing-point of the guard-page
jump: our smashing-chunk then overwrites a return-address on the
stack, below the landing-point of the guard-page jump.
In theory, this probability is roughly:
SUM(d = 1; d < guard-page jump - stack guard-page; d++) d / (256MB*1MB)
~= ((guard-page jump - stack guard-page)^2 / 2) / (256MB*1MB)
~= 1 / 2^17
In practice, we tested this Sudo proof-of-concept on an i386 Debian 8.6
protected by the linux-grsec package from the jessie-backports, but we
manually disabled /proc/sys/kernel/grsecurity/deter_bruteforce:
- it uses 3GB of memory, and 800K on-disk inodes;
- it takes 5.5 seconds per run (on a 4GB Virtual Machine);
- it has a good chance of gaining eip control after 2^17 * 5.5 seconds =
200 hours; in our test:
PAX: From 192.168.56.1: execution attempt in: <heap>, 1b068000-a100d000 1b068000
PAX: terminating task: /usr/bin/sudo( 1 ):25465, uid/euid: 1000/0, PC: 41414141, SP: b8844f30
PAX: bytes at PC: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
PAX: bytes at SP-4: 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141
However, brute-forcing the ASLR to obtain a root-shell would take ~1500
years and makes exploitation impossible.
Moreover, if we enable /proc/sys/kernel/grsecurity/deter_bruteforce,
gaining eip control would take ~1365 days, and obtaining a root-shell
would take thousands of years.
========================================================================
IV.1.7. 64-bit exploitation
========================================================================
Introduction
The address-space of a 64-bit process is so vast that we initially
thought it was impossible to clash the stack with another memory region;
we were wrong.
Linux's execve() first randomizes the end of the mmap region (which
grows top-down by default) and then randomizes the end of the stack
region (which grows down, on x86). On amd64, the initial mmap-stack
distance (between the end of the mmap region and the end of the stack
region) is minimal when RLIMIT_STACK is lower than or equal to MIN_GAP
(mmap_base() in arch/x86/mm/mmap.c), and then:
- the end of the mmap region is equal to (as calculated by
arch_pick_mmap_layout() in arch/x86/mm/mmap.c):
mmap_end = TASK_SIZE - MIN_GAP - arch_mmap_rnd()
where:
. TASK_SIZE is the highest address of the user-space (0x7ffffffff000)
. MIN_GAP = 128MB + stack_maxrandom_size()
. stack_maxrandom_size() is ~16GB (or ~4GB if the kernel is vulnerable
to CVE-2015-1593, but we do not consider this case here)
. arch_mmap_rnd() is a random variable in the [0B,1TB] range
- the end of the stack region is equal to (as calculated by
randomize_stack_top() in fs/binfmt_elf.c):
stack_end = TASK_SIZE - "stack_rand"
where:
. "stack_rand" is a random variable in the [0, stack_maxrandom_size()]
range
- the initial mmap-stack distance is therefore equal to:
stack_end - mmap_end = MIN_GAP + arch_mmap_rnd() - "stack_rand"
= 128MB + stack_maxrandom_size() - "stack_rand" + arch_mmap_rnd()
= 128MB + StackRand + MmapRand
where:
. StackRand = stack_maxrandom_size() - "stack_rand", a random variable
in the [0B,16GB] range
. MmapRand = arch_mmap_rnd(), a random variable in the [0B,1TB] range
Consequently, the minimum initial mmap-stack distance is only 128MB
(CVE-2017-1000379), and:
- On kernels vulnerable to offset2lib, the heap of a PIE (which is
mapped at the end of the mmap region) is mapped below and close to the
stack with a good probability (~1/700). We can therefore clash the
stack with the heap in Step 1, jump over the stack guard-page and into
the heap in Step 3, and smash the stack with the heap and gain control
of rip in Step 4a (after 6 hours on average). However, because the
addresses of all executable regions contain null-bytes, and because
most of our stack-smashes in Step 4a are string operations (except the
getaddrinfo() method), we were unable to transform such a rip control
into arbitrary code execution.
- On all kernels, either a PIE or ld.so is mapped directly below the
stack with a good probability (~1/17000) -- the end of the PIE's or
ld.so's read-write segment is then equal to the start of the stack
guard-page. We can therefore adapt our ld.so "hwcap" exploit to amd64
and obtain root privileges through most SUID binaries on most Linux
distributions (after 5 hours on average).
Kernels vulnerable to offset2lib, local Exim proof-of-concept
Exim's binary is usually a PIE, mapped at the end of the mmap region;
and the heap, which always grows up and is randomized above the end of
the binary, is therefore randomized above the end of the mmap region
(arch_randomize_brk() in arch/x86/kernel/process.c):
heap_start = mmap_end + "heap_rand"
where "heap_rand" is a random variable in the [0B,32MB] range
(negligible and ignored here). For example, on Debian 8.5:
# cat /proc/"`pidof -s /usr/sbin/exim4`"/maps
...
7fa6410d6000-7fa6411c8000 r-xp 00000000 08:01 14574 /usr/sbin/exim4
7fa6413b4000-7fa6413bd000 rw-p 00000000 00:00 0
7fa6413c5000-7fa6413c7000 rw-p 00000000 00:00 0
7fa6413c7000-7fa6413c9000 r--p 000f1000 08:01 14574 /usr/sbin/exim4
7fa6413c9000-7fa6413d2000 rw-p 000f3000 08:01 14574 /usr/sbin/exim4
7fa6413d2000-7fa6413d7000 rw-p 00000000 00:00 0
7fa641b34000-7fa641b76000 rw-p 00000000 00:00 0 [heap]
7ffdf3e53000-7ffdf3ed6000 rw-p 00000000 00:00 0 [stack]
7ffdf3f3c000-7ffdf3f3e000 r-xp 00000000 00:00 0 [vdso]
7ffdf3f3e000-7ffdf3f40000 r--p 00000000 00:00 0 [vvar]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
To reach the start of the stack with the end of the heap (through the -p
memory leak in Exim) in Step 1 of our stack-clash, we must minimize the
initial heap-stack distance, and hence the initial mmap-stack distance,
and set RLIMIT_STACK to MIN_GAP (~16GB). This limits the size of our -p
argument strings on the stack to 16GB/4=4GB, and because we then leak
the same amount of heap memory through -p, the initial heap-stack
distance must be:
- longer than 4GB (the stack must be able to contain the -p argument
strings);
- shorter than 8GB (the end of the heap must be able to reach the start
of the stack during the -p memory leak).
The initial heap-stack distance (approximately the initial mmap-stack
distance, 128MB + StackRand + MmapRand, but we ignore the 128MB term
here) follows a trapezoidal Irwin-Hall distribution, and the [4GB,8GB]
range is within the first non-uniform area of this trapezoid, so the
probability that the initial heap-stack distance is in this range is:
SUM(d = 4GB; d < 8GB; d++) d / (16GB * 1TB)
= SUM(d = 0; d < 4GB; d++) (4GB + d) / (16GB * 1TB)
= SUM(d = 0; d < 2^32; d++) (2^32 + d) / (2^34 * 2^40)
~= ((2^32)*(2^32) + (2^32)*(2^32) / 2) / (2^74)
~= 3 / 2^11
~= 1 / 682
The probability of gaining rip control after the heap reaches the stack
is ~1/16 (as calculated by a 64-bit version of the small helper program
presented in IV.1.1.), and the final probability of gaining rip control
with our local Exim proof-of-concept is:
(3 / 2^11) * (1/16) ~= 1 / 10922
On our 8GB Debian 8.7 test machine, this proof-of-concept takes roughly
2 seconds per run, and has a good chance of gaining rip control after
10922 * 2 seconds ~= 6 hours:
# gdb /usr/sbin/exim4 core.6049
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
...
This GDB was configured as "x86_64-linux-gnu".
Core was generated by `/usr/sbin/exim4 -p0000000000000000000000000000000000000000000000000000000000000'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:41
41 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such file or directory.
(gdb) x/i $rip
=> 0x7ffab1be7061 <__memcpy_sse2_unaligned+65>: retq
(gdb) x/xg $rsp
0x7ffb9b294a48: 0x4141414141414141
Kernels vulnerable to offset2lib, ld.so ".dynamic" exploit
Since kernels vulnerable to offset2lib map PIEs below and close to the
stack, we tried to adapt our ld.so ".dynamic" exploit to amd64. MIN_GAP
guarantees a minimum distance of 128MB between the theoretical end of
the mmap region and the end of the stack, but the stack then grows down
to store the argument and environment strings, and may therefore occupy
the theoretical end of the mmap region (where nothing has been mapped
yet). Consequently, the end of the mmap region (where the PIE will be
mapped) slides down to the first available address, directly below the
stack guard-page and the initial stack expansion (described in II.3.2.):
7ffbb7e51000-7ffbb7e53000 r-xp 00000000 fd:03 4465810 /tmp/test64
...
7ffbb8053000-7ffbb808c000 rw-p 00002000 fd:03 4465810 /tmp/test64
7ffbb808d000-7ffc180ae000 rw-p 00000000 00:00 0 [heap]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Note: in this example, the "[stack]" is, again, incorrectly displayed as
the "[heap]" by show_map_vma() (in fs/proc/task_mmu.c).
This layout is ideal for our stack-clash exploits, but poses an
unexpected problem: because the PIE is mapped directly below the stack,
the stack cannot grow anymore, and the only free stack space is the
initial stack expansion (128KB) minus the argv[] and envp[] pointers
(which are stored there, as mentioned in II.3.2.):
- on the one hand, many argv[] and envp[] pointers, and hence many
argument and environment strings, result in a higher probability of
mapping the PIE directly below the stack;
- on the other hand, many argv[] and envp[] pointers consume most of the
initial stack expansion and do not leave enough free stack space for
ld.so to operate.
In practice, we pass 96KB of argv[] pointers to execve(), thus leaving
32KB of free stack space for ld.so, and since the size of a pointer is
8B, and the maximum size of an argument string is 128KB, we also pass
96KB/8B*128KB=1.5GB of argument strings to execve(). The resulting
probability of mapping the PIE directly below the stack is:
SUM(s = 0; s < 1.5GB - 128MB; s++) s / (16GB * 1TB)
~= ((1.5GB - 128MB)^2 / 2) / (16GB * 1TB)
~= 1 / 17331
On a 4GB Virtual Machine, each run takes 1 second, and 17331 runs take
roughly 5 hours. But we cannot add more uncertainty to this exploit, and
because of the problems discussed in IV.1.4. (null-bytes in DT_NEEDED,
but also in DT_AUXILIARY on 64-bit, etc), we were unable to overwrite
the .dynamic section with a pattern that does not significantly decrease
this exploit's probability of success.
All kernels, ld.so "hwcap" exploit
Despite this failure, we had an intuition: when the PIE is mapped
directly below the stack, the stack layout should be deterministic --
rsp should point into the 128KB of initial stack expansion, at a 32KB
offset above the start of the stack, and the only entropy should be the
8KB of sub-page randomization within the stack (arch_align_stack() in
arch/x86/kernel/process.c). The following output of our small test
program confirmed this intuition (the fourth field is the distance
between the start of the stack and our main()'s rsp when the PIE is
mapped directly below the stack):
$ grep -w sp test64.out | sort -nk4
sp 0x7ffbc271ff38 -> 28472
sp 0x7ffbb95ccff8 -> 28664
sp 0x7ffbaf062678 -> 30328
sp 0x7ffbb08736e8 -> 30440
sp 0x7ffbbc616d18 -> 32024
sp 0x7ffbc1a0fdb8 -> 32184
sp 0x7ffbb9c28ff8 -> 32760
sp 0x7ffbdbf4c178 -> 33144
sp 0x7ffbb39bc1c8 -> 33224
sp 0x7ffbebb86838 -> 34872
Surprisingly, the output of this test program contained additional
valuable information:
7ffbb7e51000-7ffbb7e53000 r-xp 00000000 fd:03 4465810 /tmp/test64
7ffbb8034000-7ffbb8037000 rw-p 00000000 00:00 0
7ffbb804d000-7ffbb804e000 rw-p 00000000 00:00 0
7ffbb804e000-7ffbb8050000 r--p 00000000 00:00 0 [vvar]
7ffbb8050000-7ffbb8052000 r-xp 00000000 00:00 0 [vdso]
7ffbb8052000-7ffbb8053000 r--p 00001000 fd:03 4465810 /tmp/test64
7ffbb8053000-7ffbb808c000 rw-p 00002000 fd:03 4465810 /tmp/test64
7ffbb808d000-7ffc180ae000 rw-p 00000000 00:00 0 [heap]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
- the distance between the end of the read-execute segment of our test
program and the start of its read-only and read-write segments is
approximately 2MB; indeed, for every ELF on amd64:
$ readelf -a /usr/bin/su | grep -wA1 LOAD
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x00000000000061b4 0x00000000000061b4 R E 200000
LOAD 0x0000000000006888 0x0000000000206888 0x0000000000206888
0x0000000000000798 0x00000000000007d0 RW 200000
$ readelf -a /lib64/ld-linux-x86-64.so.2 | grep -wA1 LOAD
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x000000000001fad0 0x000000000001fad0 R E 200000
LOAD 0x000000000001fb60 0x000000000021fb60 0x000000000021fb60
0x000000000000141c 0x00000000000015e8 RW 200000
- several objects are actually mapped inside this ~2MB hole: [vdso],
[vvar], and two anonymous mappings (7ffbb804d000-7ffbb804e000 and
7ffbb8034000-7ffbb8037000).
This discovery allowed us to adapt our ld.so "hwcap" exploit to amd64:
- we choose hardware-capabilities that are small enough to be mapped
inside this ~2MB hole, but large enough to defeat the 8KB sub-page
randomization of the stack;
- we jump over the stack guard-page, and over the read-only and
read-write segments of the PIE, and exploit ld.so as we did on i386.
This exploit's probability of success is therefore 1 when the PIE is
mapped directly below the stack, and its final probability of success is
~1/17331: it takes 1 second per run, and has a good chance of obtaining
a root-shell after 5 hours. Moreover, it works on all kernels: if a SUID
binary is not a PIE, or if the kernel is not vulnerable to offset2lib,
we simply jump over ld.so's read-write segment, instead of the PIE's.
For example, on Fedora 25, when the exploit succeeds and loads our own
library /var/tmp/a (the 7ffbabbef000-7ffbabca7000 mapping contains the
hardware-capabilities that we smash):
55a0c9e8d000-55a0c9e91000 r-xp 00000000 fd:00 112767 /usr/libexec/cockpit-polkit
55a0ca091000-55a0ca093000 rw-p 00004000 fd:00 112767 /usr/libexec/cockpit-polkit
7ffbab603000-7ffbab604000 r-xp 00000000 fd:00 4866583 /var/tmp/a
7ffbab604000-7ffbab803000 ---p 00001000 fd:00 4866583 /var/tmp/a
7ffbab803000-7ffbab804000 r--p 00000000 fd:00 4866583 /var/tmp/a
7ffbab804000-7ffbaba86000 rw-p 00000000 00:00 0
7ffbaba86000-7ffbabaab000 r-xp 00000000 fd:00 4229637 /usr/lib64/ld-2.24.so
7ffbabbef000-7ffbabca7000 rw-p 00000000 00:00 0
7ffbabca7000-7ffbabca9000 r--p 00000000 00:00 0 [vvar]
7ffbabca9000-7ffbabcab000 r-xp 00000000 00:00 0 [vdso]
7ffbabcab000-7ffbabcad000 rw-p 00025000 fd:00 4229637 /usr/lib64/ld-2.24.so
7ffbabcad000-7ffbabcae000 rw-p 00000000 00:00 0
7ffbabcaf000-7ffc0bcf0000 rw-p 00000000 00:00 0 [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
========================================================================
IV.2. OpenBSD
========================================================================
========================================================================
IV.2.1. Maximum RLIMIT_STACK vulnerability (CVE-2017-1000372)
========================================================================
The OpenBSD kernel limits the maximum size of the user-space stack
(RLIMIT_STACK) to MAXSSIZ (32MB); the execve() system-call allocates a
MAXSSIZ memory region for the stack and divides it in two:
- the second part, effectively the user-space stack, is mapped
PROT_READ|PROT_WRITE at the end of this stack memory region, and
occupies RLIMIT_STACK bytes (by default 8MB for root processes, and
4MB for user processes);
- the first part, effectively a large stack guard-page, is mapped
PROT_NONE at the start of this stack memory region, and occupies
MAXSSIZ - RLIMIT_STACK bytes.
Unfortunately, we discovered that if an attacker sets RLIMIT_STACK to
MAXSSIZ, he eliminates the PROT_NONE part of the stack region, and hence
the stack guard-page itself (CVE-2017-1000372). For example:
# sh -c 'ulimit -S -s; procmap -a -P'
8192
Start End Size Offset rwxpc RWX I/W/A Dev Inode - File
...
14cf6000-14cfafff 20k 00000000 r-xp+ (rwx) 1/0/0 00:03 52375 - /usr/sbin/procmap [0xdb29ce10]
...
84a7b000-84a7bfff 4k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ anon ]
cd7db000-cefdafff 24576k 00000000 ---p+ (rwx) 1/0/0 00:00 0 - [ stack ]
cefdb000-cf7cffff 8148k 00000000 rw-p+ (rwx) 1/0/0 00:00 0 - [ stack ]
cf7d0000-cf7dafff 44k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ stack ]
total 10348k
# sh -c 'ulimit -S -s `ulimit -H -s`; procmap -a -P'
Start End Size Offset rwxpc RWX I/W/A Dev Inode - File
...
1a47f000-1a483fff 20k 00000000 r-xp+ (rwx) 1/0/0 00:03 52375 - /usr/sbin/procmap [0xdb29ce10]
...
8a3c8000-8a3c9fff 8k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ anon ]
cd7c9000-cf7bffff 32732k 00000000 rw-p+ (rwx) 1/0/0 00:00 0 - [ stack ]
cf7c0000-cf7c8fff 36k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ stack ]
total 33992k
A remote attacker cannot exploit this vulnerability, because he cannot
modify RLIMIT_STACK; but a local attacker can set RLIMIT_STACK to
MAXSSIZ, and:
- Step 1: malloc()ate almost 2GB of heap memory, until the heap reaches
the start of the stack region;
- Steps 2 and 3: consume MAXSSIZ (32MB) of stack memory, until the
stack-pointer reaches the start of the stack region (Step 2) and moves
into the heap (Step 3);
- Step 4: smash the stack with the heap (Step 4a) or smash the heap with
the stack (Step 4b).
========================================================================
IV.2.2. Recursive qsort() vulnerability (CVE-2017-1000373)
========================================================================
To complete Step 2, a recursive function is needed, and the first
possibly recursive function that we investigated is qsort(). On the one
hand, glibc's _quicksort() function (in stdlib/qsort.c) is non-recursive
(iterative): it uses a small, specialized stack of partition structures
(two pointers, low and high), and guarantees that no more than 32
partitions (on i386) or 64 partitions (on amd64) are pushed onto this
stack, because it always pushes the larger of two sub-partitions and
iterates on the smaller partition.
On the other hand, BSD's qsort() function is recursive: it always
recurses on the first sub-partition, and iterates on the second
sub-partition; but instead, it should always recurse on the smaller
sub-partition, and iterate on the larger sub-partition (CVE-2017-1000373
in OpenBSD, CVE-2017-1000378 in NetBSD, and CVE-2017-1082 in FreeBSD).
In theory, because BSD's qsort() is not randomized, an attacker can
construct a pathological input array of N elements that causes qsort()
to deterministically recurse N times. In practice, because this qsort()
uses the median-of-three medians-of-three selection of a pivot element
(the "ninther"), our attack constructs an input array of N elements that
causes qsort() to recurse N/4 times.
========================================================================
IV.2.3. /usr/bin/at proof-of-concept
========================================================================
/usr/bin/at is SGID-crontab (which can be escalated to full root
privileges) because it must be able to create ("at -t"), list ("at -l"),
and remove ("at -r") job-files in the /var/cron/atjobs directory:
-r-xr-sr-x 4 root crontab 31376 Jul 26 2016 /usr/bin/at
drwxrwx--T 2 root crontab 512 Jul 26 2016 /var/cron/atjobs
To demonstrate that OpenBSD's RLIMIT_STACK and qsort() vulnerabilities
can be transformed into powerful primitives such as heap corruption, we
developed a proof-of-concept against "at -l" (the list_jobs() function):
- Step 1 (Clash): first, list_jobs() malloc()ates an atjob structure for
each file in /var/cron/atjobs -- if we create 40M job-files, then the
heap reaches the stack, but we do not exhaust the address-space;
- Steps 2 and 3 (Run and Jump): second, list_jobs() qsort()s the
malloc()ated jobs -- if we construct their time-stamps with our
qsort() attack, then we can cause qsort() to recurse 40M/4=10M times
and consume at least 10M*4B=40MB of stack memory (each recursive call
to qsort() consumes at least 4B, the return-address) and move the
stack-pointer into the heap;
- Step 4b (Smash the heap with the stack): last, list_jobs() free()s the
malloc()ated jobs, and abort()s with an error message -- OpenBSD's
hardened malloc() implementation detects that the heap has been
corrupted by the last recursive calls to qsort().
This naive version of our /usr/bin/at proof-of-concept poses two major
problems:
- Our pathological input array of N=40M elements cannot be sorted (Step
2 never finishes because it exhibits qsort()'s worst-case behavior,
N^2). To solve this problem, we divide the input array in two:
. the first, pathological part contains only n=(33MB/176B)*4=768K
elements that are needed to complete Steps 2 and 3, and cause
qsort() to recurse n/4 times and consume (n/4)*176B=33MB of stack
memory (MAXSSIZ+1MB) as each recursive call to qsort() consumes 176B
of stack memory;
. the second, innocuous part contains the remaining N-n=39M elements
that are needed to complete Step 1, but not Steps 2 and 3, and are
therefore swapped into the second, iterative partition of the first
recursive call to qsort().
- We were unable to create 40M files in /var/cron/atjobs: after one
week, OpenBSD's default filesystem (ffs) had created only 4M files,
and the rate of file creation had dropped from 25 files/second to 4
files/second. We did not solve this problem, but nevertheless wanted
to validate our proof-of-concept:
. we transformed it into an LD_PRELOAD library that intercepts calls
to readdir() and fstatat(), and pretends that our 40M files in
/var/cron/atjobs exist;
. we made /var/cron/atjobs world-readable and LD_PRELOADed our library
into a non-SGID copy of /usr/bin/at;
. after about an hour, "at" reports random heap corruptions:
# chmod o+r /var/cron/atjobs
# chmod o+r /var/cron/at.deny
$ ulimit -c 0
$ ulimit -S -d `ulimit -H -d`
$ ulimit -S -s `ulimit -H -s`
$ ulimit -S -a
...
coredump(blocks) 0
data(kbytes) 3145728
stack(kbytes) 32768
...
$ cp /usr/bin/at .
$ LD_PRELOAD=./OpenBSD_at.so ./at -l -v -q x > /dev/null
initializing jobkeys
finalizing jobkeys
reading jobs
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
sorting jobs
at(78717) in free(): error: chunk info corrupted
Abort trap
$ LD_PRELOAD=./OpenBSD_at.so ./at -l -v -q x > /dev/null
initializing jobkeys
finalizing jobkeys
reading jobs
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
sorting jobs
at(14184) in free(): error: modified chunk-pointer 0xcd6d0120
Abort trap
========================================================================
IV.3. NetBSD
========================================================================
Like OpenBSD, NetBSD is vulnerable to the maximum RLIMIT_STACK
vulnerability (CVE-2017-1000374): if a local attacker sets RLIMIT_STACK
to MAXSSIZ, he eliminates the PROT_NONE part of the stack region -- the
stack guard-page itself. Unlike OpenBSD, however, NetBSD:
- defines MAXSSIZ to 64MB on i386 (128MB on amd64);
- maps the run-time link-editor ld.so directly below the stack region,
even if ASLR is enabled (CVE-2017-1000375):
$ sh -c 'ulimit -S -s; pmap -a -P'
2048
Start End Size Offset rwxpc RWX I/W/A Dev Inode - File
08048000-0804dfff 24k 00000000 r-xp+ (rwx) 1/0/0 00:00 21706 - /usr/bin/pmap [0xc5c8f0b8]
...
bbbee000-bbbfefff 68k 00000000 r-xp+ (rwx) 1/0/0 00:00 107525 - /libexec/ld.elf_so [0xc535f580]
bbbff000-bbbfffff 4k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ anon ]
bbc00000-bf9fffff 63488k 00000000 ---p+ (rwx) 1/0/0 00:00 0 - [ stack ]
bfa00000-bfbeffff 1984k 00000000 rw-p+ (rwx) 1/0/0 00:00 0 - [ stack ]
bfbf0000-bfbfffff 64k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ stack ]
total 9528k
$ sh -c 'ulimit -S -s `ulimit -H -s`; pmap -a -P'
Start End Size Offset rwxpc RWX I/W/A Dev Inode - File
08048000-0804dfff 24k 00000000 r-xp+ (rwx) 1/0/0 00:00 21706 - /usr/bin/pmap [0xc5c8f0b8]
...
bbbee000-bbbfefff 68k 00000000 r-xp+ (rwx) 1/0/0 00:00 107525 - /libexec/ld.elf_so [0xc535f580]
bbbff000-bbbfffff 4k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ anon ]
bbc00000-bfbeffff 65472k 00000000 rw-p+ (rwx) 1/0/0 00:00 0 - [ stack ]
bfbf0000-bfbfffff 64k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ stack ]
total 73016k
# cp /usr/bin/pmap .
# paxctl +A ./pmap
# sh -c 'ulimit -S -s `ulimit -H -s`; ./pmap -a -P'
Start End Size Offset rwxpc RWX I/W/A Dev Inode - File
08048000-0804dfff 24k 00000000 r-xp+ (rwx) 1/0/0 00:00 172149 - /tmp/pmap [0xc5cb3c64]
...
bbbee000-bbbfefff 68k 00000000 r-xp+ (rwx) 1/0/0 00:00 107525 - /libexec/ld.elf_so [0xc535f580]
bbbff000-bbbfffff 4k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ anon ]
bbc00000-bf1bffff 55040k 00000000 rw-p+ (rwx) 1/0/0 00:00 0 - [ stack ]
bf1c0000-bf1cefff 60k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ stack ]
total 62580k
Consequently, a local attacker can set RLIMIT_STACK to MAXSSIZ,
eliminate the stack guard-page, and:
- skip Step 1, because ld.so's read-write segment is naturally mapped
directly below the stack region;
- Steps 2 and 3: consume 64MB (MAXSSIZ) of stack memory (for example,
through the recursive qsort() vulnerability, CVE-2017-1000378) until
the stack-pointer reaches the start of the stack region (Step 2) and
moves into ld.so's read-write segment (Step 3);
- Step 4b: smash ld.so's read-write segment with the stack.
We did not try to exploit this vulnerability, nor did we search for a
vulnerable SUID or SGID binary, but we wrote a simple proof-of-concept,
and some of the following crashes may be exploitable:
$ sh -c 'ulimit -S -s `ulimit -H -s`; ./NetBSD_CVE-2017-1000375 0x04000000'
[1] Segmentation fault ./NetBSD_CVE-201...
$ sh -c 'ulimit -S -s `ulimit -H -s`; ./NetBSD_CVE-2017-1000375 0x03000000'
...
$ sh -c 'ulimit -S -s `ulimit -H -s`; ./NetBSD_CVE-2017-1000375 0x03ec5000'
$ sh -c 'ulimit -S -s `ulimit -H -s`; ./NetBSD_CVE-2017-1000375 0x03ec5400'
[1] Segmentation fault ./NetBSD_CVE-201...
$ sh -c 'ulimit -S -s `ulimit -H -s`; gdb ./NetBSD_CVE-2017-1000375'
GNU gdb (GDB) 7.7.1
...
(gdb) run 0x03ec5400
Program received signal SIGSEGV, Segmentation fault.
0xbbbf448d in _rtld_symlook_default () from /usr/libexec/ld.elf_so
(gdb) x/i $eip
=> 0xbbbf448d <_rtld_symlook_default+185>: mov %edx,(%esi,%edi,4)
(gdb) info registers
esi 0xbabae890 -1162155888
edi 0x0 0
...
(gdb) run 0x03ec5800
Program received signal SIGSEGV, Segmentation fault.
0xbbbf4465 in _rtld_symlook_default () from /usr/libexec/ld.elf_so
(gdb) x/i $eip
=> 0xbbbf4465 <_rtld_symlook_default+145>: mov 0x4(%ecx),%edx
(gdb) info registers
ecx 0x41414141 1094795585
...
(gdb) run 0x03ec5c00
Program received signal SIGSEGV, Segmentation fault.
0xbbbf4408 in _rtld_symlook_default () from /usr/libexec/ld.elf_so
(gdb) x/i $eip
=> 0xbbbf4408 <_rtld_symlook_default+52>: mov (%eax),%esi
(gdb) info registers
eax 0x41414141 1094795585
...
========================================================================
IV.4. FreeBSD
========================================================================
========================================================================
IV.4.1. setrlimit() RLIMIT_STACK vulnerability (CVE-2017-1085)
========================================================================
FreeBSD's kern_proc_setrlimit() function contains the following comment
and code:
/*
* Stack is allocated to the max at exec time with only
* "rlim_cur" bytes accessible. If stack limit is going
* up make more accessible, if going down make inaccessible.
*/
if (limp->rlim_cur != oldssiz.rlim_cur) {
...
if (limp->rlim_cur > oldssiz.rlim_cur) {
prot = p->p_sysent->sv_stackprot;
size = limp->rlim_cur - oldssiz.rlim_cur;
addr = p->p_sysent->sv_usrstack -
limp->rlim_cur;
} else {
prot = VM_PROT_NONE;
size = oldssiz.rlim_cur - limp->rlim_cur;
addr = p->p_sysent->sv_usrstack -
oldssiz.rlim_cur;
}
...
(void)vm_map_protect(&p->p_vmspace->vm_map,
addr, addr + size, prot, FALSE);
}
OpenBSD's and NetBSD's dosetrlimit() function contains the same comment,
which accurately describes the layout of their user-space stack region.
Unfortunately, FreeBSD's kern_proc_setrlimit() comment and code are
incorrect, as hinted at in exec_new_vmspace():
/*
* Destroy old address space, and allocate a new stack
* The new stack is only SGROWSIZ large because it is grown
* automatically in trap.c.
*/
and vm_map_stack_locked():
/*
* We initially map a stack of only init_ssize. We will grow as
* needed later.
where init_ssize is SGROWSIZ (128KB), not MAXSSIZ (64MB on i386),
because "init_ssize = (max_ssize < growsize) ? max_ssize : growsize;"
(and max_ssize is MAXSSIZ, and growsize is SGROWSIZ).
As a result, if a program calls setrlimit() to increase RLIMIT_STACK,
vm_map_protect() may turn a read-only memory region below the stack into
a read-write region (CVE-2017-1085), as demonstrated by the following
proof-of-concept:
% ./FreeBSD_CVE-2017-1085
Segmentation fault
% ./FreeBSD_CVE-2017-1085 setrlimit to the max
char at 0xbd155000: 41
========================================================================
IV.4.2. Stack guard-page disabled by default (CVE-2017-1083)
========================================================================
The FreeBSD kernel implements a 4KB stack guard-page, and recent
versions of the FreeBSD Installer offer it as a system hardening option.
Unfortunately, it is disabled by default (CVE-2017-1083):
% sysctl security.bsd.stack_guard_page
security.bsd.stack_guard_page: 0
========================================================================
IV.4.3. Stack guard-page vulnerabilities (CVE-2017-1084)
========================================================================
- If FreeBSD's stack guard-page is enabled, its entire logic is
implemented in vm_map_growstack(): this function guarantees a minimum
distance of 4KB (the stack guard-page) between the start of the stack
and the end of the memory region that is mapped below (but the stack
guard-page is not physically mapped into the address-space).
Unfortunately, this guarantee is given only when the stack grows down
and clashes with the memory region mapped below, but not if the memory
region mapped below grows up and clashes with the stack: this
vulnerability effectively eliminates the stack guard-page
(CVE-2017-1084). In our proof-of-concept:
. we allocate anonymous mmap()s of 4KB, until the end of an anonymous
mmap() reaches the start of the stack [Step 1];
. we call a recursive function until the stack-pointer reaches the
start of the stack and moves into the anonymous mmap() directly
below [Step 2];
. but we do not jump over the stack guard-page, because each call to
the recursive function allocates (and fully writes to) a 1KB
stack-based buffer [Step 3];
. and we do not crash into the stack guard-page, because CVE-2017-1084
has effectively eliminated the stack guard-page in Step 1.
# sysctl security.bsd.stack_guard_page=1
security.bsd.stack_guard_page: 0 -> 1
% ./FreeBSD_CVE-2017-FGPU
char at 0xbfbde000: 41
- vm_map_growstack() implements most of the stack guard-page logic in
the following code:
/*
* Growing downward.
*/
/* Get the preliminary new entry start value */
addr = stack_entry->start - grow_amount;
/*
* If this puts us into the previous entry, cut back our
* growth to the available space. Also, see the note above.
*/
if (addr < end) {
stack_entry->avail_ssize = max_grow;
addr = end;
if (stack_guard_page)
addr += PAGE_SIZE;
}
where:
. addr is the new start of the stack;
. stack_entry->start is the old start of the stack;
. grow_amount is the size of the stack expansion;
. end is the end of the memory region below the stack.
Unfortunately, the "addr < end" test should be "addr <= end": if addr,
the new start of the stack, is equal to end, the end of the memory
region mapped below, then the stack guard-page is eliminated
(CVE-2017-1084). In our proof-of-concept:
. we allocate anonymous mmap()s of 4KB, until the end of an anonymous
mmap() reaches a randomly chosen distance below the start of the
stack [Step 1];
. we call a recursive function until the stack-pointer reaches the
start of the stack, and the stack expansion reaches the end of the
anonymous mmap() below [Step 2];
. we do not jump over the stack guard-page, because each call to the
recursive function allocates (and fully writes to) a 1KB stack-based
buffer [Step 3];
. and we crash into the stack guard-page most of the time;
. but we survive with a probability of 4KB/128KB=1/32 (grow_amount is
always a multiple of SGROWSIZ, 128KB) because CVE-2017-1084 has
effectively eliminated the stack guard-page in Step 2.
% sysctl security.bsd.stack_guard_page
security.bsd.stack_guard_page: 1
% sh -c 'while true; do ./FreeBSD_CVE-2017-FGPE; done'
Segmentation fault
char at 0xbe45e000: 41; final dist 6097 (24778705)
Segmentation fault
Segmentation fault
Segmentation fault
...
Segmentation fault
Segmentation fault
Segmentation fault
char at 0xbd25e000: 41; final dist 7036 (43654012)
Segmentation fault
Segmentation fault
Segmentation fault
...
Segmentation fault
Segmentation fault
Segmentation fault
char at 0xbd29e000: 41; final dist 5331 (43390163)
Segmentation fault
Segmentation fault
Segmentation fault
...
In contrast, if FreeBSD's stack guard-page is disabled, our
proof-of-concept always survives:
# sysctl security.bsd.stack_guard_page=0
security.bsd.stack_guard_page: 1 -> 0
% sh -c 'while true; do ./FreeBSD_CVE-2017-FGPE; done'
char at 0xbe969000: 41; final dist 89894 (19488550)
char at 0xbfa6d000: 41; final dist 74525 (1647389)
char at 0xbf4df000: 41; final dist 78 (7471182)
char at 0xbe9e4000: 41; final dist 112397 (18986765)
char at 0xbf693000: 41; final dist 49811 (5685907)
char at 0xbf533000: 41; final dist 51037 (7128925)
char at 0xbd799000: 41; final dist 26043 (38167995)
char at 0xbd54b000: 11; final dist 83754 (40585002)
char at 0xbe176000: 41; final dist 36992 (27824256)
char at 0xbfa91000: 41; final dist 57449 (1499241)
char at 0xbd1b9000: 41; final dist 26115 (44328451)
char at 0xbd1c8000: 41; final dist 94852 (44266116)
char at 0xbf73a000: 41; final dist 22276 (5003012)
char at 0xbe6b1000: 41; final dist 58854 (22341094)
char at 0xbeb81000: 41; final dist 124727 (17295159)
char at 0xbfb35000: 41; final dist 43174 (829606)
...
- FreeBSD's thread library (libthr) mmap()s a secondary PROT_NONE stack
guard-page at a distance RLIMIT_STACK below the end of the stack:
# sysctl security.bsd.stack_guard_page=1
security.bsd.stack_guard_page: 0 -> 1
% sh -c 'exec procstat -v $$'
PID START END PRT RES PRES REF SHD FLAG TP PATH
2779 0x8048000 0x8050000 r-x 8 8 1 0 CN-- vn /usr/bin/procstat
...
2779 0x28400000 0x28800000 rw- 22 35 2 0 ---- df
2779 0xbfbdf000 0xbfbff000 rwx 3 3 1 0 ---D df
2779 0xbfbff000 0xbfc00000 r-x 1 1 23 0 ---- ph
% sh -c 'LD_PRELOAD=libthr.so exec procstat -v $$'
PID START END PRT RES PRES REF SHD FLAG TP PATH
2798 0x8048000 0x8050000 r-x 8 8 1 0 CN-- vn /usr/bin/procstat
...
2798 0x28400000 0x28800000 rw- 23 35 2 0 ---- df
2798 0xbbbfe000 0xbbbff000 --- 0 0 0 0 ---- --
2798 0xbfbdf000 0xbfbff000 rwx 3 3 1 0 ---D df
2798 0xbfbff000 0xbfc00000 r-x 1 1 23 0 ---- ph
Unfortunately, this secondary stack guard-page does not mitigate the
vulnerabilities that we discovered in FreeBSD's stack guard-page
implementation:
% sysctl security.bsd.stack_guard_page
security.bsd.stack_guard_page: 1
% sh -c 'LD_PRELOAD=libthr.so ./FreeBSD_CVE-2017-FGPU'
char at 0xbfbde000: 41
% sh -c 'while true; do LD_PRELOAD=libthr.so ./FreeBSD_CVE-2017-FGPE; done'
Segmentation fault
Segmentation fault
Segmentation fault
...
Segmentation fault
Segmentation fault
Segmentation fault
char at 0xbda5e000: 41; final dist 3839 (35262207)
Segmentation fault
Segmentation fault
Segmentation fault
...
Segmentation fault
Segmentation fault
Segmentation fault
char at 0xbdb1e000: 41; final dist 3549 (34475485)
Segmentation fault
Segmentation fault
Segmentation fault
...
========================================================================
IV.4.4. Remote exploitation
========================================================================
Because FreeBSD's stack guard-page is disabled by default, we tried (and
failed) to remotely exploit a test service vulnerable to:
- an unlimited memory leak that allows us to malloc()ate gigabytes of
memory;
- a limited recursion that allows us to allocate up to 1MB of stack
memory.
FreeBSD's malloc() implementation (jemalloc) mmap()s 4MB chunks of
anonymous memory that are aligned on multiples of 4MB. The first 4MB
mmap() chunk starts at 0x28400000, and the last 4MB mmap() chunk ends at
0xbf800000, because the stack itself already ends at 0xbfc00000; but it
is impossible to cover this final mmap-stack distance (almost 4MB) with
the limited recursion (1MB) of our test service.
break(0x80499b0) = 0 (0x0)
break(0x8400000) = 0 (0x0)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 672845824 (0x281ad000)
mmap(0x285ad000,2437120,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 677040128 (0x285ad000)
munmap(0x281ad000,2437120) = 0 (0x0)
mmap(0x0,8388608,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 679477248 (0x28800000)
munmap(0x28c00000,4194304) = 0 (0x0)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 683671552 (0x28c00000)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 687865856 (0x29000000)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 692060160 (0x29400000)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 696254464 (0x29800000)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 700448768 (0x29c00000)
...
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = -1103101952 (0xbe400000)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = -1098907648 (0xbe800000)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = -1094713344 (0xbec00000)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = -1090519040 (0xbf000000)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = -1086324736 (0xbf400000)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) ERR#12 'Cannot allocate memory'
break(0x8800000) = 0 (0x0)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) ERR#12 'Cannot allocate memory'
break(0x8c00000) = 0 (0x0)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) ERR#12 'Cannot allocate memory'
break(0x9000000) = 0 (0x0)
...
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) ERR#12 'Cannot allocate memory'
break(0x27c00000) = 0 (0x0)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) ERR#12 'Cannot allocate memory'
break(0x28000000) = 0 (0x0)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) ERR#12 'Cannot allocate memory'
break(0x28400000) ERR#12 'Cannot allocate memory'
========================================================================
IV.5. Solaris >= 11.1
========================================================================
========================================================================
IV.5.1. Minimal RLIMIT_STACK vulnerability (CVE-2017-3630)
========================================================================
On Solaris, ASLR can be enabled or disabled for each ELF binary with the
SUNW_ASLR dynamic section entry (man elfedit):
$ elfdump /usr/bin/rsh | egrep 'ASLR|NX'
[39] SUNW_ASLR 0x2 ENABLE
[40] SUNW_NXHEAP 0x2 ENABLE
[41] SUNW_NXSTACK 0x2 ENABLE
Without ASLR
If ASLR is disabled:
- a stack region of size RLIMIT_STACK is reserved in the address-space;
- a 4KB stack guard-page is mapped directly below this stack region;
- the runtime linker ld.so is mapped directly below this stack
guard-page.
$ cp /usr/bin/sleep .
$ chmod u+w ./sleep
$ elfedit -e 'dyn:sunw_aslr disable' ./sleep
$ sh -c 'ulimit -S -s; ./sleep 3 & pmap -r ${!}'
8192
7176: ./sleep 3
...
FE7B1000 228K r-x---- /lib/ld.so.1
FE7FA000 8K rwx---- /lib/ld.so.1
FE7FC000 8K rwx---- /lib/ld.so.1
FE7FF000 8192K rw----- [ stack ]
total 17148K
$ sh -c 'ulimit -S -s 64; ./sleep 3 & pmap -r ${!}'
7244: ./sleep 3
...
FEFA1000 228K r-x---- /lib/ld.so.1
FEFEA000 8K rwx---- /lib/ld.so.1
FEFEC000 8K rwx---- /lib/ld.so.1
FEFEF000 64K rw----- [ stack ]
total 9020K
On the one hand, a local attacker can exploit this simplified
stack-clash:
- Step 1 (Clash) is not needed, because ld.so is naturally mapped
directly below the stack (the distance between the end of ld.so's
read-write segment and the start of the stack is 4KB, the stack
guard-page);
- Step 2 (Run) is not needed, because a local attacker can set
RLIMIT_STACK to just a few kilobytes, reserve a very small stack
region, and hence shorten the distance between the stack-pointer and
the start of the stack (and the end of ld.so's read-write segment);
- Step 3 (Jump) can be completed with a large stack-based buffer that is
not fully written to;
- Step 4b (Smash) can be completed by overwriting the function pointers
in ld.so's read-write segment with the contents of a stack-based
buffer.
Such a simplified stack-clash exploit was first mentioned in Gael
Delalleau's 2005 presentation (slide 30).
On the other hand, a remote attacker cannot modify RLIMIT_STACK and must
complete Step 2 (Run) with a recursive function that consumes the 8MB
(the default RLIMIT_STACK) between the stack-pointer and the start of
the stack.
With ASLR
If ASLR is enabled:
- a stack region of size RLIMIT_STACK is reserved in the address-space;
- a 4KB stack guard-page is mapped directly below this stack region;
- the runtime linker ld.so is mapped below this stack guard-page, but at
a random distance (within a [4KB,128MB] range) -- effectively a large,
secondary stack guard-page.
On the one hand, a local attacker can run the simplified "Without ASLR"
stack-clash exploit until the ld.so-stack distance is minimal -- with a
probability of 4KB/128MB=1/32K, the distance between the end of ld.so's
read-write segment and the start of the stack is exactly 8KB: the stack
guard-page plus the minimum distance between the stack guard-page and
ld.so (CVE-2017-3629).
On the other hand, a remote attacker must complete Step 2 (Run) with a
recursive function, and:
- has a good chance of exploiting this stack-clash after 32K connections
(when the ld.so-stack distance is minimal) if the remote service
re-execve()s (re-randomizes the ld.so-stack distance for each new
connection);
- cannot exploit this stack-clash if the remote service does not
re-execve() (does not re-randomize the ld.so-stack distance for each
new connection) unless the attacker is able to restart the service,
reboot the server, or target a 32K-server farm.
========================================================================
IV.5.2. /usr/bin/rsh exploit
========================================================================
/usr/bin/rsh is SUID-root and its main() function allocates a 50KB
stack-based buffer that is not written to and can be used to jump over
the stack guard-page, into ld.so's read-write segment, in Step 3 of our
simplified stack-clash exploit.
Next, we discovered a general method for gaining eip control in Step 4b:
setlocale(LC_ALL, ""), called by the main() function of /usr/bin/rsh and
other SUID binaries, copies the LC_ALL environment variable to several
stack-based buffers and thus smashes ld.so's read-write segment and
overwrites some of ld.so's function pointers.
Last, we execute our own shell-code: we return-into-binary (/usr/bin/rsh
is not a PIE), to an instruction that reliably jumps into a copy of our
LC_ALL environment variable in ld.so's read-write segment, which is in
fact read-write-executable. For example, after we gain control of eip:
- on Solaris 11.1, we return to a "pop; pop; ret" instruction, because a
pointer to our shell-code is stored at an 8-byte offset from esp;
- on Solaris 11.3, we return to a "call *0xc(%ebp)" instruction, because
a pointer to our shell-code is stored at a 12-byte offset from ebp.
Our Solaris exploit brute-forces the random ld.so-stack distance and two
parameters:
- the RLIMIT_STACK;
- the length of the LC_ALL environment variable.
========================================================================
IV.5.3. Forced-Privilege vulnerability (CVE-2017-3631)
========================================================================
/usr/bin/rsh is SUID-root, but the shell that we obtained in Step 4b of
our stack-clash exploit did not grant us full root privileges, only
net_privaddr, the privilege to bind to a privileged port number.
Disappointed by this result, we investigated and found:
$ ggrep -r /usr/bin/rsh /etc 2>/dev/null
/etc/security/exec_attr.d/core-os:Forced Privilege:solaris:cmd:RO::/usr/bin/rsh:privs=net_privaddr
$ /usr/bin/rsh -h
/usr/bin/rsh: illegal option -- h
usage: rsh [ -PN / -PO ] [ -l login ] [ -n ] [ -k realm ] [ -a ] [ -x ] [ -f / -F ] host command
rsh [ -PN / -PO ] [ -l login ] [ -k realm ] [ -a ] [ -x ] [ -f / -F ] host
# cat truss.out
...
7319: execve("/usr/bin/rsh", 0xA9479C548, 0xA94792808) argc = 2
7319: *** FPRIV: P/E: net_privaddr ***
...
Unfortunately, this Forced-Privilege protection is based on the pathname
of SUID-root binaries, which can be execve()d through hard-links, under
different pathnames (CVE-2017-3631). For example, we discovered that
readable SUID-root binaries can be execve()d through hard-links in
/proc:
$ sleep 3 < /usr/bin/rsh & /proc/${!}/fd/0 -h
[1] 7333
/proc/7333/fd/0: illegal option -- h
usage: rsh [ -PN / -PO ] [ -l login ] [ -n ] [ -k realm ] [ -a ] [ -x ] [ -f / -F ] host command
rsh [ -PN / -PO ] [ -l login ] [ -k realm ] [ -a ] [ -x ] [ -f / -F ] host
# cat truss.out
...
7335: execve("/proc/7333/fd/0", 0xA947CA508, 0xA94792808) argc = 2
7335: *** SUID: ruid/euid/suid = 100 / 0 / 0 ***
...
This vulnerability allows us to bypass the Forced-Privilege protection
and obtain full root privileges with our /usr/bin/rsh exploit.
========================================================================
V. Acknowledgments
========================================================================
We thank the members of the distros list, Oracle/Solaris, Exim, Sudo,
security@kernel.org, grsecurity/PaX, and OpenBSD. SEC Consult Vulnerability Lab Security Advisory < 20190904-0 >
=======================================================================
title: Multiple vulnerabilities
product: Cisco RV340, Cisco RV340W, Cisco RV345, Cisco RV345P,
Cisco RV260, Cisco RV260P, Cisco RV260W, Cisco 160,
Cisco 160W
vulnerable version: Cisco RV34X - 1.0.02.16, Cisco RV16X/26X - 1.0.00.15
fixed version: see "Solution"
CVE number: -
impact: High
homepage: https://www.cisco.com/
found: 2019-05-15
by: T. Weber, S. Viehböck (Office Vienna)
IoT Inspector
SEC Consult Vulnerability Lab
An integrated part of SEC Consult
Europe | Asia | North America
https://www.sec-consult.com
=======================================================================
Vendor description:
-------------------
"Securely connecting your small business to the outside world is as important
as connecting your internal network devices to one another. Cisco Small
Business RV Series Routers offer virtual private networking (VPN) technology
so your remote workers can connect to your network through a secure Internet
pathway."
Source: https://www.cisco.com/c/en/us/products/routers/small-business-rv-series-routers/index.html
Business recommendation:
------------------------
We want to thank Cisco for the very quick and professional response and great
coordination. Customers are urged to update the firmware of their devices.
Vulnerability overview/description:
-----------------------------------
1) Hardcoded Credentials
The device contains hardcoded users and passwords which can be used to login
via SSH on an emulated device at least.
During the communication with Cisco it turned out that:
"Accounts like the 'debug-admin' and 'root' can not be accessed
from console port, CLI or webui".
Therefore, these accounts had no real functionality and cannot be used for
malicious actions. The outdated version was found by IoT Inspector. One of
the discovered vulnerabilities (CVE-2015-7547, "getaddrinfo() buffer overflow")
was verified by using the MEDUSA scalable firmware runtime.
3) Known BusyBox Vulnerabilities
The used BusyBox toolkit in version 1.23.2 is outdated and contains multiple
known vulnerabilities. The outdated version was found by IoT Inspector.
One of the discovered vulnerabilities (CVE-2017-16544) was verified by using
the MEDUSA scaleable firmware runtime.
4) Multiple Vulnerabilities - IoT Inspector Report
Further information can be found in IoT Inspector report:
https://r.sec-consult.com/ciscoiot
Proof of concept:
-----------------
1) Hardcoded Credentials
The following hardcoded hashes were found in the 'shadow' file of the firmware:
root:$1$hPNSjUZA$7eKqEpqVYltt9xJ6f0OGf0:15533:0:99999:7:::
debug-admin:$1$.AAm0iJ4$na9wZwly9pSrdS8MhcGKw/:15541:0:99999:7:::
[...]
The undocumented user 'debug-admin' is also contained in this file.
Starting the dropbear daemon as background process on emulated firmware:
-------------------------------------------------------------------------------
# dropbear -E
# [1109] <timestamp> Running in background
#
# [1112] <timestamp> Child connection from <IP>:52718
[1112] <timestamp> /var must be owned by user or root, and not writable by others
[1112] <timestamp> Password auth succeeded for 'debug-admin' from <IP>:52718
-------------------------------------------------------------------------------
Log on via another host connected to the same network. For this PoC the
password of the debug-admin was changed in the 'shadow' file.
-------------------------------------------------------------------------------
[root@localhost medusa]# ssh debug-admin@<IP> /bin/ash -i
debug-admin@<IP>'s password:
/bin/ash: can't access tty; job control turned off
BusyBox v1.23.2 (2018-11-21 18:22:56 IST) built-in shell (ash)
/tmp $
-------------------------------------------------------------------------------
The 'debug-admin' user has the same privileges like 'root'. This can be
determined from the corresponding sudoers file in the firmware:
[...]
## User privilege specification
##
root ALL=(ALL) ALL
debug-admin ALL=(ALL) ALL
## Uncomment to allow members of group wheel to execute any command
# %wheel ALL=(ALL) ALL
[...]
During the communication with Cisco it turned out that:
"Accounts like the 'debug-admin' and 'root' can not be accessed
from console port, CLI or webui".
Therefore, these accounts had no real functionality and cannot be used for
malicious actions.
The getaddrinfo() buffer overflow vulnerability was checked with the help of
the exploit code from https://github.com/fjserna/CVE-2015-7547. It was compiled
and executed on the emulated device to test the system.
# python cve-2015-7547-poc.py &
[1] 961
# chroot /medusa_rootfs/ bin/ash
BusyBox v1.23.2 (2018-11-21 18:22:56 IST) built-in shell (ash)
# gdb cve-2015-7547_glibc_getaddrinfo
[...]
[UDP] Total Data len recv 36
[UDP] Total Data len recv 36
Connected with 127.0.0.1:41782
[TCP] Total Data len recv 76
[TCP] Request1 len recv 36
[TCP] Request2 len recv 36
Cannot access memory at address 0x4
Program received signal SIGSEGV, Segmentation fault.
0x76f1fd58 in ?? () from /lib/libc.so.6
(gdb)
References:
https://security.googleblog.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
https://github.com/fjserna/CVE-2015-7547
3) Known BusyBox Vulnerabilities
BusyBox version 1.23.2 contains multiple CVEs like:
CVE-2016-2148, CVE-2016-6301, CVE-2015-9261, CVE-2016-2147, CVE-2018-20679,
CVE-2017-16544 and CVE-2019-5747.
The BusyBox shell autocompletion vulnerability (CVE-2017-16544) was verified on
an emulated device:
A file with the name "\ectest\n\e]55;test.txt\a" was created to trigger the
vulnerability.
-------------------------------------------------------------------------------
# ls "pressing <TAB>"
test
]55;test.txt
#
-------------------------------------------------------------------------------
4) Multiple Vulnerabilities - IoT Inspector Report
Further information can be found in IoT Inspector report:
https://r.sec-consult.com/ciscoiot
The summary is below:
IoT Inspector Vulnerability #1 BusyBox CVE entries
Outdated BusyBox version is affected by 7 published CVEs.
IoT Inspector Vulnerability #2 curl CVE entries
Outdated curl version is affected by 35 published CVEs.
IoT Inspector Vulnerability #5 Hardcoded password hashes
Firmware contains multiple hardcoded credentials.
IoT Inspector Vulnerability #6 Linux Kernel CVE entries
Outdated Linux Kernel version affected by 512 published CVEs.
IoT Inspector Vulnerability #7 MiniUPnPd CVE entries
Outdated MiniUPnPd version affected by 2 published CVEs.
IoT Inspector Vulnerability #8 Dnsmasq CVE entries
Outdated MiniUPnPd version affected by 1 published CVE.
IoT Inspector Vulnerability #9 Linux Kernel Privilege Escalation “pp_key”
Outdated Linux Kernel version is affected by CVE-2015-7547.
IoT Inspector Vulnerability #10 OpenSSL CVE entries
Outdated OpenSSL version affected by 6 published CVEs.
Vulnerable / tested versions:
-----------------------------
The following firmware versions have been tested with IoT Inspector and
firmware emulation techniques:
Cisco RV340 / 1.0.02.16
Cisco RV340W / 1.0.02.16
Cisco RV345 / 1.0.02.16
Cisco RV345P / 1.0.02.16
The following firmware versions have been tested with IoT Inspector only:
Cisco RV260 / 1.0.00.15
Cisco RV260P / 1.0.00.15
Cisco RV260W / 1.0.00.15
Cisco RV160 / 1.0.00.15
Cisco RV160P / 1.0.00.15
The firmware was obtained from the vendor website:
https://software.cisco.com/download/home/286287791/type/282465789/release/1.0.02.16
https://software.cisco.com/download/home/286316464/type/282465789/release/1.0.00.15
Vendor contact timeline:
------------------------
2019-05-15: Contacting vendor through psirt@cisco.com.
2019-05-16: Vendor confirmed the receipt.
2019-05-2019-08: Periodic updates about the investigation from the vendor.
Clarification which of the reported issues will be fixed.
2019-08-20: The vendor proposed the next possible publication date for the
advisory for 2019-09-04. The vendor added the RV160 and RV260
router series to be vulnerable to the same issues too.
2019-09-04: Coordinated advisory release.
Solution:
---------
Upgrade to the newest available firmware version.
Additionally, the vendor provides the following security notice:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190904-sb-vpnrouter
Workaround:
-----------
None.
Advisory URL:
-------------
https://www.sec-consult.com/en/vulnerability-lab/advisories/index.html
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SEC Consult Vulnerability Lab
SEC Consult
Europe | Asia | North America
About SEC Consult Vulnerability Lab
The SEC Consult Vulnerability Lab is an integrated part of SEC Consult. It
ensures the continued knowledge gain of SEC Consult in the field of network
and application security to stay ahead of the attacker. The SEC Consult
Vulnerability Lab supports high-quality penetration testing and the evaluation
of new offensive and defensive technologies for our customers. Hence our
customers obtain the most current information about vulnerabilities and valid
recommendation about the risk profile of new technologies.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Interested to work with the experts of SEC Consult?
Send us your application https://www.sec-consult.com/en/career/index.html
Interested in improving your cyber security with the experts of SEC Consult?
Contact our local offices https://www.sec-consult.com/en/contact/index.html
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mail: research at sec-consult dot com
Web: https://www.sec-consult.com
Blog: http://blog.sec-consult.com
Twitter: https://twitter.com/sec_consult
EOF T. Weber / @2019
. 7) - x86_64
3. Description:
Red Hat Container Development Kit is a platform for developing
containerized applicationsaaait is a set of tools that enables developers
to quickly and easily set up an environment for developing and testing
containerized applications on the Red Hat Enterprise Linux platform. An attacker could use this flaw to crash a server
application compiled against the NSS library. Solution:
The References section of this erratum contains a link to download CDK
3.0.0-2 (you must log in to download the update)
| VAR-201706-0272 | CVE-2017-3167 | Apache httpd Vulnerabilities in authentication |
CVSS V2: 7.5 CVSS V3: 9.8 Severity: CRITICAL |
In Apache httpd 2.2.x before 2.2.33 and 2.4.x before 2.4.26, use of the ap_get_basic_auth_pw() by third-party modules outside of the authentication phase may lead to authentication requirements being bypassed. Apache httpd Contains an authentication vulnerability.Information is acquired, information is falsified, and denial of service (DoS) May be in a state. Apache HTTP Server is prone to an authentication bypass vulnerability.
An attacker can exploit this issue to bypass authentication mechanism and perform unauthorized actions. This may lead to further attacks.
The following versions are vulnerable:
Apache HTTP Server 2.2.0 to 2.2.32
Apache HTTP Server 2.4.0 to 2.4.25. Advisory ID: SYSS-2024-029
Product: C-MOR Video Surveillance
Manufacturer: za-internet GmbH
Affected Version(s): 5.2401
Tested Version(s): 5.2401
Vulnerability Type: Dependency on Vulnerable Third-Party
Component (CWE-1395)
Use of Unmaintained Third Party Components
(CWE-1104)
Risk Level: High
Solution Status: Fixed
Manufacturer Notification: 2024-04-05
Solution Date: 2024-07-31
Public Disclosure: 2024-09-04
CVE Reference: CVE-2017-9798, CVE-2017-3167, and more
Authors of Advisory: Chris Beiter, Frederik Beimgraben,
and Matthias Deeg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Overview:
The software product C-MOR is an IP video surveillance system.
The manufacturer describes the product as follows:
"With C-MOR video surveillance, it is possible to check your
surveillance over network and the Internet. You can access the live
view as well as previous recordings from any PC or mobile device.
C-MOR is managed and controlled over the C-MOR web interface.
IP settings, camera recording setup, user rights and so on are set
over the web without the installation of any software on the
client."[1]
The C-MOR system uses several outdated third-party software components
with known security vulnerabilities.
Some of the used software components have also reached their end of life
and are not supported anymore by a maintainer.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Proof of Concept (PoC):
The following excerpt of the "dpkg-query" output illustrates some outdated
third-party software components used on the C-MOR system:
$ sudo dpkg-query -l
(...)
ii apache2 2.2.16-6+squeeze10
Apache HTTP Server metapackage
ii apache2-mpm-prefork 2.2.16-6+squeeze10
Apache HTTP Server - traditional non-threaded model
ii apache2-utils 2.2.16-6+squeeze10
utility programs for webservers
ii apache2.2-bin 2.2.16-6+squeeze10
Apache HTTP Server common binary files
ii apache2.2-common 2.2.16-6+squeeze10
Apache HTTP Server common files
(...)
ii libapache2-mod-php5 5.3.3-7+squeeze14
server-side, HTML-embedded scripting language (Apache 2 module)
(...)
ii libssl0.9.8 0.9.8o-4squeeze14 SSL
shared libraries
(...)
ii linux-image-4.7.8 c-mor-v5-00
Linux kernel binary image for version 4.7.8
(...)
ii php5 5.3.3-7+squeeze14
server-side, HTML-embedded scripting language (metapackage)
rc php5-cgi 5.3.3-7+squeeze14
server-side, HTML-embedded scripting language (CGI binary)
ii php5-cli 5.3.3-7+squeeze14
command-line interpreter for the php5 scripting language
ii php5-common 5.3.3-7+squeeze14
Common files for packages built from the php5 source
ii php5-gd 5.3.3-7+squeeze14 GD
module for php5
ii php5-mysql 5.3.3-7+squeeze14
MySQL module for php5
ii php5-suhosin 0.9.32.1-1
advanced protection module for php5
(...)
ii python2.6 2.6.6-8+b1 An
interactive high-level object-oriented language (version 2.6)
ii python2.6-minimal 2.6.6-8+b1 A
minimal subset of the Python language (version 2.6)
(...)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Solution:
Install C-MOR Video Surveillance version 6.00PL1.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Disclosure Timeline:
2024-04-05: Vulnerability reported to manufacturer
2024-04-05: Manufacturer acknowledges receipt of security advisories
2024-04-08: Exchange regarding security updates and disclosure timeline
2024-05-08: Further exchange concerning security updates and disclosure
timeline; public release of all security advisories
scheduled for release of C-MOR Video Surveillance version 6
2024-05-10: Release of C-MOR software version 5.30 with security updates
for some reported security issues
2024-07-19: E-mail to manufacturer concerning release date of C-MOR
Video Surveillance version 6; response with planned
release date of 2024-08-01
2024-07-30: E-mail from manufacturer with further information
concerning security fixes
2024-07-31: Release of C-MOR software version 6.00PL1
2024-09-04: Public release of security advisory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
References:
[1] Product website for C-MOR Video Surveillance
https://www.c-mor.com/
[2] SySS Security Advisory SYSS-2024-029
https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2024-029.txt
[3] SySS Responsible Disclosure Policy
https://www.syss.de/en/responsible-disclosure-policy/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Credits:
This security vulnerability was found by Chris Beiter, and Frederik
Beimgraben.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Disclaimer:
The information provided in this security advisory is provided "as is"
and without warranty of any kind. Details of this security advisory may
be updated in order to provide as accurate information as possible. The
latest version of this security advisory is available on the SySS Web
site.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Copyright:
Creative Commons - Attribution (by) - Version 3.0
URL: http://creativecommons.org/licenses/by/3.0/deed.en
. ==========================================================================
Ubuntu Security Notice USN-3373-1
July 31, 2017
apache2 vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 12.04 ESM
Summary:
Several security issues were fixed in Apache HTTP Server. This update adds a
new ap_get_basic_auth_components() function for use by third-party
modules. (CVE-2017-3167)
Vasileios Panopoulos discovered that the Apache mod_ssl module may
crash when third-party modules call ap_hook_process_connection() during
an HTTP request to an HTTPS port. (CVE-2017-3169)
Javier JimA(c)nez discovered that the Apache HTTP Server incorrectly
handled parsing certain requests. (CVE-2017-7679)
David Dennerline and RA(c)gis Leroy discovered that the Apache HTTP Server
incorrectly handled unusual whitespace when parsing requests, contrary
to specifications. This update may
introduce compatibility issues with clients that do not strictly follow
HTTP protocol specifications. A new configuration option
"HttpProtocolOptions Unsafe" can be used to revert to the previous
unsafe behaviour in problematic environments. (CVE-2016-8743)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 12.04 ESM:
A apache2.2-binA A A A A A A A A A A A A A A A A A A 2.2.22-1ubuntu1.12
In general, a standard system update will make all the necessary
changes. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 201710-32
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
https://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Severity: Normal
Title: Apache: Multiple vulnerabilities
Date: October 29, 2017
Bugs: #622240, #624868, #631308
ID: 201710-32
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Synopsis
========
Multiple vulnerabilities have been found in Apache, the worst of which
may result in the loss of secrets.
Affected packages
=================
-------------------------------------------------------------------
Package / Vulnerable / Unaffected
-------------------------------------------------------------------
1 www-servers/apache < 2.4.27-r1 >= 2.4.27-r1
Description
===========
Multiple vulnerabilities have been discovered in Apache. Please review
the referenced CVE identifiers for details.
Impact
======
The Optionsbleed vulnerability can leak arbitrary memory from the
server process that may contain secrets.
Workaround
==========
There is no known workaround at this time.
Resolution
==========
All Apache users should upgrade to the latest version:
# emerge --sync
# emerge --ask --oneshot --verbose ">=www-servers/apache-2.4.27-r1"
References
==========
[ 1 ] CVE-2017-3167
https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-3167
[ 2 ] CVE-2017-3169
https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-3169
[ 3 ] CVE-2017-7659
https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-7659
[ 4 ] CVE-2017-7668
https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-7668
[ 5 ] CVE-2017-7679
https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-7679
[ 6 ] CVE-2017-9788
https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9788
[ 7 ] CVE-2017-9789
https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9789
[ 8 ] CVE-2017-9798
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9798
Availability
============
This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:
https://security.gentoo.org/glsa/201710-32
Concerns?
=========
Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users' machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.
License
=======
Copyright 2017 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).
http://creativecommons.org/licenses/by-sa/2.5
. (CVE-2017-7679)
* A use-after-free flaw was found in the way httpd handled invalid and
previously unregistered HTTP methods specified in the Limit directive used
in an .htaccess file. (CVE-2017-9798)
Red Hat would like to thank Hanno BAPck for reporting CVE-2017-9798. -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=====================================================================
Red Hat Security Advisory
Synopsis: Important: httpd security update
Advisory ID: RHSA-2017:2478-01
Product: Red Hat Enterprise Linux
Advisory URL: https://access.redhat.com/errata/RHSA-2017:2478
Issue date: 2017-08-15
CVE Names: CVE-2017-3167 CVE-2017-3169 CVE-2017-7679
CVE-2017-9788
=====================================================================
1. Summary:
An update for httpd is now available for Red Hat Enterprise Linux 6.
Red Hat Product Security has rated this update as having a security impact
of Important. A Common Vulnerability Scoring System (CVSS) base score,
which gives a detailed severity rating, is available for each vulnerability
from the CVE link(s) in the References section.
2. Relevant releases/architectures:
Red Hat Enterprise Linux Desktop (v. 6) - i386, x86_64
Red Hat Enterprise Linux Desktop Optional (v. 6) - i386, noarch, x86_64
Red Hat Enterprise Linux HPC Node (v. 6) - x86_64
Red Hat Enterprise Linux HPC Node Optional (v. 6) - noarch, x86_64
Red Hat Enterprise Linux Server (v. 6) - i386, noarch, ppc64, s390x, x86_64
Red Hat Enterprise Linux Workstation (v. 6) - i386, noarch, x86_64
3.
Security Fix(es):
* It was discovered that the httpd's mod_auth_digest module did not
properly initialize memory before using it when processing certain headers
related to digest authentication. A remote attacker could possibly use this
flaw to disclose potentially sensitive information or cause httpd child
process to crash by sending specially crafted requests to a server. (CVE-2017-3167)
* A NULL pointer dereference flaw was found in the httpd's mod_ssl module.
A remote attacker could use this flaw to cause an httpd child process to
crash if another module used by httpd called a certain API function during
the processing of an HTTPS request. (CVE-2017-3169)
* A buffer over-read flaw was found in the httpd's mod_mime module. A user
permitted to modify httpd's MIME configuration could use this flaw to cause
httpd child process to crash. (CVE-2017-7679)
4. Solution:
For details on how to apply this update, which includes the changes
described in this advisory, refer to:
https://access.redhat.com/articles/11258
After installing the updated packages, the httpd daemon will be restarted
automatically.
5. Bugs fixed (https://bugzilla.redhat.com/):
1463194 - CVE-2017-3167 httpd: ap_get_basic_auth_pw() authentication bypass
1463197 - CVE-2017-3169 httpd: mod_ssl NULL pointer dereference
1463207 - CVE-2017-7679 httpd: mod_mime buffer overread
1470748 - CVE-2017-9788 httpd: Uninitialized memory reflection in mod_auth_digest
6. Package List:
Red Hat Enterprise Linux Desktop (v. 6):
Source:
httpd-2.2.15-60.el6_9.5.src.rpm
i386:
httpd-2.2.15-60.el6_9.5.i686.rpm
httpd-debuginfo-2.2.15-60.el6_9.5.i686.rpm
httpd-tools-2.2.15-60.el6_9.5.i686.rpm
x86_64:
httpd-2.2.15-60.el6_9.5.x86_64.rpm
httpd-debuginfo-2.2.15-60.el6_9.5.x86_64.rpm
httpd-tools-2.2.15-60.el6_9.5.x86_64.rpm
Red Hat Enterprise Linux Desktop Optional (v. 6):
i386:
httpd-debuginfo-2.2.15-60.el6_9.5.i686.rpm
httpd-devel-2.2.15-60.el6_9.5.i686.rpm
mod_ssl-2.2.15-60.el6_9.5.i686.rpm
noarch:
httpd-manual-2.2.15-60.el6_9.5.noarch.rpm
x86_64:
httpd-debuginfo-2.2.15-60.el6_9.5.i686.rpm
httpd-debuginfo-2.2.15-60.el6_9.5.x86_64.rpm
httpd-devel-2.2.15-60.el6_9.5.i686.rpm
httpd-devel-2.2.15-60.el6_9.5.x86_64.rpm
mod_ssl-2.2.15-60.el6_9.5.x86_64.rpm
Red Hat Enterprise Linux HPC Node (v. 6):
Source:
httpd-2.2.15-60.el6_9.5.src.rpm
x86_64:
httpd-2.2.15-60.el6_9.5.x86_64.rpm
httpd-debuginfo-2.2.15-60.el6_9.5.x86_64.rpm
httpd-tools-2.2.15-60.el6_9.5.x86_64.rpm
Red Hat Enterprise Linux HPC Node Optional (v. 6):
noarch:
httpd-manual-2.2.15-60.el6_9.5.noarch.rpm
x86_64:
httpd-debuginfo-2.2.15-60.el6_9.5.i686.rpm
httpd-debuginfo-2.2.15-60.el6_9.5.x86_64.rpm
httpd-devel-2.2.15-60.el6_9.5.i686.rpm
httpd-devel-2.2.15-60.el6_9.5.x86_64.rpm
mod_ssl-2.2.15-60.el6_9.5.x86_64.rpm
Red Hat Enterprise Linux Server (v. 6):
Source:
httpd-2.2.15-60.el6_9.5.src.rpm
i386:
httpd-2.2.15-60.el6_9.5.i686.rpm
httpd-debuginfo-2.2.15-60.el6_9.5.i686.rpm
httpd-devel-2.2.15-60.el6_9.5.i686.rpm
httpd-tools-2.2.15-60.el6_9.5.i686.rpm
mod_ssl-2.2.15-60.el6_9.5.i686.rpm
noarch:
httpd-manual-2.2.15-60.el6_9.5.noarch.rpm
ppc64:
httpd-2.2.15-60.el6_9.5.ppc64.rpm
httpd-debuginfo-2.2.15-60.el6_9.5.ppc.rpm
httpd-debuginfo-2.2.15-60.el6_9.5.ppc64.rpm
httpd-devel-2.2.15-60.el6_9.5.ppc.rpm
httpd-devel-2.2.15-60.el6_9.5.ppc64.rpm
httpd-tools-2.2.15-60.el6_9.5.ppc64.rpm
mod_ssl-2.2.15-60.el6_9.5.ppc64.rpm
s390x:
httpd-2.2.15-60.el6_9.5.s390x.rpm
httpd-debuginfo-2.2.15-60.el6_9.5.s390.rpm
httpd-debuginfo-2.2.15-60.el6_9.5.s390x.rpm
httpd-devel-2.2.15-60.el6_9.5.s390.rpm
httpd-devel-2.2.15-60.el6_9.5.s390x.rpm
httpd-tools-2.2.15-60.el6_9.5.s390x.rpm
mod_ssl-2.2.15-60.el6_9.5.s390x.rpm
x86_64:
httpd-2.2.15-60.el6_9.5.x86_64.rpm
httpd-debuginfo-2.2.15-60.el6_9.5.i686.rpm
httpd-debuginfo-2.2.15-60.el6_9.5.x86_64.rpm
httpd-devel-2.2.15-60.el6_9.5.i686.rpm
httpd-devel-2.2.15-60.el6_9.5.x86_64.rpm
httpd-tools-2.2.15-60.el6_9.5.x86_64.rpm
mod_ssl-2.2.15-60.el6_9.5.x86_64.rpm
Red Hat Enterprise Linux Workstation (v. 6):
Source:
httpd-2.2.15-60.el6_9.5.src.rpm
i386:
httpd-2.2.15-60.el6_9.5.i686.rpm
httpd-debuginfo-2.2.15-60.el6_9.5.i686.rpm
httpd-devel-2.2.15-60.el6_9.5.i686.rpm
httpd-tools-2.2.15-60.el6_9.5.i686.rpm
mod_ssl-2.2.15-60.el6_9.5.i686.rpm
noarch:
httpd-manual-2.2.15-60.el6_9.5.noarch.rpm
x86_64:
httpd-2.2.15-60.el6_9.5.x86_64.rpm
httpd-debuginfo-2.2.15-60.el6_9.5.i686.rpm
httpd-debuginfo-2.2.15-60.el6_9.5.x86_64.rpm
httpd-devel-2.2.15-60.el6_9.5.i686.rpm
httpd-devel-2.2.15-60.el6_9.5.x86_64.rpm
httpd-tools-2.2.15-60.el6_9.5.x86_64.rpm
mod_ssl-2.2.15-60.el6_9.5.x86_64.rpm
These packages are GPG signed by Red Hat for security. Our key and
details on how to verify the signature are available from
https://access.redhat.com/security/team/key/
7. References:
https://access.redhat.com/security/cve/CVE-2017-3167
https://access.redhat.com/security/cve/CVE-2017-3169
https://access.redhat.com/security/cve/CVE-2017-7679
https://access.redhat.com/security/cve/CVE-2017-9788
https://access.redhat.com/security/updates/classification/#important
8. Contact:
The Red Hat security contact is <secalert@redhat.com>. More contact
details at https://access.redhat.com/security/team/contact/
Copyright 2017 Red Hat, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iD8DBQFZkzq3XlSAg2UNWIIRAjxIAJ9JoJcSMguc2VTpgJl2P5BGoM2IrACfXd/8
Jxb2g1bdehw6Jjq0qF13AEM=
=ZvYI
-----END PGP SIGNATURE-----
--
RHSA-announce mailing list
RHSA-announce@redhat.com
https://www.redhat.com/mailman/listinfo/rhsa-announce
| VAR-201706-0996 | CVE-2017-7668 | Apache httpd Input validation vulnerability |
CVSS V2: 5.0 CVSS V3: 7.5 Severity: HIGH |
The HTTP strict parsing changes added in Apache httpd 2.2.32 and 2.4.24 introduced a bug in token list parsing, which allows ap_find_token() to search past the end of its input string. By maliciously crafting a sequence of request headers, an attacker may be able to cause a segmentation fault, or to force ap_find_token() to return an incorrect value. Apache httpd Contains an input validation vulnerability.Information is obtained, information is altered, and service operation is disrupted (DoS) There is a possibility of being put into a state. Apache HTTP Server is prone to a denial-of-service vulnerability.
Attackers may leverage this issue to cause a denial-of-service condition, denying service to legitimate users.
Apache HTTP Server 2.2.32 and 2.4.25 are vulnerable. ==========================================================================
Ubuntu Security Notice USN-3373-1
July 31, 2017
apache2 vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 12.04 ESM
Summary:
Several security issues were fixed in Apache HTTP Server. This update adds a
new ap_get_basic_auth_components() function for use by third-party
modules. (CVE-2017-3167)
Vasileios Panopoulos discovered that the Apache mod_ssl module may
crash when third-party modules call ap_hook_process_connection() during
an HTTP request to an HTTPS port. (CVE-2017-3169)
Javier JimA(c)nez discovered that the Apache HTTP Server incorrectly
handled parsing certain requests. (CVE-2017-7679)
David Dennerline and RA(c)gis Leroy discovered that the Apache HTTP Server
incorrectly handled unusual whitespace when parsing requests, contrary
to specifications. This update may
introduce compatibility issues with clients that do not strictly follow
HTTP protocol specifications. A new configuration option
"HttpProtocolOptions Unsafe" can be used to revert to the previous
unsafe behaviour in problematic environments. (CVE-2016-8743)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 12.04 ESM:
A apache2.2-binA A A A A A A A A A A A A A A A A A A 2.2.22-1ubuntu1.12
In general, a standard system update will make all the necessary
changes. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 201710-32
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
https://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Severity: Normal
Title: Apache: Multiple vulnerabilities
Date: October 29, 2017
Bugs: #622240, #624868, #631308
ID: 201710-32
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Synopsis
========
Multiple vulnerabilities have been found in Apache, the worst of which
may result in the loss of secrets.
Affected packages
=================
-------------------------------------------------------------------
Package / Vulnerable / Unaffected
-------------------------------------------------------------------
1 www-servers/apache < 2.4.27-r1 >= 2.4.27-r1
Description
===========
Multiple vulnerabilities have been discovered in Apache. Please review
the referenced CVE identifiers for details.
Impact
======
The Optionsbleed vulnerability can leak arbitrary memory from the
server process that may contain secrets.
Workaround
==========
There is no known workaround at this time.
Resolution
==========
All Apache users should upgrade to the latest version:
# emerge --sync
# emerge --ask --oneshot --verbose ">=www-servers/apache-2.4.27-r1"
References
==========
[ 1 ] CVE-2017-3167
https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-3167
[ 2 ] CVE-2017-3169
https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-3169
[ 3 ] CVE-2017-7659
https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-7659
[ 4 ] CVE-2017-7668
https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-7668
[ 5 ] CVE-2017-7679
https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-7679
[ 6 ] CVE-2017-9788
https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9788
[ 7 ] CVE-2017-9789
https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9789
[ 8 ] CVE-2017-9798
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9798
Availability
============
This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:
https://security.gentoo.org/glsa/201710-32
Concerns?
=========
Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users' machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.
License
=======
Copyright 2017 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).
The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.
http://creativecommons.org/licenses/by-sa/2.5
. 7) - x86_64
3.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=====================================================================
Red Hat Security Advisory
Synopsis: Important: httpd24-httpd security update
Advisory ID: RHSA-2017:2483-01
Product: Red Hat Software Collections
Advisory URL: https://access.redhat.com/errata/RHSA-2017:2483
Issue date: 2017-08-16
CVE Names: CVE-2017-3167 CVE-2017-3169 CVE-2017-7659
CVE-2017-7668 CVE-2017-7679 CVE-2017-9788
=====================================================================
1. Summary:
An update for httpd24-httpd is now available for Red Hat Software
Collections.
Red Hat Product Security has rated this update as having a security impact
of Important. A Common Vulnerability Scoring System (CVSS) base score,
which gives a detailed severity rating, is available for each vulnerability
from the CVE link(s) in the References section.
2. Relevant releases/architectures:
Red Hat Software Collections for Red Hat Enterprise Linux Server (v. 6) - noarch, x86_64
Red Hat Software Collections for Red Hat Enterprise Linux Server (v. 7) - noarch, x86_64
Red Hat Software Collections for Red Hat Enterprise Linux Server EUS (v. 6.7) - noarch, x86_64
Red Hat Software Collections for Red Hat Enterprise Linux Server EUS (v. 7.3) - noarch, x86_64
Red Hat Software Collections for Red Hat Enterprise Linux Workstation (v. 6) - noarch, x86_64
Red Hat Software Collections for Red Hat Enterprise Linux Workstation (v. 7) - noarch, x86_64
3.
Security Fix(es):
* It was discovered that the httpd's mod_auth_digest module did not
properly initialize memory before using it when processing certain headers
related to digest authentication. A remote attacker could possibly use this
flaw to disclose potentially sensitive information or cause httpd child
process to crash by sending specially crafted requests to a server.
(CVE-2017-9788)
* It was discovered that the use of httpd's ap_get_basic_auth_pw() API
function outside of the authentication phase could lead to authentication
bypass. A remote attacker could possibly use this flaw to bypass required
authentication if the API was used incorrectly by one of the modules used
by httpd. (CVE-2017-3167)
* A NULL pointer dereference flaw was found in the httpd's mod_ssl module.
A remote attacker could use this flaw to cause an httpd child process to
crash if another module used by httpd called a certain API function during
the processing of an HTTPS request. (CVE-2017-3169)
* A NULL pointer dereference flaw was found in the mod_http2 module of
httpd. A remote attacker could use this flaw to cause httpd child process
to crash via a specially crafted HTTP/2 request. (CVE-2017-7659)
* A buffer over-read flaw was found in the httpd's ap_find_token()
function. A remote attacker could use this flaw to cause httpd child
process to crash via a specially crafted HTTP request. (CVE-2017-7668)
* A buffer over-read flaw was found in the httpd's mod_mime module. A user
permitted to modify httpd's MIME configuration could use this flaw to cause
httpd child process to crash. (CVE-2017-7679)
4. Solution:
For details on how to apply this update, which includes the changes
described in this advisory, refer to:
https://access.redhat.com/articles/11258
After installing the updated packages, the httpd daemon will be restarted
automatically.
5. Bugs fixed (https://bugzilla.redhat.com/):
1463194 - CVE-2017-3167 httpd: ap_get_basic_auth_pw() authentication bypass
1463197 - CVE-2017-3169 httpd: mod_ssl NULL pointer dereference
1463199 - CVE-2017-7659 httpd: mod_http2 NULL pointer dereference
1463205 - CVE-2017-7668 httpd: ap_find_token() buffer overread
1463207 - CVE-2017-7679 httpd: mod_mime buffer overread
1470748 - CVE-2017-9788 httpd: Uninitialized memory reflection in mod_auth_digest
6. Package List:
Red Hat Software Collections for Red Hat Enterprise Linux Server (v. 6):
Source:
httpd24-httpd-2.4.25-9.el6.1.src.rpm
noarch:
httpd24-httpd-manual-2.4.25-9.el6.1.noarch.rpm
x86_64:
httpd24-httpd-2.4.25-9.el6.1.x86_64.rpm
httpd24-httpd-debuginfo-2.4.25-9.el6.1.x86_64.rpm
httpd24-httpd-devel-2.4.25-9.el6.1.x86_64.rpm
httpd24-httpd-tools-2.4.25-9.el6.1.x86_64.rpm
httpd24-mod_ldap-2.4.25-9.el6.1.x86_64.rpm
httpd24-mod_proxy_html-2.4.25-9.el6.1.x86_64.rpm
httpd24-mod_session-2.4.25-9.el6.1.x86_64.rpm
httpd24-mod_ssl-2.4.25-9.el6.1.x86_64.rpm
Red Hat Software Collections for Red Hat Enterprise Linux Server EUS (v. 6.7):
Source:
httpd24-httpd-2.4.25-9.el6.1.src.rpm
noarch:
httpd24-httpd-manual-2.4.25-9.el6.1.noarch.rpm
x86_64:
httpd24-httpd-2.4.25-9.el6.1.x86_64.rpm
httpd24-httpd-debuginfo-2.4.25-9.el6.1.x86_64.rpm
httpd24-httpd-devel-2.4.25-9.el6.1.x86_64.rpm
httpd24-httpd-tools-2.4.25-9.el6.1.x86_64.rpm
httpd24-mod_ldap-2.4.25-9.el6.1.x86_64.rpm
httpd24-mod_proxy_html-2.4.25-9.el6.1.x86_64.rpm
httpd24-mod_session-2.4.25-9.el6.1.x86_64.rpm
httpd24-mod_ssl-2.4.25-9.el6.1.x86_64.rpm
Red Hat Software Collections for Red Hat Enterprise Linux Workstation (v. 6):
Source:
httpd24-httpd-2.4.25-9.el6.1.src.rpm
noarch:
httpd24-httpd-manual-2.4.25-9.el6.1.noarch.rpm
x86_64:
httpd24-httpd-2.4.25-9.el6.1.x86_64.rpm
httpd24-httpd-debuginfo-2.4.25-9.el6.1.x86_64.rpm
httpd24-httpd-devel-2.4.25-9.el6.1.x86_64.rpm
httpd24-httpd-tools-2.4.25-9.el6.1.x86_64.rpm
httpd24-mod_ldap-2.4.25-9.el6.1.x86_64.rpm
httpd24-mod_proxy_html-2.4.25-9.el6.1.x86_64.rpm
httpd24-mod_session-2.4.25-9.el6.1.x86_64.rpm
httpd24-mod_ssl-2.4.25-9.el6.1.x86_64.rpm
Red Hat Software Collections for Red Hat Enterprise Linux Server (v. 7):
Source:
httpd24-httpd-2.4.25-9.el7.1.src.rpm
noarch:
httpd24-httpd-manual-2.4.25-9.el7.1.noarch.rpm
x86_64:
httpd24-httpd-2.4.25-9.el7.1.x86_64.rpm
httpd24-httpd-debuginfo-2.4.25-9.el7.1.x86_64.rpm
httpd24-httpd-devel-2.4.25-9.el7.1.x86_64.rpm
httpd24-httpd-tools-2.4.25-9.el7.1.x86_64.rpm
httpd24-mod_ldap-2.4.25-9.el7.1.x86_64.rpm
httpd24-mod_proxy_html-2.4.25-9.el7.1.x86_64.rpm
httpd24-mod_session-2.4.25-9.el7.1.x86_64.rpm
httpd24-mod_ssl-2.4.25-9.el7.1.x86_64.rpm
Red Hat Software Collections for Red Hat Enterprise Linux Server EUS (v. 7.3):
Source:
httpd24-httpd-2.4.25-9.el7.1.src.rpm
noarch:
httpd24-httpd-manual-2.4.25-9.el7.1.noarch.rpm
x86_64:
httpd24-httpd-2.4.25-9.el7.1.x86_64.rpm
httpd24-httpd-debuginfo-2.4.25-9.el7.1.x86_64.rpm
httpd24-httpd-devel-2.4.25-9.el7.1.x86_64.rpm
httpd24-httpd-tools-2.4.25-9.el7.1.x86_64.rpm
httpd24-mod_ldap-2.4.25-9.el7.1.x86_64.rpm
httpd24-mod_proxy_html-2.4.25-9.el7.1.x86_64.rpm
httpd24-mod_session-2.4.25-9.el7.1.x86_64.rpm
httpd24-mod_ssl-2.4.25-9.el7.1.x86_64.rpm
Red Hat Software Collections for Red Hat Enterprise Linux Workstation (v. 7):
Source:
httpd24-httpd-2.4.25-9.el7.1.src.rpm
noarch:
httpd24-httpd-manual-2.4.25-9.el7.1.noarch.rpm
x86_64:
httpd24-httpd-2.4.25-9.el7.1.x86_64.rpm
httpd24-httpd-debuginfo-2.4.25-9.el7.1.x86_64.rpm
httpd24-httpd-devel-2.4.25-9.el7.1.x86_64.rpm
httpd24-httpd-tools-2.4.25-9.el7.1.x86_64.rpm
httpd24-mod_ldap-2.4.25-9.el7.1.x86_64.rpm
httpd24-mod_proxy_html-2.4.25-9.el7.1.x86_64.rpm
httpd24-mod_session-2.4.25-9.el7.1.x86_64.rpm
httpd24-mod_ssl-2.4.25-9.el7.1.x86_64.rpm
These packages are GPG signed by Red Hat for security. Our key and
details on how to verify the signature are available from
https://access.redhat.com/security/team/key/
7. References:
https://access.redhat.com/security/cve/CVE-2017-3167
https://access.redhat.com/security/cve/CVE-2017-3169
https://access.redhat.com/security/cve/CVE-2017-7659
https://access.redhat.com/security/cve/CVE-2017-7668
https://access.redhat.com/security/cve/CVE-2017-7679
https://access.redhat.com/security/cve/CVE-2017-9788
https://access.redhat.com/security/updates/classification/#important
8. Contact:
The Red Hat security contact is <secalert@redhat.com>. More contact
details at https://access.redhat.com/security/team/contact/
Copyright 2017 Red Hat, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iD8DBQFZlNCpXlSAg2UNWIIRArzwAJwNfAuroR6X18rUh+zmjiMy5iBkdwCeJF6e
4v4GwWYC+5xG0xxXzTEQyAg=
=UV+2
-----END PGP SIGNATURE-----
--
RHSA-announce mailing list
RHSA-announce@redhat.com
https://www.redhat.com/mailman/listinfo/rhsa-announce
. 7.2) - ppc64, ppc64le, s390x, x86_64
3. (CVE-2017-7679)
* A use-after-free flaw was found in the way httpd handled invalid and
previously unregistered HTTP methods specified in the Limit directive used
in an .htaccess file. (CVE-2017-9798)
Red Hat would like to thank Hanno BAPck for reporting CVE-2017-9798
| VAR-201706-0271 | CVE-2017-3169 | Apache httpd In NULL Pointer dereference vulnerability |
CVSS V2: 7.5 CVSS V3: 9.8 Severity: CRITICAL |
In Apache httpd 2.2.x before 2.2.33 and 2.4.x before 2.4.26, mod_ssl may dereference a NULL pointer when third-party modules call ap_hook_process_connection() during an HTTP request to an HTTPS port. Apache httpd Is NULL A vulnerability related to pointer dereference exists.Information is obtained, information is altered, and service operation is disrupted (DoS) There is a possibility of being put into a state. Apache HTTP Server is prone to a denial-of-service vulnerability.
Attackers may leverage this issue to cause a denial-of-service condition, denying service to legitimate users.
The following versions are vulnerable:
Apache HTTP Server 2.2.0 to 2.2.32
Apache HTTP Server 2.4.0 to 2.4.25. ==========================================================================
Ubuntu Security Notice USN-3373-1
July 31, 2017
apache2 vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 12.04 ESM
Summary:
Several security issues were fixed in Apache HTTP Server. This update adds a
new ap_get_basic_auth_components() function for use by third-party
modules. (CVE-2017-3169)
Javier JimA(c)nez discovered that the Apache HTTP Server incorrectly
handled parsing certain requests. (CVE-2017-7679)
David Dennerline and RA(c)gis Leroy discovered that the Apache HTTP Server
incorrectly handled unusual whitespace when parsing requests, contrary
to specifications. This update may
introduce compatibility issues with clients that do not strictly follow
HTTP protocol specifications. A new configuration option
"HttpProtocolOptions Unsafe" can be used to revert to the previous
unsafe behaviour in problematic environments. (CVE-2016-8743)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 12.04 ESM:
A apache2.2-binA A A A A A A A A A A A A A A A A A A 2.2.22-1ubuntu1.12
In general, a standard system update will make all the necessary
changes. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 201710-32
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
https://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Severity: Normal
Title: Apache: Multiple vulnerabilities
Date: October 29, 2017
Bugs: #622240, #624868, #631308
ID: 201710-32
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Synopsis
========
Multiple vulnerabilities have been found in Apache, the worst of which
may result in the loss of secrets.
Affected packages
=================
-------------------------------------------------------------------
Package / Vulnerable / Unaffected
-------------------------------------------------------------------
1 www-servers/apache < 2.4.27-r1 >= 2.4.27-r1
Description
===========
Multiple vulnerabilities have been discovered in Apache. Please review
the referenced CVE identifiers for details.
Impact
======
The Optionsbleed vulnerability can leak arbitrary memory from the
server process that may contain secrets.
Workaround
==========
There is no known workaround at this time.
Resolution
==========
All Apache users should upgrade to the latest version:
# emerge --sync
# emerge --ask --oneshot --verbose ">=www-servers/apache-2.4.27-r1"
References
==========
[ 1 ] CVE-2017-3167
https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-3167
[ 2 ] CVE-2017-3169
https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-3169
[ 3 ] CVE-2017-7659
https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-7659
[ 4 ] CVE-2017-7668
https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-7668
[ 5 ] CVE-2017-7679
https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-7679
[ 6 ] CVE-2017-9788
https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9788
[ 7 ] CVE-2017-9789
https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9789
[ 8 ] CVE-2017-9798
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9798
Availability
============
This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:
https://security.gentoo.org/glsa/201710-32
Concerns?
=========
Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users' machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.
License
=======
Copyright 2017 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).
The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.
http://creativecommons.org/licenses/by-sa/2.5
. This software, such as Apache HTTP Server, is
common to multiple JBoss middleware products, and is packaged under Red Hat
JBoss Core Services to allow for faster distribution of updates, and for a
more consistent update experience.
This release of Red Hat JBoss Core Services Apache HTTP Server 2.4.23
Service Pack 3 serves as an update to Red Hat JBoss Core Services Apache
HTTP Server 2.4.23 Service Pack 2, and includes bug fixes, which are
documented in the Release Notes document linked to in the References.
Security Fix(es):
* An out-of-bounds array dereference was found in apr_time_exp_get(). An
attacker could abuse an unvalidated usage of this function to cause a
denial of service or potentially lead to data leak. JIRA issues fixed (https://issues.jboss.org/):
JBCS-403 - Errata for httpd 2.4.23.SP3 RHEL6
7. Solution:
The References section of this erratum contains a download link (you must
log in to download the update). Before applying the update, back up your
existing Red Hat JBoss Web Server installation (including all applications
and configuration files). -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=====================================================================
Red Hat Security Advisory
Synopsis: Important: httpd security update
Advisory ID: RHSA-2017:3194-01
Product: Red Hat Enterprise Linux
Advisory URL: https://access.redhat.com/errata/RHSA-2017:3194
Issue date: 2017-11-13
CVE Names: CVE-2017-3167 CVE-2017-3169 CVE-2017-7668
CVE-2017-7679 CVE-2017-9788 CVE-2017-9798
=====================================================================
1. Summary:
An update for httpd is now available for Red Hat Enterprise Linux 7.3
Extended Update Support.
Red Hat Product Security has rated this update as having a security impact
of Important. A Common Vulnerability Scoring System (CVSS) base score,
which gives a detailed severity rating, is available for each vulnerability
from the CVE link(s) in the References section.
2. Relevant releases/architectures:
Red Hat Enterprise Linux ComputeNode Optional EUS (v. 7.3) - noarch, x86_64
Red Hat Enterprise Linux Server EUS (v. 7.3) - noarch, ppc64, ppc64le, s390x, x86_64
Red Hat Enterprise Linux Server Optional EUS (v. 7.3) - ppc64, ppc64le, s390x, x86_64
3.
Security Fix(es):
* It was discovered that the httpd's mod_auth_digest module did not
properly initialize memory before using it when processing certain headers
related to digest authentication. A remote attacker could possibly use this
flaw to disclose potentially sensitive information or cause httpd child
process to crash by sending specially crafted requests to a server.
(CVE-2017-9788)
* It was discovered that the use of httpd's ap_get_basic_auth_pw() API
function outside of the authentication phase could lead to authentication
bypass. A remote attacker could possibly use this flaw to bypass required
authentication if the API was used incorrectly by one of the modules used
by httpd. (CVE-2017-3167)
* A NULL pointer dereference flaw was found in the httpd's mod_ssl module.
A remote attacker could use this flaw to cause an httpd child process to
crash if another module used by httpd called a certain API function during
the processing of an HTTPS request. (CVE-2017-3169)
* A buffer over-read flaw was found in the httpd's ap_find_token()
function. A remote attacker could use this flaw to cause httpd child
process to crash via a specially crafted HTTP request. (CVE-2017-7668)
* A buffer over-read flaw was found in the httpd's mod_mime module. A user
permitted to modify httpd's MIME configuration could use this flaw to cause
httpd child process to crash. (CVE-2017-7679)
* A use-after-free flaw was found in the way httpd handled invalid and
previously unregistered HTTP methods specified in the Limit directive used
in an .htaccess file. A remote attacker could possibly use this flaw to
disclose portions of the server memory, or cause httpd child process to
crash. (CVE-2017-9798)
Red Hat would like to thank Hanno BAPck for reporting CVE-2017-9798.
4. Solution:
For details on how to apply this update, which includes the changes
described in this advisory, refer to:
https://access.redhat.com/articles/11258
After installing the updated packages, the httpd daemon will be restarted
automatically.
5. Bugs fixed (https://bugzilla.redhat.com/):
1463194 - CVE-2017-3167 httpd: ap_get_basic_auth_pw() authentication bypass
1463197 - CVE-2017-3169 httpd: mod_ssl NULL pointer dereference
1463205 - CVE-2017-7668 httpd: ap_find_token() buffer overread
1463207 - CVE-2017-7679 httpd: mod_mime buffer overread
1470748 - CVE-2017-9788 httpd: Uninitialized memory reflection in mod_auth_digest
1490344 - CVE-2017-9798 httpd: Use-after-free by limiting unregistered HTTP method (Optionsbleed)
6. Package List:
Red Hat Enterprise Linux ComputeNode Optional EUS (v. 7.3):
Source:
httpd-2.4.6-45.el7_3.5.src.rpm
noarch:
httpd-manual-2.4.6-45.el7_3.5.noarch.rpm
x86_64:
httpd-2.4.6-45.el7_3.5.x86_64.rpm
httpd-debuginfo-2.4.6-45.el7_3.5.x86_64.rpm
httpd-devel-2.4.6-45.el7_3.5.x86_64.rpm
httpd-tools-2.4.6-45.el7_3.5.x86_64.rpm
mod_ldap-2.4.6-45.el7_3.5.x86_64.rpm
mod_proxy_html-2.4.6-45.el7_3.5.x86_64.rpm
mod_session-2.4.6-45.el7_3.5.x86_64.rpm
mod_ssl-2.4.6-45.el7_3.5.x86_64.rpm
Red Hat Enterprise Linux Server EUS (v. 7.3):
Source:
httpd-2.4.6-45.el7_3.5.src.rpm
noarch:
httpd-manual-2.4.6-45.el7_3.5.noarch.rpm
ppc64:
httpd-2.4.6-45.el7_3.5.ppc64.rpm
httpd-debuginfo-2.4.6-45.el7_3.5.ppc64.rpm
httpd-devel-2.4.6-45.el7_3.5.ppc64.rpm
httpd-tools-2.4.6-45.el7_3.5.ppc64.rpm
mod_ssl-2.4.6-45.el7_3.5.ppc64.rpm
ppc64le:
httpd-2.4.6-45.el7_3.5.ppc64le.rpm
httpd-debuginfo-2.4.6-45.el7_3.5.ppc64le.rpm
httpd-devel-2.4.6-45.el7_3.5.ppc64le.rpm
httpd-tools-2.4.6-45.el7_3.5.ppc64le.rpm
mod_ssl-2.4.6-45.el7_3.5.ppc64le.rpm
s390x:
httpd-2.4.6-45.el7_3.5.s390x.rpm
httpd-debuginfo-2.4.6-45.el7_3.5.s390x.rpm
httpd-devel-2.4.6-45.el7_3.5.s390x.rpm
httpd-tools-2.4.6-45.el7_3.5.s390x.rpm
mod_ssl-2.4.6-45.el7_3.5.s390x.rpm
x86_64:
httpd-2.4.6-45.el7_3.5.x86_64.rpm
httpd-debuginfo-2.4.6-45.el7_3.5.x86_64.rpm
httpd-devel-2.4.6-45.el7_3.5.x86_64.rpm
httpd-tools-2.4.6-45.el7_3.5.x86_64.rpm
mod_ssl-2.4.6-45.el7_3.5.x86_64.rpm
Red Hat Enterprise Linux Server Optional EUS (v. 7.3):
ppc64:
httpd-debuginfo-2.4.6-45.el7_3.5.ppc64.rpm
mod_ldap-2.4.6-45.el7_3.5.ppc64.rpm
mod_proxy_html-2.4.6-45.el7_3.5.ppc64.rpm
mod_session-2.4.6-45.el7_3.5.ppc64.rpm
ppc64le:
httpd-debuginfo-2.4.6-45.el7_3.5.ppc64le.rpm
mod_ldap-2.4.6-45.el7_3.5.ppc64le.rpm
mod_proxy_html-2.4.6-45.el7_3.5.ppc64le.rpm
mod_session-2.4.6-45.el7_3.5.ppc64le.rpm
s390x:
httpd-debuginfo-2.4.6-45.el7_3.5.s390x.rpm
mod_ldap-2.4.6-45.el7_3.5.s390x.rpm
mod_proxy_html-2.4.6-45.el7_3.5.s390x.rpm
mod_session-2.4.6-45.el7_3.5.s390x.rpm
x86_64:
httpd-debuginfo-2.4.6-45.el7_3.5.x86_64.rpm
mod_ldap-2.4.6-45.el7_3.5.x86_64.rpm
mod_proxy_html-2.4.6-45.el7_3.5.x86_64.rpm
mod_session-2.4.6-45.el7_3.5.x86_64.rpm
These packages are GPG signed by Red Hat for security. Our key and
details on how to verify the signature are available from
https://access.redhat.com/security/team/key/
7. References:
https://access.redhat.com/security/cve/CVE-2017-3167
https://access.redhat.com/security/cve/CVE-2017-3169
https://access.redhat.com/security/cve/CVE-2017-7668
https://access.redhat.com/security/cve/CVE-2017-7679
https://access.redhat.com/security/cve/CVE-2017-9788
https://access.redhat.com/security/cve/CVE-2017-9798
https://access.redhat.com/security/updates/classification/#important
8. Contact:
The Red Hat security contact is <secalert@redhat.com>. More contact
details at https://access.redhat.com/security/team/contact/
Copyright 2017 Red Hat, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iD8DBQFaCdj8XlSAg2UNWIIRAmF6AJ9ommuCBXady2Uloicor+n2/b5e+QCePhWu
bCdZPicTFE/tqoTmfRyUw2w=
=0uWn
-----END PGP SIGNATURE-----
--
RHSA-announce mailing list
RHSA-announce@redhat.com
https://www.redhat.com/mailman/listinfo/rhsa-announce
| VAR-201706-0356 | CVE-2017-3745 | Lenovo XClarity Administrator Authentication vulnerability |
CVSS V2: 2.1 CVSS V3: 7.8 Severity: HIGH |
In Lenovo XClarity Administrator (LXCA) before 1.3.0, if service data is downloaded from LXCA, a non-administrative user may have access to password information for users that have previously authenticated to the LXCA's internal LDAP server, including administrative accounts and service accounts with administrative privileges. This is an issue only for users who have used local authentication with LXCA and not remote authentication against external LDAP or ADFS servers. Lenovo XClarity Administrator (LXCA) Contains an authentication vulnerability.Information is obtained, information is altered, and service operation is disrupted (DoS) There is a possibility of being put into a state. Lenovo XClarity Administrator is prone to an information-disclosure vulnerability.
Attackers can exploit this issue to obtain sensitive information that may aid in further attacks. Lenovo XClarity Administrator (LXCA) is a set of centralized resource management solutions of China Lenovo (Lenovo). The solution supports simplified infrastructure management, faster server response, and improved Lenovo server system performance. A security vulnerability exists in versions prior to LXCA 1.3.0
| VAR-201708-1406 | CVE-2017-9659 | Fuji Electric Monitouch V-SFT Project File Parsing Stack-based Buffer Overflow Remote Code Execution Vulnerability |
CVSS V2: 6.8 CVSS V3: 8.8 Severity: MEDIUM |
A Stack-Based Buffer Overflow issue was discovered in Fuji Electric Monitouch V-SFT versions prior to Version 5.4.43.0. The stack-based buffer overflow vulnerability has been identified, which may cause a crash or allow remote code execution. Fuji Electric Monitouch V-SFT Contains a buffer error vulnerability.Information is obtained, information is altered, and service operation is disrupted (DoS) There is a possibility of being put into a state. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.The specific flaw exists within parsing of a V8 project file. The issue lies in the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer. An attacker can leverage this vulnerability to execute arbitrary code under the context of the process. Fuji Electric Monitouch V-SFT is an HMI software. Failed exploit attempts will result in denial-of-service conditions
| VAR-201708-1409 | CVE-2017-9662 | Fuji Electric Monitouch V-SFT Insecure Configuration Privilege Escalation Vulnerability |
CVSS V2: 4.6 CVSS V3: 5.3 Severity: MEDIUM |
An Improper Privilege Management issue was discovered in Fuji Electric Monitouch V-SFT versions prior to Version 5.4.43.0. Monitouch V-SFT is installed in a directory with weak access controls by default, which could allow an authenticated attacker with local access to escalate privileges. Fuji Electric Monitouch V-SFT Contains vulnerabilities related to authorization, permissions, and access control.Information is obtained, information is altered, and service operation is disrupted (DoS) There is a possibility of being put into a state. This vulnerability allows local attackers to escalate their privileges on vulnerable installations of Fuji Electric Monitouch V-SFT. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability.The specific flaw exists within the configuration of Monitouch V-SFT. An attacker can leverage this vulnerability to execute code in the context of any user of the software. Fuji Electric Monitouch V-SFT is an HMI software
| VAR-201708-1405 | CVE-2017-9655 | OSIsoft PI Integrator Cross-Site Scripting Vulnerability |
CVSS V2: 3.5 CVSS V3: 5.4 Severity: MEDIUM |
A Cross-Site Scripting issue was discovered in OSIsoft PI Integrator for Business Analytics before 2016 R2, PI Integrator for Microsoft Azure before 2016 R2 SP1, and PI Integrator for SAP HANA before 2017. An attacker may be able to upload a malicious script that attempts to redirect users to a malicious web site. OSIsoft PI Integrator Contains a cross-site scripting vulnerability.Information may be obtained and information may be altered. OSIsoft PI Integrator is a tool for OSIsoft to provide visual data for external systems.
An attacker may leverage these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site, steal cookie-based authentication credentials, or gain elevated privileges and perform unauthorized actions. This may aid in further attacks
| VAR-201708-1404 | CVE-2017-9653 | OSIsoft PI Integrator Unauthorized Access Vulnerability |
CVSS V2: 7.5 CVSS V3: 9.8 Severity: CRITICAL |
An Improper Authorization issue was discovered in OSIsoft PI Integrator for Business Analytics before 2016 R2, PI Integrator for Microsoft Azure before 2016 R2 SP1, and PI Integrator for SAP HANA before 2017. An attacker is able to gain privileged access to the system while unauthorized. OSIsoft PI Integrator is a tool for OSIsoft to provide visual data for external systems. An unauthorized access vulnerability exists in OSIsoft PI Integrator.
An attacker may leverage these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site, steal cookie-based authentication credentials, or gain elevated privileges and perform unauthorized actions. This may aid in further attacks
| VAR-201708-1408 | CVE-2017-9661 | SIMPlight SCADA Software DLL Load Local Code Execution Vulnerability |
CVSS V2: 5.1 CVSS V3: 7.0 Severity: HIGH |
An Uncontrolled Search Path Element issue was discovered in SIMPlight SCADA Software version 4.3.0.27 and prior. The uncontrolled search path element vulnerability has been identified, which may allow an attacker to place a malicious DLL file within the search path resulting in execution of arbitrary code. SIMPlight SCADA The software contains a vulnerability related to uncontrolled search path elements.Information is obtained, information is altered, and service operation is disrupted (DoS) There is a possibility of being put into a state. SIMPlight SCADA is a building management system and automation equipment software. SIMPlight SCADA Software is prone to a local arbitrary code-execution vulnerability because it fails to sanitize user-supplied input.
A local attacker can exploit this issue to execute arbitrary code in the context of the user running the affected application.
SIMPlight SCADA Software 4.3.0.27 and prior versions are vulnerable
| VAR-201801-0997 | CVE-2017-2743 | plural HP Cross-site scripting vulnerability in printer product firmware |
CVSS V2: 4.3 CVSS V3: 6.1 Severity: MEDIUM |
HP has identified a potential security vulnerability with HP Enterprise LaserJet Printers and MFPs, HP OfficeJet Enterprise Color Printers and MFP, HP PageWide Color Printers and MPS before 2308214_000901, 2308214_000900, and other firmware versions. The vulnerability could be exploited to perform a cross site scripting (XSS) attack. plural HP Printer product firmware contains a cross-site scripting vulnerability.Information may be obtained and information may be altered. HPColorLaserJetCM4540MFPCC419A and so on are all HP (HP) printer equipment. A cross-site scripting vulnerability exists in several HP products. A remote attacker can exploit this vulnerability to inject arbitrary web scripts or HTML. This may allow the attacker to steal cookie-based authentication credentials and launch other attacks
| VAR-201708-1400 | CVE-2017-9646 | Solar Controls Heating Control Downloader DLL Load Local Code Execution Vulnerability |
CVSS V2: 9.3 CVSS V3: 7.8 Severity: HIGH |
An Uncontrolled Search Path Element issue was discovered in Solar Controls Heating Control Downloader (HCDownloader) Version 1.0.1.15 and prior. An uncontrolled search path element has been identified, which could allow an attacker to execute arbitrary code on a target system using a malicious DLL file. A security vulnerability exists in Solar Controls HCDownloader 1.0.1.15 and earlier
| VAR-201708-1402 | CVE-2017-9648 | Solar Controls WATTConfig M Software DLL Load Local Code Execution Vulnerability |
CVSS V2: 9.3 CVSS V3: 7.8 Severity: HIGH |
An Uncontrolled Search Path Element issue was discovered in Solar Controls WATTConfig M Software Version 2.5.10.1 and prior. An uncontrolled search path element has been identified, which could allow an attacker to execute arbitrary code on a target system using a malicious DLL file
| VAR-201708-1401 | CVE-2017-9647 | Continental TCU Stack Buffer Overflow Vulnerability |
CVSS V2: 7.2 CVSS V3: 6.6 Severity: MEDIUM |
A Stack-Based Buffer Overflow issue was discovered in the Continental AG Infineon S-Gold 2 (PMB 8876) chipset on BMW several models produced between 2009-2010, Ford a limited number of P-HEV vehicles, Infiniti 2013 JX35, Infiniti 2014-2016 QX60, Infiniti 2014-2016 QX60 Hybrid, Infiniti 2014-2015 QX50, Infiniti 2014-2015 QX50 Hybrid, Infiniti 2013 M37/M56, Infiniti 2014-2016 Q70, Infiniti 2014-2016 Q70L, Infiniti 2015-2016 Q70 Hybrid, Infiniti 2013 QX56, Infiniti 2014-2016 QX 80, and Nissan 2011-2015 Leaf. An attacker with a physical connection to the TCU may exploit a buffer overflow condition that exists in the processing of AT commands. This may allow arbitrary code execution on the baseband radio processor of the TCU. The TCU is a 2G modem commonly used in modern cars produced by Continental AG to transmit data between cars and remote management tools such as web panels and mobile applications. Continental TCU has a stack buffer overflow vulnerability that affects TCUs using S-Gold 2 (PMB 8876) cellular baseband chips. Continental AG Infineon S-Gold 2 (PMB 8876) is prone to a remote code-execution vulnerability and a stack-based buffer-overflow vulnerability; fixes are available. Failed exploit attempts will likely result in denial-of-service conditions
| VAR-201805-0355 | CVE-2017-9664 | ABB SREA-01 and SREA-50 Path traversal vulnerability |
CVSS V2: 5.0 CVSS V3: 9.8 Severity: CRITICAL |
In ABB SREA-01 revisions A, B, C: application versions up to 3.31.5, and SREA-50 revision A: application versions up to 3.32.8, an attacker may access internal files of ABB SREA-01 and SREA-50 legacy remote monitoring tools without any authorization over the network using a HTTP request which refers to files using ../../ relative paths. Once the internal password file is retrieved, the password hash can be identified using a brute force attack. There is also an exploit allowing running of commands after authorization. ABB SREA-01 and SREA-50 Contains a path traversal vulnerability.Information is obtained, information is altered, and service operation is disrupted (DoS) There is a possibility of being put into a state. Both ABBSREA-01 and SREA-50 are inverter adapters from Asea Brown Boveri (ABB), Switzerland. A directory traversal vulnerability exists in ABBSREA-01 and SREA-50. An attacker who successfully exploited the vulnerability could access files on the file system of the affected product, view the data, change the configuration, retrieve the password hash code, and send commands to connect to Authorized device. ABB SREA-01 and SREA-50 are prone to a directory-traversal vulnerability.
Remote attackers may use a specially crafted request with directory-traversal sequences ('../') to retrieve sensitive information. This may aid in further attacks.
The following products are affected:
SREA-01 revisions A, B, C version 3.31.5 and prior.
SREA-50 revision A version 3.32.8 and prior