Sockstress is an internal proof-of-concept program developed by the late Jack C. Louis at Outpost24. Louis discovered anomalies using Unicornscan to test and probe networks for corporate security which lead to the development of Sockstress. [1]
This program appears to cause excessive resource allocation on a service or operating system hosting a service listening on a TCP port. This falls into the category of denial of service attacks. [2]
Affected Systems
editThis attack is reported to affect any system running a listening TCP port, which includes mainstream operating systems such as Windows, Linux, OSX and BSD, but also appears to include operating systems that power embedded devices, such as Cisco's IOS router operating system.[3]
Mechanism
edit
In an interview by Brenno de Winter for De Beveiligingsupdate, the Sockstress authors explain that the program has two modes of action - a simple Netkill type attack where an attacker causes the TCP stack on the target machine to run out of memory or program space to accept incoming connections. The Netkill attack works by completing a very large number of series of 3 way TCP handshakes with the target machine, without actually keeping the connections open on the client machine.
The researchers claim that the they've potentiated this attack with what they call client side SYN Cookies, which they presented in power point slides at the 2008 Sec-T security conference, which enable them to store connection state in the packet that they send. This means that an attacking machine can generate a very large number of open connections with a target, and not need to keep state about them locally, should it wish to reuse the connections later to deliver a payload to the target.
Their argument is that denial of service attacks are essentially resource allocation attacks, with the victor being the system that allocates the least resources over the period of the attack. By using client side SYN Cookies, the target machine is forced into allocating many more resources than the attacking system, allowing attackers to take on targets much larger than itself.
According to the interview, the researchers then realised that once a TCP connection is established, operating systems don't appear to do fastidious bounds or resource checking on the state of an established TCP connection, allowing them to apparently create packets that would allocate more resources on a target machine than should be allocated. This, combined with their client-side SYN cookies improvement, means that an attacking system or systems in a DDOS style attack could then send multiple exploit packets and not have to keep track of them, but cause massive resource allocation on the attacked machine. This is the second mode of the SockStress attack, and the one that was apparently demonstrated at the linked presentations.
The authors further claim in the above interview that resources that were particularly vulnerable were system memory and timers, particularly on Microsoft Windows machines.
Effects
editAssuming that the attacks listed above are valid, systems will follow the usual pattern of a service under severe stress. In practice this means that a normally running system to one that has a service consuming some critical resource bounded by how that resource was allocated to it by the system. If there are no bounds imposed on the service, then the service serving the connections could possibly consume all resources on a system.
In its simplest form, a service under the above type of attack will start rejecting incoming network connections if the incoming TCP queue buffer gets full from too many connections to a service.
If a connection manages to allocate resources temporarily or permanently on a host, then different outcomes can occur. In the case of system memory, if an attacker manages to allocate excessive system memory, swap space will start to be used, and the targeted system will use significant CPU time to move data from main memory to disk, entering a phase called thrashing, and depending on the type of Out of memory handling that the system runs, may end up killing other critical processes in an attempt to allow the system to recover.
If the attacker manages to allocate a vast number of system timers, then system CPU utilization could significantly increase as a result of the system having to constantly be interrupted to check a timer. If timers are allowed to get into a blocking or race condition state, then a reboot of the system may be the only way for a system to recover. According to the researchers, timers are particularly effective at using resources. This behavior was noted in the interview and demonstrations.
Validity
editDue to the apparent global nature of the problem, the researchers haven't released the code or binaries to the Sockstress program. They have apparently been in contact with vendors of affected systems so that they can have fixes for their code released. This casts some doubt on the vulnerability, since fundamentally, the demonstrations in September and October 2008, along with the content of the interview could have been fabricated.
A counter argument to this is that the validity of the exploit can be inferred from the warning output from large corporates like Cisco, or the Statement on Outpost24 TCP Issues from the Finnish National Computer Emergency Response Team.
Mitigation
editSince this attack relies on a successful 3-way TCP handshake being completed, the Cisco advisory notice states that systems administrators should only allow specific source address IP addresses to be allowed to connect to the management console of configurable routers and switches.
This type of mitigation tactic can only apply to systems with a whitelist of trusted users, something that isn't applicable to the public Internet.