This article is about a vulnerability found in Linux kernel versions since 3.6 that allows hackers to perform a side-channel attack. At a high level, a side-channel attack allows someone to passively monitor a system through indirect channels, hence side-channel. An example of this would be watching the power supply rate of a system to determine its work-load. In this case, an attacker is not actively watching the server but can still draw conclusions as to what it is used for. Another example of this would be determining the amount of time a machine sends a response packet or how long it took to process a packet. A feature of TCP is windowing. Professor Mackey described this during our last lecture when he described TCP connections to be secure in that they will confirm or deny a remote machine’s acceptance of packets. Linux kernels since 3.6 have a feature built in that forces the machine to send “ACK” (acknowledgement) packets to a remote server it is communicating with when it thinks it is receiving bad packets. It’s basically Linux’s way of saying, ‘hey, these packets don’t look correct, can you confirm?’. In theory, this is a good thing in that it prevents attacks such as man in the middle. What hackers have found though is that they can force a Linux machine to send ACK packets by sending “spoof” (fake packets) once a connection has been made. The hacker will then watch the number of ACK packets sent out. If the number of ACK packets the hacker receives is less than the number of allowed ACK packets, the hacker knows there is a valid connection between the server and a client somewhere. The math for the next part is rather complex but it is possible to determine the TCP 32 bit sequence numbers for that specific connection and inject malicious packets into the valid connection (This video describes how this is done when RSA encryption methods are used: //www.youtube.com/watch?v=AZkDGaISXq8). This article greatly illustrates how hackers use TCP/IP to gain entry to or disrupt systems.
http://www.theregister.co.uk/2016/08/10/linux_tor_users_open_corrupted_communications/
If I used the word “secure” I was incorrect. The CRC check only verifies that the packet received was the packet sent. No determination can be made as to whether or not someone made a copy.
Wade