xterm through Patch 370, when Sixel support is enabled, allows attackers to trigger a buffer overflow in set_sixel in graphics_sixel.c via crafted text.

CVE-2022-24130: XTERM - Change Log

The Kubelet and kube-proxy components in versions 1.1.0-1.16.10, 1.17.0-1.17.6, and 1.18.0-1.18.3 were found to contain a security issue which allows adjacent hosts to reach TCP and UDP services bound to 127.0.0.1 running on the node or in the node's network namespace. Such a service is generally thought to be reachable only by other processes on the same host, but due to this defeect, could be reachable by other hosts on the same LAN as the node, or by containers running on the same node as the service.

CVSS Rating:

In typical clusters: medium (5.4) CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

In clusters where API server insecure port has not been disabled: high (8.8) CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

A security issue was discovered in kube-proxy which allows adjacent hosts to reach TCP and UDP services bound to 127.0.0.1 running on the node or in the node's network namespace. For example, if a cluster administrator runs a TCP service on a node that listens on 127.0.0.1:1234, because of this bug, that service would be potentially reachable by other hosts on the same LAN as the node, or by containers running on the same node as the service. If the example service on port 1234 required no additional authentication (because it assumed that only other localhost processes could reach it), then it could be vulnerable to attacks that make use of this bug.

The Kubernetes API Server's default insecure port setting causes the API server to listen on 127.0.0.1:8080 where it will accept requests without authentication. Many Kubernetes installers explicitly disable the API Server's insecure port, but in clusters where it is not disabled, an attacker with access to another system on the same LAN or with control of a container running on the master may be able to reach the API server and execute arbitrary API requests on the cluster. This port is deprecated, and will be removed in Kubernetes v1.20.

**Am I vulnerable?**

You may be vulnerable if:

*   You are running a vulnerable version (see below)
    
*   Your cluster nodes run in an environment where untrusted hosts share the same layer 2 domain (i.e. same LAN) as nodes
    
*   Your cluster allows untrusted pods to run containers with CAP_NET_RAW (the Kubernetes default is to allow this capability).
    
*   Your nodes (or hostnetwork pods) run any localhost-only services which do not require any further authentication. To list services that are potentially affected, run the following commands on nodes:  
       - lsof +c 15 -P -n -i4TCP@127.0.0.1 -sTCP:LISTEN  
      - lsof +c 15 -P -n -i4UDP@127.0.0.1
    
    On a master node, an lsof entry like this indicates that the API server may be listening with an insecure port:
    

    COMMAND        PID  USER FD   TYPE DEVICE SIZE/OFF NODE NAME
    kube-apiserver 123  root  7u  IPv4  26799      0t0  TCP 127.0.0.1:8080 (LISTEN)
    

**Affected Versions**

*   kubelet/kube-proxy v1.18.0-1.18.3
*   kubelet/kube-proxy v1.17.0-1.17.6
*   kubelet/kube-proxy <=1.16.10

**How do I mitigate this vulnerability?**

Prior to upgrading, this vulnerability can be mitigated by manually adding an iptables rule on nodes. This rule will reject traffic to 127.0.0.1 which does not originate on the node.

 iptables -I INPUT --dst 127.0.0.0/8 ! --src 127.0.0.0/8 -m conntrack ! --ctstate RELATED,ESTABLISHED,DNAT -j DROP

Additionally, if your cluster does not already have the API Server insecure port disabled, we strongly suggest that you disable it. Add the following flag to your kubernetes API server command line: --insecure-port=0

**Detection**

Packets on the wire with an IPv4 destination in the range 127.0.0.0/8 and a layer-2 destination MAC address of a node may indicate that an attack is targeting this vulnerability.

**Fixed Versions**

Although the issue is caused by kube-proxy, the current fix for the issue is in kubelet (although future versions may have the fix in kube-proxy instead). We recommend updating both kubelet and kube-proxy to be sure the issue is addressed.

The following versions contain the fix:

*   kubelet/kube-proxy master - fixed by kubelet: block non-forwarded packets from crossing the localhost boundary #91569
*   kubelet/kube-proxy v1.18.4+ - fixed by \[1.18\] kubelet: block non-forwarded packets from crossing the localhost boundary #92038
*   kubelet/kube-proxy v1.17.7+ - fixed by \[1.17\] kubelet: block non-forwarded packets from crossing the localhost boundary #92039
*   kubelet/kube-proxy v1.16.11+ - fixed by \[1.16\] kubelet: block non-forwarded packets from crossing the localhost boundary #92040

To upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#upgrading-a-cluster

**Additional Details**

This issue was originally raised in issue #90259 which details how the kube-proxy sets net.ipv4.conf.all.route_localnet=1 which causes the system not to reject traffic to localhost which originates on other hosts.

IPv6-only services that bind to a localhost address are not affected. 

