TCP Flaw Opens Linux Systems to Hijackers

A flaw in the RCP 2159 specification the Internet Engineering Task Force developed to protect TCP against blind in-window attacks could threaten Android smartphones, as well as every Linux computer on the planet.

The flaw is described in a paper a team of researchers presented at the 25th Usenix Security Symposium, ongoing in Austin, Texas, through Friday. The researchers are affiliated with the University of California at Riverside and the United States Army Research Laboratory.

The vulnerability, CVE-2016-5696, lets attackers hijack plaintext communications between two devices communicating over TCP on the Internet.

The RCP 2159 spec is implemented in Linux kernel v 3.6 and later.

"This attack could be used to target long-lived back-end connections like database sessions or management and monitoring channels," said Craig Young, a computer security researcher for Tripwire's Vulnerability and Exposures Research Team.

"Since only one host in the connection needs to be vulnerable, it's also possible that websites which provide interactive sessions over a persistent HTTP tunnel would be targeted," he told LinuxInsider.

Other targets are update servers used to replace firmware on embedded devices, and security cameras and smart appliances that maintain constant communications with a vendor's infrastructure.

Exploiting the Vulnerability

RFC 2159 was designed to make it more difficult to carry out TCP spoofing attacks against long-lived connections. The specification ensures that an incoming packet's sequence number exactly matches the sequence number expected to be next. Further, the attacker also would have to guess a proper ACK value within a scoped range.

Up to now, it was widely accepted that there was no easy way for attackers to know whether two arbitrary hosts on the Internet were communicating over TCP, or to tamper with or terminate such a connection, without being on the communication path themselves.

However, the researchers have found that it is possible to do so without running malicious code on either communicating party's system.

The ACK throttling feature, as implemented under RFC 2159, has a default limit of 100 challenge ACKS generated per second. That limit is shared across all channels, which lets the shared state be exploited as a side channel.

Attackers only have to send spoofed packets to a targeted connection, hit the 100 ACK per second limit, and count the actual number of challenge ACKs received on that connection. If the number is less than 100, some challenge ACKS must have been sent over the connection as responses to the spoofed packets.

Two likely scenarios are of greatest concern, said Josh Bressers, a security strategist at Red Hat.

One is through a plaintext connection and the second is a denial-of-service attack, he told LinuxInsider.

"The danger with potential vulnerabilities like this one is that many mobile devices and other embedded systems won't or can't be easily updated due to both design and connectivity issues," said Bill Weinberg, a senior director at The Linux Foundation.

"Of particular worry should be the installed base of Android devices," he told LinuxInsider.

Patching and Protection

Enterprise users will look to vendors like Red Hat for a patch, said Weinberg. Organizations and developers who build their own kernels "will obtain patches from kernel.org or major distribution supplier provides like Fedora."

Red Hat "is working on releasing a patch for this issue in our products, and are working with the relevant upstream communities to address this issue in their respective codebases," Bressers said.

In the meantime, the company's customers can use its kpatch dynamic kernel patching code to patch running systems.

The best defense is to eliminate the global challenge ACK count altogether, the researchers suggested, although it's possible the count could skyrocket.

Concerned users should think about possible ramifications before disrupting businesses to roll out patches, warned Adrian Sanaba, a senior security analyst at 451 Research.

"I've seen many cases where the attempt to mitigate a largely academic vulnerability results in more damage than simply accepting the narrow risk would," he told LinuxInsider. "I'm not saying that's the case here, but ... we need to study it more."