Date: Sat, 04 Apr 2015 16:13:37 +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: <551FF191.2090109@selasky.org> In-Reply-To: <35F9F267-EDB3-45FC-95E0-4573556BD736@freebsd.org> References: <551F034A.3040402@selasky.org> <20150403213641.GM64665@glebius.int.ru> <551FA37B.90609@selasky.org> <35F9F267-EDB3-45FC-95E0-4573556BD736@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?551FF191.2090109>