Re: Covert Channels

[Michal Zalewski <lcamtuf () dione ids pl>]

On Wed, 23 Oct 2002, Blue Boar wrote:

> Of course there are.  There are a huge number of POP3 clients out
> there..  some of which will fail when given a particular input, some of
> which will handle it with no trouble.

What do you mean? We're talking about the intrusion, not a failure to
handle a proper input. The sequence needed for exploitation is typically
either a nasty violation of a standard POP3 authentication sequence that
will work when it shouldn't, or sending excessively long lines, no
newlines, commands or responses containing things like '%n', etc. Even
when RFC does not disallow those practices, they can be filtered out with
a very low false positive ratio.

Even if it is not OK with the RFC, you can filter out pop3 commands longer
than, say, 32 characters, and be happy. Something longer does not
necessarily mean you've been compromised, but it means something is doing
something nasty that does not fit "normal traffic characteristics I'd
expect". Besides, to exploit such a buffer overflow, you'd most likely
have to send a suspicious shellcode data at some point - place it in a
mailbox earlier, or send it in one of the commands, which can be detected;
I doubt you can ret-into-libc to do system("/bin/sh") with alphanumeric
chars only. But... I'll give you a better example:

There was a bug in OpenSSH. When you disabled logins for accounts without
passwords (PermitEmptyPassword option), you couldn't log in to an account
like "toor::0:0:...". Well...  unless you actually typed some bogus
non-empty password, in which case, the daemon would let you in. Try to
detect that by checking for network-based protocol anomaly analysis -
quite difficult. Whoops.

I'm not trying to say you can't think of a scenario where this general
statement about the feasibility of detecting potential attacks or
anomalies with an acceptable false positive ratio does not hold true, but
it will be a very specific scenario, not a broad problem that applies to
every protocol and every check algorithm; and with covert channel
detection, it's a general issue.

> All I'm saying is that a covert channel detector can do as well as IDS'
> do today, which means basically catching some set of known stuff.

Yes, the difference I'm pointing out is that in majority of cases, attack
detection can be performed successfully, and there's no reason to think
there's a fundamental limitation to this process (other than the problem
of complexity of needed models), whereas detection of covert channels has
very serious limitations that, while not yet reached, may bite us soon,
rendering this practice pretty much pointless - you can make all
low-bandwith covert data exchange look simply legitimate, with some basic
knowledge about the environment your targeting.

-- 
------------------------- bash$ :(){ :|:&};: --
 Michal Zalewski * [http://lcamtuf.coredump.cx]
    Did you know that clones never use mirrors?
--------------------------- 2002-10-23 16:58 --