Slashdot Mirror
Messaging Over IPv6 Headers
elias miles writes "A guy from the Swiss Unix Users Group made a cool utility that lets you chat over IPv6 packet headers. Not useful, but it's a nice hack.
Read the article and download joe 6 pack."
← Back to Stories (view on slashdot.org)
This method of sending messages might seem stupid now, but in the long run a James Bond like spy might do something like this to save a life. Hmm, or maybe spies are such jocks that computer code alludes them. Any unorthodox method of sending a message is important, though.
that would be security through obscurity - which we all know can not be relied on.
The point of a covert channel is obscurity. You could add security on top of it, but putting the message into the data part would defeat the whole purpose of the covert channel. You are trying to find some way to get processes/machines/people to communicate within the confines of the operating system, and without anything/anybody else knowing about it.
An simple example? Say all the normal channels for process communication are blocked. No pipes, no sockets, etc. You can't use files. The only thing you can do is monitor the activity of the other process (ie the 'ps' command). By monitoring, say, memory allocation of the other process, two processes could communicate, sending the data byte by byte. Once a byte is sent, the receiving process could increment its memory to confirm. Then the sender increments its memory to send the next byte, etc.
The point of covert channels is that no matter how secure a system appears to be, it is possible for leaks because of things like this (probably more complex).
I'm not sure what the standard says about what this field should say. And even if it defines something, another question is what stacks will actually do with this field. Anyway - one way to stop this would be to zero this field on everything going out and comming into the firewall. The problem, of course, is that if this field actually serves a pourpose this will break the functionality. A way to detect and monitor this type of channel is to inspect that field on all the packets. If stacks are zeroing the field, then it should be easy to detect machines employing this technique. But as soon as a major vendor releases a stack that doesn't do that, this ceases to be a good detection method.
This all makes some big assumptions. How many admins will actually recognize this threat? How many will care? How many will take steps to mitigate it?
The thing I find fascinating is he invented and implemented this method without realizing what he was doing.
espo
As for point 4, you certainly have a point there, but with the MTU discovery in IPv6 (which prevents the (expensive!) fragmentation found in IPv4) you might actually see improvements there, too.