CVE-2018-1002105
published 2018-12-05CVE-2018-1002105: In all Kubernetes versions prior to v1.10.11, v1.11.5, and v1.12.3, incorrect handling of error responses to proxied upgrade requests in the kube-apiserver…
PriorityP184critical9.8CVSS 3.0
AVNACLPRNUINSUCHIHAH
EXPLOIT
EPSS
86.98%
99.7th percentile
In all Kubernetes versions prior to v1.10.11, v1.11.5, and v1.12.3, incorrect handling of error responses to proxied upgrade requests in the kube-apiserver allowed specially crafted requests to establish a connection through the Kubernetes API server to backend servers, then send arbitrary requests over the same connection directly to the backend, authenticated with the Kubernetes API server's TLS credentials used to establish the backend connection.
Affected
34 ranges· showing 25
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | kubernetes | < kubernetes 1.17.4-1 (bookworm) | kubernetes 1.17.4-1 (bookworm) |
| github.com | kubernetes_kubernetes | >= 0 < 1.10.11 | 1.10.11 |
| github.com | kubernetes_kubernetes | >= 1.11.0 < 1.11.5 | 1.11.5 |
| github.com | kubernetes_kubernetes | >= 1.12.0 < 1.12.3 | 1.12.3 |
| kubernetes | kubernetes | — | — |
| kubernetes | kubernetes | — | — |
| kubernetes | kubernetes | — | — |
| kubernetes | kubernetes | — | — |
| kubernetes | kubernetes | — | — |
| kubernetes | kubernetes | — | — |
| kubernetes | kubernetes | — | — |
| kubernetes | kubernetes | — | — |
| kubernetes | kubernetes | — | — |
| kubernetes | kubernetes | — | — |
| kubernetes | kubernetes | — | — |
| kubernetes | kubernetes | >= 0 < 1.17.4-1 | 1.17.4-1 |
| kubernetes | kubernetes | >= 0 < 1.17.4-1 | 1.17.4-1 |
| kubernetes | kubernetes | >= 0 < 1.17.4-1 | 1.17.4-1 |
| kubernetes | kubernetes | >= 0 < 1.17.4-1 | 1.17.4-1 |
| kubernetes | kubernetes | 1.0.0 – 1.9.11 | — |
| kubernetes | kubernetes | 1.10.0 – 1.10.10 | — |
| kubernetes | kubernetes | 1.11.0 – 1.11.4 | — |
| kubernetes | kubernetes | 1.12.0 – 1.12.2 | — |
| kubernetes | kubernetes | >= unspecified < v1.10.11 | v1.10.11 |
| kubernetes | kubernetes | >= unspecified < v1.11.5 | v1.11.5 |
Detection & IOCsextracted from sources · hover to see the quote
- →Detect HTTP Upgrade requests to the kube-apiserver that receive a non-101 response code but maintain an open proxy connection — this is the core exploit primitive (missing 101 Switching Protocols check in upgradeaware.go). ↗
- →Alert on use of X-Remote-User / X-Remote-Group impersonation headers arriving at the kube-apiserver, especially from pods that do not normally communicate with the API server. ↗
- →Monitor access to /root/.docker/config.json and /home/*/.docker/config.json from container processes — used by attackers to harvest Docker Hub credentials post-exploitation. ↗
- ·The vulnerability also enables privilege escalation via pod exec/attach/portforward requests routed through the kubelet API, not only through aggregated API servers. ↗
- ·Service Catalog aggregated API server is installed by default on OpenShift from version 3.7 and on cloud-provider-deployed Kubernetes clusters, expanding the attack surface. ↗
- ·Exploit traffic over the hijacked proxy connection is authenticated with the kube-apiserver's own TLS credentials, making it appear as legitimate server-to-server traffic in backend logs. ↗
CVSS provenance
nvdv3.09.8CRITICALCVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
nvdv2.07.5HIGHAV:N/AC:L/Au:N/C:P/I:P/A:P
osv9.8CRITICAL
vendor_debian9.8CRITICAL
vendor_redhat9.8CRITICAL
CVEs like this are exactly what “Exploited This Week” covers.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kubernetes: authentication/authorization bypass in the handling of non-101 responses
vendor_redhat·2018-12-03·CVSS 9.8
CVE-2018-1002105 [CRITICAL] CWE-305 kubernetes: authentication/authorization bypass in the handling of non-101 responses
kubernetes: authentication/authorization bypass in the handling of non-101 responses
In all Kubernetes versions prior to v1.10.11, v1.11.5, and v1.12.3, incorrect handling of error responses to proxied upgrade requests in the kube-apiserver allowed specially crafted requests to establish a connection through the Kubernetes API server to backend servers, then send arbitrary requests over the same connection directly to the backend, authenticated with the Kubernetes API server's TLS credentials used to establish the backend connection.
A privilege escalation vulnerability exists in OpenShift Container Platform which allows for compromise of pods running co-located on a compute node. This access could include access to all secrets, pods, environment variables, running pod/container processe
Debian
CVE-2018-1002105: kubernetes - In all Kubernetes versions prior to v1.10.11, v1.11.5, and v1.12.3, incorrect ha...
vendor_debian·2018·CVSS 9.8
CVE-2018-1002105 [CRITICAL] CVE-2018-1002105: kubernetes - In all Kubernetes versions prior to v1.10.11, v1.11.5, and v1.12.3, incorrect ha...
In all Kubernetes versions prior to v1.10.11, v1.11.5, and v1.12.3, incorrect handling of error responses to proxied upgrade requests in the kube-apiserver allowed specially crafted requests to establish a connection through the Kubernetes API server to backend servers, then send arbitrary requests over the same connection directly to the backend, authenticated with the Kubernetes API server's TLS credentials used to establish the backend connection.
Scope: local
bookworm: resolved (fixed in 1.17.4-1)
bullseye: resolved (fixed in 1.17.4-1)
forky: resolved (fixed in 1.17.4-1)
sid: resolved (fixed in 1.17.4-1)
trixie: resolved (fixed in 1.17.4-1)
OSV
Privilege Escalation in Kubernetes in github.com/kubernetes/kubernetes
osv·2024-08-21
CVE-2018-1002105 Privilege Escalation in Kubernetes in github.com/kubernetes/kubernetes
Privilege Escalation in Kubernetes in github.com/kubernetes/kubernetes
Privilege Escalation in Kubernetes in github.com/kubernetes/kubernetes
OSV
Privilege Escalation in Kubernetes
osv·2022-02-15
CVE-2018-1002105 [CRITICAL] Privilege Escalation in Kubernetes
Privilege Escalation in Kubernetes
In all Kubernetes versions prior to v1.10.11, v1.11.5, and v1.12.3, incorrect handling of error responses to proxied upgrade requests in the kube-apiserver allowed specially crafted requests to establish a connection through the Kubernetes API server to backend servers, then send arbitrary requests over the same connection directly to the backend, authenticated with the Kubernetes API server's TLS credentials used to establish the backend connection.
GHSA
Privilege Escalation in Kubernetes
ghsa·2022-02-15
CVE-2018-1002105 [CRITICAL] CWE-269 Privilege Escalation in Kubernetes
Privilege Escalation in Kubernetes
In all Kubernetes versions prior to v1.10.11, v1.11.5, and v1.12.3, incorrect handling of error responses to proxied upgrade requests in the kube-apiserver allowed specially crafted requests to establish a connection through the Kubernetes API server to backend servers, then send arbitrary requests over the same connection directly to the backend, authenticated with the Kubernetes API server's TLS credentials used to establish the backend connection.
OSV
CVE-2018-1002105: In all Kubernetes versions prior to v1
osv·2018-12-05·CVSS 9.8
CVE-2018-1002105 [CRITICAL] CVE-2018-1002105: In all Kubernetes versions prior to v1
In all Kubernetes versions prior to v1.10.11, v1.11.5, and v1.12.3, incorrect handling of error responses to proxied upgrade requests in the kube-apiserver allowed specially crafted requests to establish a connection through the Kubernetes API server to backend servers, then send arbitrary requests over the same connection directly to the backend, authenticated with the Kubernetes API server's TLS credentials used to establish the backend connection.
No detection rules found.
Exploit-DB
Kubernetes - (Authenticated) Arbitrary Requests
exploitdb·2018-12-10
CVE-2018-1002105 Kubernetes - (Authenticated) Arbitrary Requests
Kubernetes - (Authenticated) Arbitrary Requests
---
#!/usr/bin/env python3
import argparse
from ssl import wrap_socket
from socket import create_connection
from secrets import base64, token_bytes
def request_stage_1(namespace, pod, method, target, token):
stage_1 = ""
with open('stage_1', 'r') as stage_1_fd:
stage_1 = stage_1_fd.read()
return stage_1.format(namespace, pod, method, target,
token).encode('utf-8')
def request_stage_2(target, namespace, pod, container, command):
stage_2 = ""
command = f"command={'&command='.join(command.split(' '))}"
with open('stage_2', 'r') as stage_2_fd:
stage_2 = stage_2_fd.read()
key = base64.b64encode(token_bytes(20)).decode('utf-8')
return stage_2.format(namespace, pod, container, command,
target, key).encode('utf-8')
def run_exploit(tar
Exploit-DB
Kubernetes - (Unauthenticated) Arbitrary Requests
exploitdb·2018-12-10
CVE-2018-1002105 Kubernetes - (Unauthenticated) Arbitrary Requests
Kubernetes - (Unauthenticated) Arbitrary Requests
---
#!/usr/bin/env python3
import argparse
from ssl import wrap_socket
from json import loads, dumps
from socket import create_connection
def request_stage_1(base, version, target):
stage_1 = ""
with open('ustage_1', 'r') as stage_1_fd:
stage_1 = stage_1_fd.read()
return stage_1.format(base, version, target
).encode('utf-8')
def request_stage_2(base, version, target_api, target):
stage_2 = ""
with open('ustage_2', 'r') as stage_2_fd:
stage_2 = stage_2_fd.read()
return stage_2.format(base, version, target_api, target,
).encode('utf-8')
def read_data(ssock):
data = []
data_incoming = True
while data_incoming:
data_in = ssock.recv(4096)
if not data_in:
data_incoming = False
elif data_in.find(b'\n\r\n0\r\n\r\n') != -1:
data_in
arXiv
Unveiling the Bandwidth Nightmare: CDN Compression Format Conversion Attacks
arxiv_fulltext·2024-09-01
Unveiling the Bandwidth Nightmare: CDN Compression Format Conversion Attacks
Unveiling the Bandwidth Nightmare: CDN Compression Format Conversion Attacks
1st Ziyu Lin
Fuzhou University
Fuzhou, China
[email protected]
2nd Zhiwei Lin
Sichuan University
Chengdu, China
[email protected]
3rd Ximeng Liu^
Fuzhou University
Fuzhou, China
[email protected]
4th Zuobing Ying
City University of Macau
Macau, China
[email protected]
5th Cheng Chen
Fuzhou University
Fuzhou, China
[email protected]
## Abstract
Content Delivery Networks (CDNs) are designed to enhance network performance and protect against web attack traffic for their hosting websites.
And the HTTP compression request mechanism primarily aims to reduce unnecessary network transfers.
However, we find that the specification failed to consider the security risks introduced when CDNs meet compres
arXiv
Microservice Vulnerability Analysis: A Literature Review with Empirical Insights
arxiv_fulltext·2024-07-31
Microservice Vulnerability Analysis: A Literature Review with Empirical Insights
Microservice Vulnerability Analysis: A Literature Review with Empirical Insights
Raveen Kanishka Jayalath*
University of Adelaide, Australia
[email protected]
Hussain Ahmad* *Authors contributed equally to this work. Corresponding author.
University of Adelaide, Australia
[email protected]
Diksha Goel
CSIRO's Data61, Australia
[email protected]
3cmMuhammad Shuja Syed
3cmSLB, USA
[email protected]
Faheem Ullah
University of Adelaide, Australia
[email protected]
plain
## Abstract
Microservice architectures are revolutionizing both small businesses and large corporations, igniting a new era of innovation with their exceptional advantages in maintainability, reusability, and scalability. However, these benefits come w
Trailofbits
Finding unhandled errors using CodeQL
blogs_trailofbits·2022-01-11·CVSS 9.8
CVE-2018-1002105 [CRITICAL] Finding unhandled errors using CodeQL
One of your developers finds a bug in your codebase—an unhandled error code—and wonders whether there could be more. He combs through the code and finds unhandled error after unhandled error. One lone developer playing whack-a-mole. It’s not enough. And your undisciplined team of first-year Stanford grads never learned software engineering. You’re doomed.
Good developers know that unhandled errors can be exploitable and cause serious problems in a codebase. Take CVE-2018-1002105 , a critical vulnerability in Kubernetes allowing attackers to leverage incorrectly handled errors to establish a back-end connection through the Kubernetes API.
At Trail of Bits, we find issues like this all the time, and we know that there are better ways to find the rest than manually searching for them one by
Trailofbits
Finding unhandled errors using CodeQL
blogs_trailofbits·2022-01-11·CVSS 9.8
CVE-2018-1002105 [CRITICAL] Finding unhandled errors using CodeQL
One of your developers finds a bug in your codebase—an unhandled error code—and wonders whether there could be more. He combs through the code and finds unhandled error after unhandled error. One lone developer playing whack-a-mole. It’s not enough. And your undisciplined team of first-year Stanford grads never learned software engineering. You’re doomed.
Good developers know that unhandled errors can be exploitable and cause serious problems in a codebase. Take CVE-2018-1002105, a critical vulnerability in Kubernetes allowing attackers to leverage incorrectly handled errors to establish a back-end connection through the Kubernetes API.
At Trail of Bits, we find issues like this all the time, and we know that there are better ways to find the rest than manually searching for them one by
Trendmicro
Analyzing How TeamTNT Used Compromised Docker Hub Accounts
blogs_trendmicro·2021-12-01
Analyzing How TeamTNT Used Compromised Docker Hub Accounts
Cloud
## Analyzing How TeamTNT Used Compromised Docker Hub Accounts
Following our previous disclosure of compromised Docker hub accounts delivering cryptocurrency miners, we analyze these accounts and discover more malicious actions that you need to be aware of.
By: Trend Micro Research Dec 01, 2021 Read time: ( words)
Save to Folio
In early November, we disclosed that compromised Docker Hub accounts were being used for cryptocurrency mining and that these activities were tied to the TeamTNT threat actor. While those accounts have now been removed, we were still able to investigate TeamTNT’s activities in connection with these compromised accounts.
In addition to the behavior we noted earlier, we identified several other actions that the same threat actor carried out in different ven
Trendmicro
Analyzing How TeamTNT Used Compromised Docker Hub Accounts
blogs_trendmicro·2021-12-01
Analyzing How TeamTNT Used Compromised Docker Hub Accounts
Nube
## Analyzing How TeamTNT Used Compromised Docker Hub Accounts
Following our previous disclosure of compromised Docker hub accounts delivering cryptocurrency miners, we analyze these accounts and discover more malicious actions that you need to be aware of.
By: Trend Micro Research Dec 01, 2021 Read time: ( words)
Save to Folio
In early November, we disclosed that compromised Docker Hub accounts were being used for cryptocurrency mining and that these activities were tied to the TeamTNT threat actor. While those accounts have now been removed, we were still able to investigate TeamTNT’s activities in connection with these compromised accounts.
In addition to the behavior we noted earlier, we identified several other actions that the same threat actor carried out in different venu
Trendmicro
Analyzing How TeamTNT Used Compromised Docker Hub Accounts
blogs_trendmicro·2021-12-01
Analyzing How TeamTNT Used Compromised Docker Hub Accounts
Cloud
# Analyzing How TeamTNT Used Compromised Docker Hub Accounts
Following our previous disclosure of compromised Docker hub accounts delivering cryptocurrency miners, we analyze these accounts and discover more malicious actions that you need to be aware of.
By: Trend Micro Research
2021/12/01
Read time: ( words)
Save to Folio
In early November, we disclosed that compromised Docker Hub accounts were being used for cryptocurrency mining and that these activities were tied to the TeamTNT threat actor. While those accounts have now been removed, we were still able to investigate TeamTNT’s activities in connection with these compromised accounts.
In addition to the behavior we noted earlier, we identified several other actions that the same threat actor carried out in different venue
Trendmicro
Analyzing How TeamTNT Used Compromised Docker Hub Accounts
blogs_trendmicro·2021-12-01
Analyzing How TeamTNT Used Compromised Docker Hub Accounts
Cloud
## Analyzing How TeamTNT Used Compromised Docker Hub Accounts
Following our previous disclosure of compromised Docker hub accounts delivering cryptocurrency miners, we analyze these accounts and discover more malicious actions that you need to be aware of.
By: Trend Micro Research 2021/12/01 Read time: ( words)
Save to Folio
In early November, we disclosed that compromised Docker Hub accounts were being used for cryptocurrency mining and that these activities were tied to the TeamTNT threat actor. While those accounts have now been removed, we were still able to investigate TeamTNT’s activities in connection with these compromised accounts.
In addition to the behavior we noted earlier, we identified several other actions that the same threat actor carried out in different venue
Qualys
Container Security Becomes a Priority for Enterprises | Qualys
blogs_qualys·2019-01-09
Container Security Becomes a Priority for Enterprises | Qualys
Among the IT innovations that businesses are using to digitally transform operations, containers might be the most disruptive and revolutionary.
“They’re a real game changer,” Qualys Chief Product Officer Sumedh Thakar said at QSC 2018 in Las Vegas.
DevOps teams have embraced containers because they boost speed and flexibility in app development and delivery, and are ideal for microservices. In fact, by 2020 more than 50% of organizations will run containerized applications in production, up from under 20% in 2017, according to Gartner. Thus, security teams must prioritize protecting the applications that DevOps teams create with this OS virtualization method.
“We see container security as a significant new paradigm coming at us, which will bring a lot of change,” Qualys CEO Philippe Co
Qualys
Container Security Becomes a Priority for Enterprises
blogs_qualys·2019-01-09
Container Security Becomes a Priority for Enterprises
Among the IT innovations that businesses are using to digitally transform operations, containers might be the most disruptive and revolutionary.
“They’re a real game changer,” Qualys Chief Product Officer Sumedh Thakar said at QSC 2018 in Las Vegas.
DevOps teams have embraced containers because they boost speed and flexibility in app development and delivery, and are ideal for microservices. In fact, by 2020 more than 50% of organizations will run containerized applications in production, up from under 20% in 2017, according to Gartner . Thus, security teams must prioritize protecting the applications that DevOps teams create with this OS virtualization method.
“We see container security as a significant new paradigm coming at us, which will bring a lot of change,” Qualys CEO Philippe C
Unit42
Demystifying Kubernetes CVE-2018-1002105 (and a dead simple exploit)
blogs_unit42·2018-12-09·CVSS 9.8
CVE-2018-1002105 [CRITICAL] Demystifying Kubernetes CVE-2018-1002105 (and a dead simple exploit)
Earlier this week a major vulnerability in Kubernetes was made public by its maintainers. It was originally caught as a bug by Darren Shepherd and was later marked as a critical vulnerability and assigned CVE-2018-1002105. Its implications were clearly laid out in its Github issue page by Kubernetes developer Jordan Liggitt. The bug was fixed and new versions were tagged for all supported Kubernetes releases.
Many technology news sites published articles with warnings, and cloud providers followed with their own updates and mitigations (Google, Azure, AWS). At Twistlock, our CTO John Morello authored an excellent post with all the relevant details and Twistlock platform mitigations.
Since then I’ve seen multiple tools and scripts released and many commercial companies addressed this vuln
Unit42
Demystifying Kubernetes CVE-2018-1002105 (and a dead simple exploit)
blogs_unit42·2018-12-09·CVSS 9.8
CVE-2018-1002105 [CRITICAL] Demystifying Kubernetes CVE-2018-1002105 (and a dead simple exploit)
## Demystifying Kubernetes CVE-2018-1002105 (and a dead simple exploit)
Ariel Zelivansky
Published: December 9, 2018
Cloud Cybersecurity Research
Threat Research
Vulnerabilities
CVE-2018-1002105
Kubernetes
Earlier this week a major vulnerability in Kubernetes was made public by its maintainers. It was originally caught as a bug by Darren Shepherd and was later marked as a critical vulnerability and assigned CVE-2018-1002105. Its implications were clearly laid out in its Github issue page by Kubernetes developer Jordan Liggitt. The bug was fixed and new versions were tagged for all supported Kubernetes releases.
Many technology news sites published articles with warnings, and cloud providers followed with their own updates and mitigations ( Google , Azure , AWS ). At Twistlock, ou
Tenable
Kubernetes Privilege Escalation Vulnerability Publicly Disclosed (CVE-2018-1002105)
blogs_tenable·2018-12-04·CVSS 9.8
CVE-2018-1002105 [CRITICAL] Kubernetes Privilege Escalation Vulnerability Publicly Disclosed (CVE-2018-1002105)
Blog / Cyber Exposure Alerts
Subscribe
# Kubernetes Privilege Escalation Vulnerability Publicly Disclosed (CVE-2018-1002105)
Satnam Narang
December 4, 2018
2 Min Read
Patches are available for a critical privilege escalation flaw (CVE-2018-1002105) in the open-source container orchestration system, Kubernetes.
## Background
On December 3, details about a privilege escalation vulnerability in Kubernetes, the popular open source container orchestration system, were publicly disclosed by the Kubernetes team. Kubernetes is used to automate the deployment, scaling, and management of containerized applications.
## Vulnerability details
Designated as CVE-2018-1002105, the vulnerability exists in the proxy handling function of the Kubernetes API server. Arbitrary requests can be made to t
Tenable
Kubernetes Privilege Escalation Vulnerability Publicly Disclosed (CVE-2018-1002105)
blogs_tenable·2018-12-04·CVSS 9.8
[CRITICAL] Kubernetes Privilege Escalation Vulnerability Publicly Disclosed (CVE-2018-1002105)
## Cloud Exposure
Tenable Cloud Security (CNAPP) Request a demo
Tenable Cloud Vulnerability Management Request a demo
Tenable CIEM Request a demo
Secure your cloud
## Vulnerability Exposure
Tenable Vulnerability Management Try for free
Tenable Security Center Request a demo
Tenable Web App Scanning Try for free
Tenable Patch Management Request a demo
Tenable Enclave Security Request a demo
Tenable Attack Surface Management Request a demo
Tenable Nessus Try for free
## AI Exposure
Tenable AI Exposure Request a demo
## OT/IoT Exposure
Tenable OT Security Request a demo
## Identity Exposure
Tenable Identity Exposure Request a demo
## Business needs
Active Directory
AI Security Posture Management (AI-SPM)
AWS security
Azure security
Cloud Security Posture Man
Bugzilla
CVE-2018-1002105 origin: kubernetes: authentication/authorization bypass in the handling of non-101 responses [fedora-all]
bugzilla·2018-12-05·CVSS 9.8
CVE-2018-1002105 [CRITICAL] CVE-2018-1002105 origin: kubernetes: authentication/authorization bypass in the handling of non-101 responses [fedora-all]
CVE-2018-1002105 origin: kubernetes: authentication/authorization bypass in the handling of non-101 responses [fedora-all]
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of fedora-all.
For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.
For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs
When submitting as an update, use the fedpkg template provided in the next
comment(s). This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.
Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message.
NOTE: t
Bugzilla
CVE-2018-1002105 kubernetes: authentication/authorization bypass in the handling of non-101 responses [fedora-all]
bugzilla·2018-12-03·CVSS 9.8
CVE-2018-1002105 [CRITICAL] CVE-2018-1002105 kubernetes: authentication/authorization bypass in the handling of non-101 responses [fedora-all]
CVE-2018-1002105 kubernetes: authentication/authorization bypass in the handling of non-101 responses [fedora-all]
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of fedora-all.
For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.
For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs
When submitting as an update, use the fedpkg template provided in the next
comment(s). This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.
Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message.
NOTE: this issu
Bugzilla
CVE-2018-1002105 kubernetes: authentication/authorization bypass in the handling of non-101 responses
bugzilla·2018-11-08·CVSS 9.8
CVE-2018-1002105 [CRITICAL] CVE-2018-1002105 kubernetes: authentication/authorization bypass in the handling of non-101 responses
CVE-2018-1002105 kubernetes: authentication/authorization bypass in the handling of non-101 responses
With a specially crafted request, users are able to establish a connection through the Kubernetes API server to backend servers, then send arbitrary requests over the same connection directly to the backend, authenticated with the Kubernetes API server’s TLS credentials used to establish the backend connection.
Discussion:
Mitigation:
See the vulnerability article for mitigation procedures.
---
Upstream commit https://github.com/kubernetes/apimachinery/commit/b5d13f078af116d09ad9c323357497a0e9f623fc
---
Created kubernetes tracking bugs for this issue:
Affects: fedora-all [bug 1655686]
---
This issue has been addressed in the following products:
Red Hat OpenShift Container Platf
http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00041.htmlhttp://www.openwall.com/lists/oss-security/2019/06/28/2http://www.openwall.com/lists/oss-security/2019/07/06/3http://www.openwall.com/lists/oss-security/2019/07/06/4http://www.securityfocus.com/bid/106068https://access.redhat.com/errata/RHSA-2018:3537https://access.redhat.com/errata/RHSA-2018:3549https://access.redhat.com/errata/RHSA-2018:3551https://access.redhat.com/errata/RHSA-2018:3598https://access.redhat.com/errata/RHSA-2018:3624https://access.redhat.com/errata/RHSA-2018:3742https://access.redhat.com/errata/RHSA-2018:3752https://access.redhat.com/errata/RHSA-2018:3754https://github.com/evict/poc_CVE-2018-1002105https://github.com/kubernetes/kubernetes/issues/71411https://groups.google.com/forum/#%21topic/kubernetes-announce/GVllWCg6L88https://security.netapp.com/advisory/ntap-20190416-0001/https://www.coalfire.com/The-Coalfire-Blog/December-2018/Kubernetes-Vulnerability-What-You-Can-Should-Dohttps://www.exploit-db.com/exploits/46052/https://www.exploit-db.com/exploits/46053/http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00041.htmlhttp://www.openwall.com/lists/oss-security/2019/06/28/2http://www.openwall.com/lists/oss-security/2019/07/06/3http://www.openwall.com/lists/oss-security/2019/07/06/4http://www.securityfocus.com/bid/106068https://access.redhat.com/errata/RHSA-2018:3537https://access.redhat.com/errata/RHSA-2018:3549https://access.redhat.com/errata/RHSA-2018:3551https://access.redhat.com/errata/RHSA-2018:3598https://access.redhat.com/errata/RHSA-2018:3624https://access.redhat.com/errata/RHSA-2018:3742https://access.redhat.com/errata/RHSA-2018:3752https://access.redhat.com/errata/RHSA-2018:3754https://github.com/evict/poc_CVE-2018-1002105https://github.com/kubernetes/kubernetes/issues/71411https://groups.google.com/forum/#%21topic/kubernetes-announce/GVllWCg6L88https://security.netapp.com/advisory/ntap-20190416-0001/https://www.coalfire.com/The-Coalfire-Blog/December-2018/Kubernetes-Vulnerability-What-You-Can-Should-Dohttps://www.exploit-db.com/exploits/46052/https://www.exploit-db.com/exploits/46053/
2018-12-05
Published