FITUG e.V. Förderverein Informationstechnik und Gesellschaft

Why "carnivore" type systems can't be (entirely) open so

[Die Diskussion hierzu laeuft auf UKcrypto@chiark.greenend.org.uk ! ]

------- Forwarded message follows ------- Date sent: Tue, 30 Jan 2001 22:47:12 +0000 To: UKcrypto@chiark.greenend.org.uk From: Richard Clayton <richard@highwayman.com> Subject: Why "carnivore" type systems can't be (entirely) open source Send reply to: ukcrypto@chiark.greenend.org.uk

I was recently at the Home Office, playing my own small part in the consultation process on RIP Part I, Chapter I (interception) and what might be envisaged under S12.

The topic of open source came up... because there is considerable interest within the ISP industry in being able to inspect any code that is to be run within the secure boundaries of their systems.

There was some interest in my observation that although many parts of detection, packaging and delivery systems can be made open source, there are some parts that would be significantly compromised if this was done.

The relevant whitepaper on this is "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection" Thomas H. Ptacek & Timothy N. Newsham (Secure Networks, Inc.) January, 1998

http://secinf.net/info/ids/idspaper/idspaper.html

that's some 60+ pages long, there's a brief executive summary at

http://www.sans.org/newlook/resources/IDFAQ/fragments.htm

but I'll also summarise here... it's possible to send sequences of packets at either the IP or the TCP level that "overlap". If you are aware of how the receiving machine will interpret these packets (for example, knowing which bits set in their headers will ensure they are discarded as invalid) then you can fool anything but the most sophisticated sniffer programs into thinking that an interchange is benign when it is not.

This is relevant to a "carnivore" type machine that is looking out just the SMTP traffic containing strings such as, say, capodicapo@mafia.org because by suitable slicing up of packets the sniffer could be fooled into believing that no such sequence of characters had ever been present on the wire.

In fact it's relevant to any un-encrypted transfer if the "carnivore" is doing anything other than collecting the entirety of the interchange. Even if it does collect it all then there can be considerable complexity inherent in seeing what was actually said (there's some parallels here with 'chaffing & winnowing').

The bottom line message is that "sniffing" is not particularly simple to do when the traffic pattern is deliberately making it hard.... and this is all ignoring issues about performance, bandwidth etc etc

Lest it be thought that this overlapping packets idea is rather exotic, it should be noted that current "hacker" tools already contain this capability (they aren't so much worried about carnivore, as sneaking past Intrusion Detection Systems)!

Clearly, publishing the full source of a "carnivore" box would enable people to see what approach was taken to overlapping packets, and hence give a viable strategy (that fell short of encrypting SMTP sessions) for those who wished to avoid detection.

Thus the detection/logic cannot be open source.

However, it is still possible to build an open source general purpose sniffer for picking packets off the wire (where the ISP can meet their legal obligations by pre-filtering the packets by source or destination). Such a sniffer would collect "everything" .

The back-end packaging/delivery code (where the ISP may again wish to ensure that software accessing the open Internet for delivery purposes does not compromise their systems) can also be open source.

One merely adds the sensitive component as a pipe between the two to make its own (secret) decisions as to whether traffic is worth picking off and sending off to NTAC for further processing.

[[If you're thinking that perhaps that filtering should all be done in NTAC where it would be secure, then consider the bandwidth requirements of securely delivering the whole of a 2MB (in each direction) link to the other end of the country. Cost alone ensures that you filter locally when you can.]]

bcc'd to those at Home Office to whom I promised this info :)

Zurück