RE: Covert Channels

From: Michal Zalewski (lcamtufat_private)
Date: Wed Oct 23 2002 - 15:00:58 PDT

  • Next message: Michal Zalewski: "Re: Covert Channels"

    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 --
    



    This archive was generated by hypermail 2b30 : Wed Oct 23 2002 - 15:08:30 PDT