Inside the UK's Security Assessment of the Transmission Control Protocol report

Richard Chirgwin outlines the findings of the UK government's assessment of the security risks inherent in TCP.

The UK Government's Centre for the Protection of National Infrastructure has published a key paper which attempts a wide-ranging assessment of TCP security. TCP is, of course, one half of the ubiquitous TCP/IP, the protocol pairing that lies at the heart of Internet communications (see TCP’s place in the world, below).
The paper, Security Assessment of the Transmission Control Protocol, attempts something that's rarely been attempted before: it looks at the large suite of IETF RFCs on which the protocol is based, seeking to identify as many of the protocol's shortcomings as possible.
As a “first of its kind” document, the security assessment is worth understanding in some detail.
The paper, authored by Argentinian security researcher Fernando Gont, is a partner to an earlier study conducted by Gont into the IP protocol.
It makes the point that approaches to TCP security are often fragmented, leaving users at the mercy of individual vendors' implementations. In many cases, Gont writes, security problems are known and have solutions, but those solutions have not resulted in official IETF documents (RFCs). This limits the Internet community's ability to check compliance of particular TCP implementations (such as the software stacks built into operating systems and routers), since there is no reference against which a customer could check whether a vendor has addressed particular security issues.
TCP's role is to handle the setup of communications between specific end nodes in a computer network. The network itself uses IP (the Internet Protocol) to address and route packets between networks; TCP handles requests from applications to use the network – in other words, it provides the interface between the application and the IP layer.
While hugely detailed – the document runs to 130 pages – Gont's report still can't be considered “comprehensive”. Gont has assessed the contents of 18 TCP-associated RFCs, which does not cover the entirety of the protocol.
For those who don't want to read the entire document, here's an overview of some of the problems discovered by Gont.
Vulnerabilities in Headers
The first aspect of the TCP assessment is an examination of how the RFCs define the formatting and application of TCP's header fields, and how these impact security.
  • TCP's header fields include data defining the following:
  • Source and destination port numbers – used to identify the communication sessions generating packets;
  • Sequence and acknowledgment numbers – these are used to manage the ordering of packets sent between two hosts;
  • Data offset and control bits – the control bits handle a number of TCP operations such as congestion control, queue control, session interruption, and the end of a session;
  • Window size – this field notifies the size of the data in the packet;
  • Checksum – used to check the packet's integrity;
  • Urgent Pointer – this may be used to advise the receiving computer that it should give the packet priority in processing;
  • Options – optional features such as timestamping and window scaling are notified in this field; and
  • Padding – a series of zeroes inserted to ensure that the header ends at a 32-bit boundary.
Gont found problems with most aspects of the TCP header. Port numbering is a good example.
When an application initiates a communication, the port number is important. Since different applications can communicate simultaneously, the port number makes sure that an incoming packet is directed to the right application.
Port numbering is, however, an attack vector, since if an attacker can guess the port being used by a particular application, packets can be addressed to that port as the basis of an attack. To make it hard to guess which port a particular application is using, the TCP implementation has to implement a randomisation technique.
For example, while a Web server listens on port 80 (the port to which I address my request for a Web page), the user's machine will select a random port number. This will form a pair of source:destination ports – say, 49499 as the source port, 80 as the destination. The Web server will address data to me, using my source port.
Since my computer is listening for traffic on port 49499, it could be attacked by someone sending data to that port – if the attacker knows I always use port 49499 for Web traffic. This is why the strength of randomisation is important. However, a range of weaknesses reduce the effectiveness of port randomisation.
More important, however, is the predictability of destination ports. The only way that I can know which port to use to address Web servers is if they all listen for communications on the same port. Otherwise, if I addressed a Web server on the wrong port, it would fail to respond. Attacks on these ports (such as SYN floods, for example), are however well known and reasonably well-defended.
Most of the attacks identified by Gont (all the way through TCP) are denial-of-service. These do damage – but they don't involve data leakage from your organisation. However, he also identifies significant risks from data injection arising from issues such as port randomness.
The problem is that if an attacker can identify the connection ID (derived indirectly from randomised port numbers), the attacker can then send packets to the target system, and the target system will try handle those packets as legitimate.
Another source of security problems Gont identifies is that some data leakage that occurs through normal behaviour of TCP may be of value to attackers.
For example, there are various ways in which operating systems might leak data about system uptime to the outside world via TCP's timestamp field. Many systems reset timestamps to zero after reboot – allowing an attacker to infer that if a system has a very long uptime, it may not yet have the most recent security patches applied.
Another important information leakage enabled by TCP is operating system fingerprinting. Various implementation respond to packets sent to open ports in predictable ways, which might allow an attacker to determine whether an Internet-accessible machine is running Windows, Linux, OSX, or some other operating system. Clearly, the ability to identify both an operating system and infer whether or not it has the latest patches should be considered a vulnerability – and Gont provides advice for TCP implementers on how these might be addressed.
A number of other problems are identified in the Gont paper; the next step will be to see whether the publication forms the basis of concrete action in the Internet community.
An underlying question is “how did things get this way?”
Gont identifies part of the problem clearly in the paper; as noted earlier, while responses are developed to vulnerabilities, they are often implemented in products rather than being published as RFCs.
The other issue, however, is more fundamental to the Internet: it has continued to evolve as a web of trust, long after that trust became obsolete.
In the early Internet – long before the World Wide Web – Internet-connected computers were known to each other, not just as IP addresses, but on a more interpersonal level. That formed the basis of the Internet's trust-web, since the system administrator at one university, in establishing a connection to other universities, formed relationships with those other universities.
The Internet has far outgrown the original models, but its protocols still embed an assumption that other computers may be trusted. If the protocol (rather than the implementation) is still undefended, it's because that protocol is still working under the assumption that its features and capabilities will not be misused.
The pair of Internet protocols – TCP, the Transmission Control Protocol, and IP, the Internet Protocol – have become so ubiquitous that they're generally concatenated together as TCP/IP.
They have very different roles, however.
The Internet Protocol is designed for the interconnection of networks. Its design purpose is not to interconnect individual machines.
On one side, the Internet protocol takes packets from your network, identifies the next hop in those packets' route to their destination, and pass the packets to that next hope. And for incoming data, it accepts packets from other networks, and passes them to your network.
When we're talking about the behaviour of applications that communicate over the network, we're talking about the role of TCP. It's TCP that the applications talk to, in the form of a “stack” running as a driver or process on the end device (a PC, laptop, or any other Internet-capable device).
When an application wants to communicate, it passes its data to TCP, and TCP begins the long chain of communications that culminates with a connection to another computer. But it doesn't do so directly; rather, TCP prepares its packets and hands them to the Internet Protocol layer to pass over the network.
TCP is not used for all application-network communications. Because it is concerned with high reliability, TCP will delay packets or slow down its network communications rather than drop them. For time-sensitive applications, TCP's sibling, UDP, provides less reliability, but drops packets rather than delaying them.



Read more on Data centre networking