Date: Sat, 04 Apr 2015 17:59:13 +0200 From: Hans Petter Selasky <hps@selasky.org> To: "Robert N. M. Watson" <rwatson@freebsd.org> Cc: "emeric.poupon@stormshield.eu >> Emeric POUPON" <emeric.poupon@stormshield.eu>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: Patch to reduce use of global IP ID value(s) to avoid leaking information Message-ID: <55200A51.3090008@selasky.org> In-Reply-To: <551FF191.2090109@selasky.org> References: <551F034A.3040402@selasky.org> <20150403213641.GM64665@glebius.int.ru> <551FA37B.90609@selasky.org> <35F9F267-EDB3-45FC-95E0-4573556BD736@freebsd.org> <551FF191.2090109@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04/04/15 16:13, Hans Petter Selasky wrote: > Hi Robert, > > On 04/04/15 14:54, Robert N. M. Watson wrote: >> Covert and side channels are inherent to the design of >> contemporary processors and operating systems -- via caches, >> memory bandwidth, OS scheduling, statistics, clock drift due to >> temperature, protocol counters, rate limiters, etc. The inherent >> difficulty of addressing malicious information-leak mechanisms >> means that our time is far better invested in trying to document >> and mitigate side channels than covert channels, whose existence >> must be taken for granted. And it's not just the IP ID field: >> almost any practical firewall configuration will be susceptible >> to lots of leaks of this sort. For example, rate limiting ICMP >> replies, TCP RST packets, etc, are all potential covert >> channels. And that is before you start letting through >> application-level protocols like DNS. >> >> Instead, we simply need warning that the fundamental function of >> a firewall -- of communication as much as blocking or it would be >> a dual-homed host not a firewall -- makes it susceptible to >> covert channels by design. Firewalls are about limiting overt >> communication -- if you want to limit covert communication you >> need very different hardware and software designs. > > I don't disagree that we can totally eliminate covert and side channels. > It's like you say a part of digital life. There is however a big > difference providing a 1 bit per hour statistically proven _unicast_ > side channel having X percent error and a 199 bit per second digital > _broadcast_ side channel having 0 percent error under good conditions > into a firewall or router subsystem. And I think you should agree about > that. > > I was curious enough to Google this topic a bit and I found that NMAP > can provide information about hosts which use incremental IPID generation. > > * OpenBSD always randomize IP ID > http://www.securityfocus.com/columnists/361/2 > > * MacOSX - incremental ? > http://forums.macnn.com/90/mac-os-x/119605/mac-os-x-portscan-results/ > > * All Windows versions - incremental ? > http://serverfault.com/questions/258790/changing-tcp-ip-ipid-sequence-generation-algorithm-on-windows-server > > > There are several mentions of using IPID for fingerprinting systems, but > no mentions of using it as a communication channel, or for that sake > covertly storing 16-bits of information at a remote host. Given the > large number of IP addresses in use, several GBytes can be stored this way. > > I think we should take OpenBSD's example in this case. Also we should > think about performance so that this feature can be default on, and not > have problems like mutex congestion and so on like Emeric mentioned. > > --HPS Hi Robert, I think you confuse what I'm trying to explain to you from the responses I get. I'm not talking about putting data into the IP ID field or other IP fields, which then someone at the receiving end picks out and stores. This is well known. I'm talking about sampling the IP ID value you get in return from a PING response. A firewall typically has multiple ports. If pinging the gateway from any of these ports cause an increment of a shared IP ID value, then anyone that can ping the common firewall will see the IP ID updates the other parties are doing. This can be used for RX and TX communication. Can you confirm that you understand? I have a feeling we are talking about completely different ways of side channel communication. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55200A51.3090008>