I don't if it's related to this package ----------------------------------------------------- Description: A vulnerability was reported in some IPSec configurations. A remote user with the ability to modify the encrypted packets during transmission may be able to obtain the original plain text. Systems that use IPsec Encapsulating Security Payload (ESP) in tunnel mode with only confidentiality are affected. Some systems that use Authentication Header (AH) for integrity protection are also vulnerable. A remote user can modify sections of an IPsec packet to cause the ciphertext portion to be decrypted by a legitimate gateway and then redirected to an alternate host by the destination's security gateway. A remote user can also modify sections of an IPsec packet to cause a network host to issue an ICMP error message, which may contain portions of plaintext packet header and payload. In particular, a remote user can flip certain bits to modify the portion of the encrypted packet that contains the destination IP address of the payload (i.e., the inner packet). Then, when the destination security gateway decrypts the packet, it will be routed to the modified IP address. The IP Options field can also be modified in a similar fashion, which may result in the destination gateway generating an ICMP "parameter problem" message and including the affected plaintext packet within the ICMP message and sending the ICMP message to a modified address. The Protocol field can also be modified in a similar fashion, resulting in an ICMP "protocol unreachable" message. [Editor's note: A list of affected vendors and products was not available at the time of this original entry.] The UK National Infrastructure Security Co-ordination Centre (NISCC) reported this vulnerability. The original advisory is available at: http://www.uniras.gov.uk/niscc/docs/al-20050509-00386.html?lang=en Impact: A remote user with the ability to modify the encrypted packets during transmission may be able to cause the original plain text to be rerouted to an alternate destination. Solution: No solution was available at the time of this entry. As a workaround, NISCC reports that any of the following methods can be used: 1. Configure ESP to use both confidentiality and integrity protection. This is the recommended solution. 2. Use the AH protocol alongside ESP to provide integrity protection. However, this must be done carefully: for example, the configuration where AH in transport mode is applied end-to-end and tunnelled inside ESP is still vulnerable. 3. Remove the error reporting by restricting the generation of ICMP messages or by filtering these messages at a firewall or security gateway.
Plasmaroo/Latexer please advise.
Well, while this announcement does disclose a possibility of exploit, there are no new releases that change anything, the announcement really only states configuration options that should be used to avoid any compromise in the ipsec stuff. Do we do GLSAs for "FYI, doing things this way makes things safer" type situations?
Quote from http://www.gentoo.org/security/en/coordinator_guide.xml: "Default config bugs do not generate GLSAs." So, i guess no - but i'm not sure.
I'm no expert, but RFC 2406 says: Confidentiality may be selected independent of all other services. However, use of confidentiality without integrity/authentication (either in ESP or separately in AH) may subject traffic to certain forms of active attacks that could undermine the confidentiality service (see [Bel96]). Seems like this is not a vulnerability but design?
If it is by design, maybe we should patch our config file or put an ewarn in our ebuild to help people configure things securely. Moving to Default Configs.
latexer please advise.
As we don't even provide any config in /etc/racoon and people have to do their own configuration, and the advisory as largely a more detailed explanation of possibile exploits of a known bad configuration, I'd suggest this is a noop, and doesn't warrant a GLSA.
Closing as INVALDID, feel free to reopen if you disagree.
