| Article No° | Product Name | Affected Version(s) |
|---|---|---|
| 1357872 | FL MGUARD 2102 | <= 10.1.1 |
| 1441187 | FL MGUARD 4102 PCI | <= 10.1.1 |
| 1357842 | FL MGUARD 4102 PCIE | <= 10.1.1 |
| 1357840 | FL MGUARD 4302 | <= 10.1.1 |
| 2702547 | FL MGUARD CENTERPORT | <= 8.9.0 |
| 2702820 | FL MGUARD CENTERPORT VPN-1000 | <= 8.9.0 |
| 2702884 | FL MGUARD CORE TX | <= 8.9.0 |
| 2702831 | FL MGUARD CORE TX VPN | <= 8.9.0 |
| 2700967 | FL MGUARD DELTA TX/TX | <= 8.9.0 |
| 2700968 | FL MGUARD DELTA TX/TX VPN | <= 8.9.0 |
| 2700197 | FL MGUARD GT/GT | <= 8.9.0 |
| 2700198 | FL MGUARD GT/GT VPN | <= 8.9.0 |
| 2701274 | FL MGUARD PCI4000 | <= 8.9.0 |
| 2701275 | FL MGUARD PCI4000 VPN | <= 8.9.0 |
| 2701277 | FL MGUARD PCIE4000 | <= 8.9.0 |
| 2701278 | FL MGUARD PCIE4000 VPN | <= 8.9.0 |
| 2702139 | FL MGUARD RS2000 TX/TX-B | <= 8.9.0 |
| 2700642 | FL MGUARD RS2000 TX/TX VPN | <= 8.9.0 |
| 2701875 | FL MGUARD RS2005 TX VPN | <= 8.9.0 |
| 2702470 | FL MGUARD RS4000 TX/TX-M | <= 8.9.0 |
| 2702259 | FL MGUARD RS4000 TX/TX-P | <= 8.9.0 |
| 2700634 | FL MGUARD RS4000 TX/TX VPN | <= 8.9.0 |
| 2200515 | FL MGUARD RS4000 TX/TX VPN | <= 8.9.0 |
| 2701876 | FL MGUARD RS4004 TX/DTX | <= 8.9.0 |
| 2701877 | FL MGUARD RS4004 TX/DTX VPN | <= 8.9.0 |
| 2700640 | FL MGUARD SMART2 | <= 8.9.0 |
| 2700639 | FL MGUARD SMART2 VPN | <= 8.9.0 |
The FL MGUARD family of devices is affected by two vulnerabilities.
A timing based side channel exists in the OpenSSL RSA Decryption implementation which could be sufficient to recover a plaintext across a network in a Bleichenbacher style attack. To achieve a successful decryption an attacker would have to be able to send a very large number of trial messages for decryption. The vulnerability affects all RSA padding modes: PKCS#1 v1.5, RSA-OEAP and RSASVE. For example, in a TLS connection, RSA is commonly used by a client to send an encrypted pre-master secret to the server. An attacker that had observed a genuine connection between a client and a server could use this flaw to send trial messages to the server and record the time taken to process them. After a sufficiently large number of messages the attacker could recover the pre-master secret used for the original connection and thus be able to decrypt the application data sent over that connection.
Improper Input Validation vulnerability in PHOENIX CONTACT FL/TC MGUARD Family in multiple versions may allow UDP packets to bypass the filter rules and access the solely connected device behind the MGUARD which can be used for flooding attacks.
CVE-2022-4304: The OpenSSL library contains a bug that leads to a timing oracle when RSA based ciphers are used without forward secrecy for network communication. By sending a very large number of trial messages, an attacker can try to achieve a decryption of encrypted network packets. This affects TLS connections to and from the FL MGUARD as well as VPN connections. The highest risk arises from deferred attempts to decrypt pre-recorded network sessions. The throttling feature of the FL MGUARD can impede but not prevent the attack.
There is a risk that attackers could decrypt network traffic encrypted by the FL MGUARD device.
CVE-2023-2673: If a FL MGUARD or TC MGUARD device is operated in static or autodetect stealth mode, UDP packets which are directed to the protected device do not pass the configured MAC filter rules. The issue does not compromise the incoming IPv4 packet filter, which blocks all incoming traffic by default. The issue does not affect multi stealth mode.
There is a risk that attackers could send UDP packets to the protected device which should have been filtered out.
Mitigation
Remediation
The vulnerabilities are fixed in firmware versions 8.9.1 and 10.2.0. We strongly recommend all affected FL MGUARD users to upgrade to this or a later version.
CVE-2022-4304: This vulnerability was discovered by Hubert Kario and Dmitry Belyavsky (Red Hat). We kindly appreciate the coordinated disclosure of this vulnerability by the finder.
CVE-2023-2673: This vulnerability was discovered internally.
PHOENIX CONTACT thanks CERT@VDE for the coordination and support with this publication.