There may be additional attack vectors possible in addition to those fixed by #91569 and its cherry-picks. For those attacks to succeed, the target service would need to be UDP and the attack could only rely upon sending UDP datagrams since it wouldn't receive any replies. Finally, the target node would need to have reverse-path filtering disabled for an attack to have any effect. Work is ongoing to determine whether and how this issue should be fixed. See #91666 for up-to-date status on this issue.  

**Acknowledgements**

This vulnerability was reported by János Kövér, Ericsson with additional impacts reported by Rory McCune, NCC Group and Yuval Avrahami and Ariel Zelivansky, Palo Alto Networks.

/area security  
/kind bug  
/committee product-security  
/sig network  
/sig node  
/area kubelet

CVE-2020-8558: CVE-2020-8558: Node setting allows for neighboring hosts to bypass localhost boundary · Issue #92315 · kubernetes/kubernetes

An access-control flaw was found in the OpenStack Orchestration (heat) service before 8.0.0, 6.1.0 and 7.0.2 where a service log directory was improperly made world readable. A malicious system user could exploit this flaw to access sensitive information.

Description Summer Long 2017-02-10 04:46:10 UTC

The directory /var/log/heat is world readable and contains log files that are readable, which can result in the exposure of sensitive information. The 'other readable/execute' bits need to be removed from the /var/log/heat directory:

\[stack@instack ~\]$ ls -la /var/log/heat
total 39376
drwxr-xr-x.  2 heat root     4096 Feb  9 01:07 .
drwxr-xr-x. 31 root root     4096 Feb  9 01:02 ..
-rw-r--r--.  1 heat heat   201578 Feb  9 20:09 heat-api-cfn.log
-rw-r--r--.  1 heat heat  4899693 Feb  9 20:09 heat-api.log
-rw-r--r--.  1 heat heat 35193112 Feb  9 23:40 heat-engine.log

Comment 1 Summer Long 2017-02-10 05:07:35 UTC

Acknowledgments:

Name: Hans Feldt (Ericsson)

Comment 3 Summer Long 2017-02-14 22:23:48 UTC

Created openstack-heat tracking bugs for this issue:

Affects: openstack-rdo \[bug 1422265\]

CVE-2017-2621: 1420990 – (CVE-2017-2621) CVE-2017-2621 openstack-heat: /var/log/heat/ is world readable

The WDB target agent debug service in Wind River VxWorks 6.x, 5.x, and earlier, as used on the Rockwell Automation 1756-ENBT series A with firmware 3.2.6 and 3.6.1 and other products, allows remote attackers to read or modify arbitrary memory locations, perform function calls, or manage tasks via requests to UDP port 17185, a related issue to CVE-2005-3804.

**3com Inc. (Inactive) Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**ARRIS Affected**

Notified:  2010-06-18 Updated: 2020-08-31

**Statement Date:   January 20, 2011**

**Vendor Statement**

We have not received a statement from the vendor.

**CERT Addendum**

The following products have been reported to be affected: ARRIS C3™ Cable Modem Termination System Firmware Release <=4.4.4.13

**Actelis Networks Affected**

Notified:  2010-06-29 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Alcatel-Lucent Enterprise Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Allied Telesis Affected**

Notified:  2010-06-29 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Alvarion (Inactive) Affected**

Notified:  2010-06-29 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Aperto Networks Affected**

Notified:  2010-06-29 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Apple Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Avaya Inc. Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Broadcom Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Ceragon Networks Inc Affected**

Notified:  2010-06-29 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Cisco Affected**

**D-Link Systems Inc. Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Dell Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Dell EMC Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Digicom Affected**

Notified:  2010-06-29 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**DrayTek Corporation Affected**

Notified:  2010-06-29 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Enablence Affected**

Notified:  2010-06-29 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Enterasys Networks Affected**

Notified:  2010-06-18 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Ericsson Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Fluke Networks Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Foundry Brocade Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Gilat Network Systems Affected**

Notified:  2010-06-29 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Guangzhou Gaoke Communications Affected**

Notified:  2010-06-29 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Hewlett Packard Enterprise Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Huawei Affected**

Updated: 2020-08-31

**Statement Date:   June 18, 2010**

**Vendor Statement**

We have not received a statement from the vendor.

**IWATSU Voice Networks Affected**

Notified:  2010-06-29 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Keda Communications Affected**

Notified:  2010-06-29 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Knovative Inc Affected**

Notified:  2010-06-29 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Lenovo Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Lutron Electronics Affected**

Notified:  2010-06-29 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Maipu Communication Technology Affected**

Notified:  2010-06-29 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Mitel Networks Inc. Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Motorola Inc. Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Netgear Inc. Affected**

Notified:  2010-06-18 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Nokia Affected**

Notified:  2010-06-18 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Nortel Networks Inc. Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Polycom Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Statement Date:   December 07, 2010**

**Vendor Statement**

We have not received a statement from the vendor.

**CERT Addendum**

The release notes for SoundPoint IP/SoundStation IP SIP software states that version 3.1.2 has closed the debug port. "47450: Port 17185 is open, presenting a security risk" http://downloads.polycom.com/voice/voip/relnotes/spip\_ssip\_v3\_1\_6\_Legacy\_release\_notes.pdf

