Syncookies are used to protect a system against certain Denial Of Service (DOS) attacks. A flaw in this mechanism has been found which can be used to circumvent certain types of firewall configurations. Note: syncookies are not enabled in the default installation of Red Hat Linux but many server administrators do enable syncookies.
Syncookies, while not enabled in default installations of Red Hat Linux, are used to protect an Internet server against a certain type of DoS attack--the so called "synflood"--by using a cryptographic challenge protocol which ensures legitimate users can keep using the server. Under an attack, the TCP/IP layer will, instead of just accepting new connections, send back the challenge and only accept the connections in the second phase ("syn ack") of the TCP/IP handshake (where the other party returns the challenge value). The DoS attack, which consists of sending as many first phase ("syn") packets as possible will be neutralized because system resources are only used as part of the second phase. Certain firewall configurations only filter the first phase ("syn") packets to prevent connections to specific services. These systems are vulnerable when an attacker can both force a system into flood protection state (by starting a synflood attack on a non-firewalled port) and guess the cryptographic challenge of a firewalled port. While the cryptographic hash used is strong, the number of bits available is restricted by the TCP protocol header design. With a high speed link and a lot of time, an attacker can eventually succeed in faking a valid cookie and making a connection that a syn only firewall rule might have prohibited. The updated kernels have a modified synflood protection algorithm that now uses a per port "under attack" state so that ports with only a first-phase firewall rule will not use the "under attack" regime even when other, non-firewalled, ports are under attack. In addition, these packages fix a remote denial of service attack against the TUX web server. This attack can only succeed if the TUX web server has been explicitly enabled; it is disabled by default. Thanks to Aidan O'Rawe for finding this bug.