RE: Covert Channels

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

On 23 Oct 2002, Anton Aylward wrote:

> If you think of something like frequency-agile radio, we have the case
> of a covert channel where neither endpoint is "compromised" and the
> purpose of the technology in this case is to remain undetectable (by the
> channels being barely above background noise) and untappable (since
> something like a one-time pad is used to control channel switching).

Physical security is a different animal... On the software level, it's a
reasonable expectation that the system is not broadcasting the information
its processing, and, severe implementation problems aside [*], cases when
it happens (and needs to be detected on a nIDS level) are typically a
result of adverse user actions or a compromise. For physical security,
there's no such expectation, except for veeery specific applications, and
it's quite difficult to accomplish it without sacrificing other, more
important features (weight, price, performance, compatibility). As such,
I'm not sure it even deserves the name "covert channel" - it's a well
documented and known problem people are willing to live with, since the
alternative is not always feasible and the risk is fairly low. A good
security policy should take those things into account...


[*] Happened few times in the past; for example, Linux kernels used
    to leak some information about privileged processes to local users
    via /proc - registers could be read; and some un*x system used to
    truncate certain packets incorrectly, leaking some kernel memory,
    IIRC. But this is fairly rare.

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