**Proxim Inc. Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Rad Vision Inc. Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Ricoh Company Ltd. Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**SEIKO EPSON Corp. / Epson America Inc. Affected**

Notified:  2010-06-18 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**SFR Affected**

Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**CERT Addendum**

newsoft reports that the SFR (formerly Neuf Cegetel and Neuf Telecom) Trio3C has the debug service enabled.

**SMC Networks Inc. Affected**

Notified:  2010-06-18 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Schneider Electric Affected**

Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**CERT Addendum**

The Modicon M340 with firmware version 2.5 was reported to run VxWorks 6.4 and have the debug port enabled.

**ShoreTel Inc. Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Siemens Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

Security Advisory Report - OBSO-1010-01 Enabled VxWorks debug service Creation Date: 2010-10-15 Last Update: 2010-10-15 Summary A security researcher has identified a large number of products based on the VxWorks platform provided by Wind River Systems with a debug service enabled by default at port 17185/udp. Vulnerability Details The debug service provides full access to the memory of an affected device and allows for memory to be written as well as functions to be called. Of the various products based on VxWorks, the following are not affected by this vulnerability: HiPath Wireless Convergence, RG 8700, optiPoint 410/420 SIP and HFA (V5). Affected Products HiPath 3000 (HG 1500 Gateway) HiPath 4000 (HG 35xx Gateway) optiPoint 410/420 HFA, versions before V5 optiPoint 600 office Recommended Actions In general, it is recommended not to attach the mentioned systems directly at the internet. Appropriate firewall rules should be implemented to restrict access to the debug service (17185/udp). The problem is solved in the following versions; an update to these or higher versions is highly recommended: HiPath 3000 V8: V8 R5.2.0 HiPath 4000 V4: V4 R4.1.12 HiPath 4000 V5: V5 R1.2.4 Please note: HiPath 3000 V7: You need to upgrade the HG 1500 gateway only. Please use V8 R5.2.0 for this. You may keep the system itself in V7. HiPath 3000 V6 and earlier have reached end of SW support; please consider an upgrade to V7 or V8 HiPath 4000 V3 and earlier have reached end of SW support; please consider an upgrade to V4 or higher. Some older, unsupported versions of optiPoint 410/420 HFA IP phones are also vulnerable. Please ensure, that V5 is installed on all phones. optiPoint 600 office has reached end of life since a few years already; an update is unfortunately not available References http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2965 http://blog.metasploit.com/2010/08/vxworks-vulnerabilities.html http://www.kb.cert.org/vuls/id/362332 Revision History 2010-10-15 Initial release Contact and Disclaimer OpenScale Baseline Security Office obso@siemens-enterprise.com © Siemens Enterprise Communications GmbH & Co KG 2010 Siemens Enterprise Communications GmbH & Co. KG is a Trademark Licensee of Siemens AG The information provided in this document is subject to change without notice. Siemens Enterpise Communications GmbH & Co KG (SEN) assumes no responsibility for any errors that may appear in this document, and it does not affect your current support agreements with SEN. Any trademarks referenced in this document are the property of their respective owners. ---End Vendor Statement-------------------------------------------------------------------

**CERT Addendum**

The vendor provided the above advisory information for their affected products.

**TRENDnet Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Tut Systems Affected**

Notified:  2010-06-18 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Wind River Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

Wind River has analyzed VU#362332, and determined that all versions of VxWorks could be vulnerable if the WDB agent is left enabled in production systems and the system is network attached. VxWorks has a very strong track record of offering secure products and Wind River is committed to active threat monitoring, rapid assessment, threat prioritization, expedited remediation, response and proactive customer contact. Customers are encouraged to follow the remediation actions outlined in the SOLUTION section of the vulnerability post. Registered users can access Wind River's online support for more information by following this link: https://support.windriver.com/olsPortal/faces/maintenance/downloadDetails.jspx?contentId=033708 Or contact Wind River technical support for more information: http://windriver.com/support/

**CERT Addendum**

Within the VxWorks Kernel programmers guide it states: “For production systems, you will want to reconfigure VxWorks with only those components needed for deployed operation, and to build it as the appropriate type of system image. You will likely want to remove components required for host development support, such as the WDB target agent and debugging components (INCLUDE\_WDB and INCLUDE\_DEBUG), as well as to remove any other operating system components not required to support your application. Other considerations may include reducing the memory requirements of the system, speeding up boot time, and security issues.”

**Xerox Affected**

Notified:  2010-06-14 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**amx Affected**

Notified:  2010-06-29 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Canon Not Affected**

Notified:  2010-06-18 Updated: 2020-08-31

**CVE-2010-2965**

Not Affected

**Vendor Statement**

We have not received a statement from the vendor.

**Brocade Communication Systems Unknown**

Notified:  2010-08-03 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

**Intel Unknown**

Notified:  2010-07-02 Updated: 2020-08-31

**Vendor Statement**

We have not received a statement from the vendor.

Tag

#ericsson