Search Results
There are 48 CVE Records that match your search.
| Name | Description |
|---|---|
| CVE-2024-24760 | mailcow is a dockerized email package, with multiple containers linked in one bridged network. A security vulnerability has been identified in mailcow affecting versions < 2024-01c. This vulnerability potentially allows attackers on the same subnet to connect to exposed ports of a Docker container, even when the port is bound to 127.0.0.1. The vulnerability has been addressed by implementing additional iptables/nftables rules. These rules drop packets for Docker containers on ports 3306, 6379, 8983, and 12345, where the input interface is not `br-mailcow` and the output interface is `br-mailcow`. |
| CVE-2023-33376 | Connected IO v2.1.0 and prior has an argument injection vulnerability in its iptables command message in its communication protocol, enabling attackers to execute arbitrary OS commands on devices. |
| CVE-2023-28842 | Moby) is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as moby/moby is commonly referred to as *Docker*. Swarm Mode, which is compiled in and delivered by default in `dockerd` and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code. The `overlay` network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with the VXLAN metadata, including a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes. Encrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption. When setting an endpoint up on an encrypted overlay network, Moby installs three iptables (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the `u32` iptables extension provided by the `xt_u32` kernel module to directly filter on a VXLAN packet's VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN. The `overlay` driver dynamically and lazily defines the kernel configuration for the VXLAN network on each node as containers are attached and detached. Routes and encryption parameters are only defined for destination nodes that participate in the network. The iptables rules that prevent encrypted overlay networks from accepting unencrypted packets are not created until a peer is available with which to communicate. Encrypted overlay networks silently accept cleartext VXLAN datagrams that are tagged with the VNI of an encrypted overlay network. As a result, it is possible to inject arbitrary Ethernet frames into the encrypted overlay network by encapsulating them in VXLAN datagrams. The implications of this can be quite dire, and GHSA-vwm3-crmr-xfxw should be referenced for a deeper exploration. Patches are available in Moby releases 23.0.3, and 20.10.24. As Mirantis Container Runtime's 20.10 releases are numbered differently, users of that platform should update to 20.10.16. Some workarounds are available. In multi-node clusters, deploy a global ‘pause’ container for each encrypted overlay network, on every node. For a single-node cluster, do not use overlay networks of any sort. Bridge networks provide the same connectivity on a single node and have no multi-node features. The Swarm ingress feature is implemented using an overlay network, but can be disabled by publishing ports in `host` mode instead of `ingress` mode (allowing the use of an external load balancer), and removing the `ingress` network. If encrypted overlay networks are in exclusive use, block UDP port 4789 from traffic that has not been validated by IPSec. |
| CVE-2023-28841 | Moby is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as moby/moby is commonly referred to as *Docker*. Swarm Mode, which is compiled in and delivered by default in `dockerd` and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code. The `overlay` network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with the VXLAN metadata, including a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes. Encrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption. When setting an endpoint up on an encrypted overlay network, Moby installs three iptables (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the `u32` iptables extension provided by the `xt_u32` kernel module to directly filter on a VXLAN packet's VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN. An iptables rule designates outgoing VXLAN datagrams with a VNI that corresponds to an encrypted overlay network for IPsec encapsulation. Encrypted overlay networks on affected platforms silently transmit unencrypted data. As a result, `overlay` networks may appear to be functional, passing traffic as expected, but without any of the expected confidentiality or data integrity guarantees. It is possible for an attacker sitting in a trusted position on the network to read all of the application traffic that is moving across the overlay network, resulting in unexpected secrets or user data disclosure. Thus, because many database protocols, internal APIs, etc. are not protected by a second layer of encryption, a user may use Swarm encrypted overlay networks to provide confidentiality, which due to this vulnerability this is no longer guaranteed. Patches are available in Moby releases 23.0.3, and 20.10.24. As Mirantis Container Runtime's 20.10 releases are numbered differently, users of that platform should update to 20.10.16. Some workarounds are available. Close the VXLAN port (by default, UDP port 4789) to outgoing traffic at the Internet boundary in order to prevent unintentionally leaking unencrypted traffic over the Internet, and/or ensure that the `xt_u32` kernel module is available on all nodes of the Swarm cluster. |
| CVE-2023-28840 | Moby is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as moby/moby, is commonly referred to as *Docker*. Swarm Mode, which is compiled in and delivered by default in dockerd and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code. The overlay network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes. Encrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption. When setting an endpoint up on an encrypted overlay network, Moby installs three iptables (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the u32 iptables extension provided by the xt_u32 kernel module to directly filter on a VXLAN packet's VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN. Two iptables rules serve to filter incoming VXLAN datagrams with a VNI that corresponds to an encrypted network and discards unencrypted datagrams. The rules are appended to the end of the INPUT filter chain, following any rules that have been previously set by the system administrator. Administrator-set rules take precedence over the rules Moby sets to discard unencrypted VXLAN datagrams, which can potentially admit unencrypted datagrams that should have been discarded. The injection of arbitrary Ethernet frames can enable a Denial of Service attack. A sophisticated attacker may be able to establish a UDP or TCP connection by way of the container’s outbound gateway that would otherwise be blocked by a stateful firewall, or carry out other escalations beyond simple injection by smuggling packets into the overlay network. Patches are available in Moby releases 23.0.3 and 20.10.24. As Mirantis Container Runtime's 20.10 releases are numbered differently, users of that platform should update to 20.10.16. Some workarounds are available. Close the VXLAN port (by default, UDP port 4789) to incoming traffic at the Internet boundary to prevent all VXLAN packet injection, and/or ensure that the `xt_u32` kernel module is available on all nodes of the Swarm cluster. |
| CVE-2021-32675 | Redis is an open source, in-memory database that persists on disk. When parsing an incoming Redis Standard Protocol (RESP) request, Redis allocates memory according to user-specified values which determine the number of elements (in the multi-bulk header) and size of each element (in the bulk header). An attacker delivering specially crafted requests over multiple connections can cause the server to allocate significant amount of memory. Because the same parsing mechanism is used to handle authentication requests, this vulnerability can also be exploited by unauthenticated users. The problem is fixed in Redis versions 6.2.6, 6.0.16 and 5.0.14. An additional workaround to mitigate this problem without patching the redis-server executable is to block access to prevent unauthenticated users from connecting to Redis. This can be done in different ways: Using network access control tools like firewalls, iptables, security groups, etc. or Enabling TLS and requiring users to authenticate using client side certificates. |
| CVE-2021-20238 | It was found in OpenShift Container Platform 4 that ignition config, served by the Machine Config Server, can be accessed externally from clusters without authentication. The MCS endpoint (port 22623) provides ignition configuration used for bootstrapping Nodes and can include some sensitive data, e.g. registry pull secrets. There are two scenarios where this data can be accessed. The first is on Baremetal, OpenStack, Ovirt, Vsphere and KubeVirt deployments which do not have a separate internal API endpoint and allow access from outside the cluster to port 22623 from the standard OpenShift API Virtual IP address. The second is on cloud deployments when using unsupported network plugins, which do not create iptables rules that prevent to port 22623. In this scenario, the ignition config is exposed to all pods within the cluster and cannot be accessed externally. |
| CVE-2021-20177 | A flaw was found in the Linux kernel's implementation of string matching within a packet. A privileged user (with root or CAP_NET_ADMIN) when inserting iptables rules could insert a rule which can panic the system. Kernel before kernel 5.5-rc1 is affected. |
| CVE-2021-20149 | Trendnet AC2600 TEW-827DRU version 2.08B01 does not have sufficient access controls for the WAN interface. The default iptables ruleset for governing access to services on the device only apply to IPv4. All services running on the devices are accessible via the WAN interface via IPv6 by default. |
| CVE-2020-36694 | An issue was discovered in netfilter in the Linux kernel before 5.10. There can be a use-after-free in the packet processing context, because the per-CPU sequence count is mishandled during concurrent iptables rules replacement. This could be exploited with the CAP_NET_ADMIN capability in an unprivileged namespace. NOTE: cc00bca was reverted in 5.12. |
| CVE-2020-36178 | oal_ipt_addBridgeIsolationRules on TP-Link TL-WR840N 6_EU_0.9.1_4.16 devices allows OS command injection because a raw string entered from the web interface (an IP address field) is used directly for a call to the system library function (for iptables). NOTE: oal_ipt_addBridgeIsolationRules is not the only function that calls util_execSystem. |
| CVE-2020-15590 | A vulnerability in the Private Internet Access (PIA) VPN Client for Linux 1.5 through 2.3+ allows remote attackers to bypass an intended VPN kill switch mechanism and read sensitive information via intercepting network traffic. Since 1.5, PIA has supported a “split tunnel” OpenVPN bypass option. The PIA killswitch & associated iptables firewall is designed to protect you while using the Internet. When the kill switch is configured to block all inbound and outbound network traffic, privileged applications can continue sending & receiving network traffic if net.ipv4.ip_forward has been enabled in the system kernel parameters. For example, a Docker container running on a host with the VPN turned off, and the kill switch turned on, can continue using the internet, leaking the host IP (CWE 200). In PIA 2.4.0+, policy-based routing is enabled by default and is used to direct all forwarded packets to the VPN interface automatically. |
| CVE-2020-0347 | In iptables, there is a possible out of bounds write due to an incorrect bounds check. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-136658008 |
| CVE-2019-9946 | Cloud Native Computing Foundation (CNCF) CNI (Container Networking Interface) 0.7.4 has a network firewall misconfiguration which affects Kubernetes. The CNI 'portmap' plugin, used to setup HostPorts for CNI, inserts rules at the front of the iptables nat chains; which take precedence over the KUBE- SERVICES chain. Because of this, the HostPort/portmap rule could match incoming traffic even if there were better fitting, more specific service definition rules like NodePorts later in the chain. The issue is fixed in CNI 0.7.5 and Kubernetes 1.11.9, 1.12.7, 1.13.5, and 1.14.0. |
| CVE-2019-9735 | An issue was discovered in the iptables firewall module in OpenStack Neutron before 10.0.8, 11.x before 11.0.7, 12.x before 12.0.6, and 13.x before 13.0.3. By setting a destination port in a security group rule along with a protocol that doesn't support that option (for example, VRRP), an authenticated user may block further application of security group rules for instances from any project/tenant on the compute hosts to which it's applied. (Only deployments using the iptables security group driver are affected.) |
| CVE-2019-11360 | A buffer overflow in iptables-restore in netfilter iptables 1.8.2 allows an attacker to (at least) crash the program or potentially gain code execution via a specially crafted iptables-save file. This is related to add_param_to_argv in xshared.c. |
| CVE-2018-19986 | In the /HNAP1/SetRouterSettings message, the RemotePort parameter is vulnerable, and the vulnerability affects D-Link DIR-818LW Rev.A 2.05.B03 and DIR-822 B1 202KRb06 devices. In the SetRouterSettings.php source code, the RemotePort parameter is saved in the $path_inf_wan1."/web" internal configuration memory without any regex checking. And in the IPTWAN_build_command function of the iptwan.php source code, the data in $path_inf_wan1."/web" is used with the iptables command without any regex checking. A vulnerable /HNAP1/SetRouterSettings XML message could have shell metacharacters in the RemotePort element such as the `telnetd` string. |
| CVE-2017-8217 | TP-Link C2 and C20i devices through firmware 0.9.1 4.2 v0032.0 Build 160706 Rel.37961n have too permissive iptables rules, e.g., SNMP is not blocked on any interface. |
| CVE-2017-7543 | A race-condition flaw was discovered in openstack-neutron before 7.2.0-12.1, 8.x before 8.3.0-11.1, 9.x before 9.3.1-2.1, and 10.x before 10.0.2-1.1, where, following a minor overcloud update, neutron security groups were disabled. Specifically, the following were reset to 0: net.bridge.bridge-nf-call-ip6tables and net.bridge.bridge-nf-call-iptables. The race was only triggered by an update, at which point an attacker could access exposed tenant VMs and network resources. |
| CVE-2017-6079 | The HTTP web-management application on Edgewater Networks Edgemarc appliances has a hidden page that allows for user-defined commands such as specific iptables routes, etc., to be set. You can use this page as a web shell essentially to execute commands, though you get no feedback client-side from the web application: if the command is valid, it executes. An example is the wget command. The page that allows this has been confirmed in firmware as old as 2006. |
| CVE-2017-18017 | The tcpmss_mangle_packet function in net/netfilter/xt_TCPMSS.c in the Linux kernel before 4.11, and 4.9.x before 4.9.36, allows remote attackers to cause a denial of service (use-after-free and memory corruption) or possibly have unspecified other impact by leveraging the presence of xt_TCPMSS in an iptables action. |
| CVE-2016-9599 | puppet-tripleo before versions 5.5.0, 6.2.0 is vulnerable to an access-control flaw in the IPtables rules management, which allowed the creation of TCP/UDP rules with empty port values. If SSL is enabled, a malicious user could use these open ports to gain access to unauthorized resources. |
| CVE-2016-5363 | The IPTables firewall in OpenStack Neutron before 7.0.4 and 8.0.0 through 8.1.0 allows remote attackers to bypass an intended MAC-spoofing protection mechanism and consequently cause a denial of service or intercept network traffic via (1) a crafted DHCP discovery message or (2) crafted non-IP traffic. |
| CVE-2016-5362 | The IPTables firewall in OpenStack Neutron before 7.0.4 and 8.0.0 through 8.1.0 allows remote attackers to bypass an intended DHCP-spoofing protection mechanism and consequently cause a denial of service or intercept network traffic via a crafted DHCP discovery message. |
| CVE-2016-1455 | Cisco NX-OS before 7.0(3)I2(2e) and 7.0(3)I4 before 7.0(3)I4(1) has an incorrect iptables local-interface configuration, which allows remote attackers to obtain sensitive information via TCP or UDP traffic, aka Bug ID CSCuz05365. |
| CVE-2015-8914 | The IPTables firewall in OpenStack Neutron before 7.0.4 and 8.0.0 through 8.1.0 allows remote attackers to bypass an intended ICMPv6-spoofing protection mechanism and consequently cause a denial of service or intercept network traffic via a link-local source address. |
| CVE-2015-8326 | The IPTables-Parse module before 1.6 for Perl allows local users to write to arbitrary files owned by the current user. |
| CVE-2015-3221 | OpenStack Neutron before 2014.2.4 (juno) and 2015.1.x before 2015.1.1 (kilo), when using the IPTables firewall driver, allows remote authenticated users to cause a denial of service (L2 agent crash) by adding an address pair that is rejected by the ipset tool. |
| CVE-2014-8160 | net/netfilter/nf_conntrack_proto_generic.c in the Linux kernel before 3.18 generates incorrect conntrack entries during handling of certain iptables rule sets for the SCTP, DCCP, GRE, and UDP-Lite protocols, which allows remote attackers to bypass intended access restrictions via packets with disallowed port numbers. |
| CVE-2012-2663 | extensions/libxt_tcp.c in iptables through 1.4.21 does not match TCP SYN+FIN packets in --syn rules, which might allow remote attackers to bypass intended firewall restrictions via crafted packets. NOTE: the CVE-2012-6638 fix makes this issue less relevant. |
| CVE-2012-2101 | Openstack Compute (Nova) Folsom, 2012.1, and 2011.3 does not limit the number of security group rules, which allows remote authenticated users with certain permissions to cause a denial of service (CPU and hard drive consumption) via a network request that triggers a large number of iptables rules. |
| CVE-2011-4600 | The networkReloadIptablesRules function in network/bridge_driver.c in libvirt before 0.9.9 does not properly handle firewall rules on bridge networks when libvirtd is restarted, which might allow remote attackers to bypass intended access restrictions via a (1) DNS or (2) DHCP query. |
| CVE-2010-2242 | Red Hat libvirt 0.2.0 through 0.8.2 creates iptables rules with improper mappings of privileged source ports, which allows guest OS users to bypass intended access restrictions by leveraging IP address and source-port values, as demonstrated by copying and deleting an NFS directory tree. |
| CVE-2009-4664 | Firewall Builder 3.0.4, 3.0.5, and 3.0.6, when running on Linux, allows local users to gain privileges via a symlink attack on an unspecified temporary file that is created by the iptables script. |
| CVE-2009-1184 | The selinux_ip_postroute_iptables_compat function in security/selinux/hooks.c in the SELinux subsystem in the Linux kernel before 2.6.27.22, and 2.6.28.x before 2.6.28.10, when compat_net is enabled, omits calls to avc_has_perm for the (1) node and (2) port, which allows local users to bypass intended restrictions on network traffic. NOTE: this was incorrectly reported as an issue fixed in 2.6.27.21. |
| CVE-2005-0449 | The netfilter/iptables module in Linux before 2.6.8.1 allows remote attackers to cause a denial of service (kernel crash) or bypass firewall rules via crafted packets, which are not properly handled by the skb_checksum_help function. |
| CVE-2004-0986 | Iptables before 1.2.11, under certain conditions, does not properly load the required modules at system startup, which causes the firewall rules to fail to load and protect the system from remote attackers. |
| CVE-2004-0816 | Integer underflow in the firewall logging rules for iptables in Linux before 2.6.8 allows remote attackers to cause a denial of service (application crash) via a malformed IP packet. |
| CVE-2004-0626 | The tcp_find_option function of the netfilter subsystem in Linux kernel 2.6, when using iptables and TCP options rules, allows remote attackers to cause a denial of service (CPU consumption by infinite loop) via a large option length that produces a negative integer after a casting operation to the char type. |
| CVE-2004-0592 | The tcp_find_option function of the netfilter subsystem for IPv6 in the SUSE Linux 2.6.5 kernel with USAGI patches, when using iptables and TCP options rules, allows remote attackers to cause a denial of service (CPU consumption by infinite loop) via a large option length that produces a negative integer after a casting operation to the char type, a similar flaw to CVE-2004-0626. |
| CVE-2003-0857 | The (1) ipq_read and (2) ipulog_read functions in iptables allow local users to cause a denial of service by sending spoofed messages as other users to the kernel netlink interface. |
| CVE-2003-0080 | The iptables ruleset in Gnome-lokkit in Red Hat Linux 8.0 does not include any rules in the FORWARD chain, which could allow attackers to bypass intended access restrictions if packet forwarding is enabled. |
| CVE-2002-2254 | The experimental IP packet queuing feature in Netfilter / IPTables in Linux kernel 2.4 up to 2.4.19 and 2.5 up to 2.5.31, when a privileged process exits and network traffic is not being queued, may allow a later process with the same Process ID (PID) to access certain network traffic that would otherwise be restricted. |
| CVE-2002-0704 | The Network Address Translation (NAT) capability for Netfilter ("iptables") 1.2.6a and earlier leaks translated IP addresses in ICMP error messages. |
| CVE-2001-1572 | The MAC module in Netfilter in Linux kernel 2.4.1 through 2.4.11, when configured to filter based on MAC addresses, allows remote attackers to bypass packet filters via small packets. |
| CVE-2001-1388 | iptables before 1.2.4 does not accurately convert rate limits that are specified on the command line, which could allow attackers or users to generate more or less traffic than intended by the administrator. |
| CVE-2001-1387 | iptables-save in iptables before 1.2.4 records the "--reject-with icmp-host-prohibited" rule as "--reject-with tcp-reset," which causes iptables to generate different responses than specified by the administrator, possibly leading to an information leak. |
| CVE-2001-0405 | ip_conntrack_ftp in the IPTables firewall for Linux 2.4 allows remote attackers to bypass access restrictions for an FTP server via a PORT command that lists an arbitrary IP address and port number, which is added to the RELATED table and allowed by the firewall. |
|
You can also search by reference using the CVE Reference Maps.
For More Information: CVE Request Web Form (select “Other” from dropdown)
|
||
