Re: Security: information leaks in /proc enable keystroke recovery

Robert N. M. Watson
2009-08-16T23:25:11Z

On 16 Aug 2009, at 22:09, David Wagner wrote:

>> Beyond this, and assuming the correct implementation of the above,
>> we're into the grounds of classic trusted OS covert channel analysis,
>> against which no COTS UNIX OSes I'm aware of are hardened. This
>> isn't to
>> dismiss these attacks as purely hypothetical -- we've seen some
>> rather
>> compelling examples of covert channels being exploited in unexpected
>> and remarkably practical ways in the last few years (Steven Murdoch's
>> "Hot or Not" paper takes the cake in that regard, I think).
>
> To be pedantic, I'd say that the Usenix Security paper describes a
> side
> channel, not a covert channel. The paper shows how a malicious
> attacker
> can attack an unsuspecting victim application.
>
> Covert channels are when both the sender and the receiver are
> malicious
> and cooperating to transmit information from the sender to the
> receiver.
> In contrast, side channels arise when the "sender" is unintentionally
> and inadvertently leaking information that can be decoded by a
> malicious
> receiver, against the interests of the "sender". The attack in the
> paper is a side channel, not a covert channel. When it comes to
> covert
> channels, it is indeed reasonable to throw up your hands and say that
> defending against covert channels is basically impossible, so why
> bother?
> For side channels, though, it's less clear that this is a persuasive
> argument.

Hi David--

I see what you're saying, but I'm not sure I entirely agree on the
pedantic definitions front ("two can play at this game"). Historically
interesting definitions in DoD 5200.28-STD ("The Orange Book") and
NCSC-TG-030 ("A Guide to Understanding Covert Channel Analysis of
Trusted Systems") are decidedly hazy on the concept of intention, with
some portions specific on its involvement and others entirely
disregarding it. These definitions come out of trusted OS research/
development, and might be considered historically anachronistic by
some. To my mind, the OS timing issue we're discussing meet two of the
definitions of "covert channel" presented in NCSC-TG-030:

Definition 4: Covert channels are those that "use entities not
normally viewed as data objects to transfer information from one
subject to another."

Definition 5: Given a non-discretionary (e.g., mandatory) security
policy model M and its interpretation I(M) in an operating system, any
potential communication between two subjects I(Sh) and I(Si) of I(m)
is covert if and only if any communication between the corresponding
subject Sh and Si of the model M is illegal in M.

Which is to say: what makes something a "covert channel" is not the
intention to communicate in violation of a policy, but the
*possibility* of communication in violation of system design or
security policy. Both documents are concerned primarily with
intentional leakage/corruption of information in confidentiality and
integrity policies, but their definitions appear more general.

The use of the word "mandatory" here is certainly one that also bears
consideration: I would argue that the system integrity constraints of
historic UNIX, such as those on inter-process control vectors
(debugging, signals, ...) do in fact constitute a mandatory policy,
albeit not based on information flow control or a particularly clean
or well-documented model. As an example: unprivileged users are
permitted only limited scope under the discretionary access control
policy to delegate rights for objects they own. They can delegate to
another user write access to a file via open(2), but not the right to
chown the file using chown(2), signal a process using kill(2), etc,
making the protections that prevent these operations "mandatory".

I would argue that undesired information leakage via I/O timing across
process monitoring interfaces qualifies as a covert channel under both
definitions above: it's not an intended communication channel provided
by the OS design, and that the OS security policy is not intended to
allow unintentional communication of I/O data without explicit
delegation. The historic covert channel analysis of the timing
problem, drawn out in somewhat painful detail in NCSC-TG-030, seems
pretty much to apply to this problem.

I wouldn't argue that EIP leakage in procfs counted, on the other
hand, as it appears to be an intentional, if in retrospect
unfortunate, part of the design and policy. I wouldn't doubt that
countless other similar "oh, perhaps not" cases of information leakage
exist across countless variations on the UNIX theme due to monitoring
and debugging interfaces -- for example, netstat's reporting of TCP
pending send/receive queues seems likely subject to quite similar
problems, as with timestamps on device nodes in /dev, even network
interface or protocol statistics from netstat.

Coming down on the other side of pedantic, BTW, the Orange Book's
definition of "Covert storage channels" seems to ignore intention,
"Covert timing channels" seems to require it.

>> However, this next step up from "the kernel doesn't reveal
>> information on
>> processes from other users" involves scheduler hardening,
>> consideration
>> of inter-CPU/core/thread cache interactions, and so on -- things
>> that we
>> don't have a good research, let alone production, OS understanding
>> of.
>
> Indeed. A major challenge. Good to hear that, in its default
> configuration, FreeBSD does eliminate the attack vector described in
> the Usenix Security paper (the EIP/ESP leak). It seems a good
> starting
> point would be to limit access to information that we know can enable
> keystroke recovery -- as FreeBSD apparently already does, but Linux
> apparently does not.

NCSC-TG-030 has quite a bit to say on the topic of these sorts of
things, albeit addressed at a different context and in a different
time. I find myself skeptical that the sorts of protections we are
waving our hands at apply all that well to UNIX-like systems due to
their origin as time-sharing systems. However, I think a more
interesting place to direct this analysis would be the current flush
of hypervisors, which appear (possibly even claim) to offer much
stronger separation in a less time-sharesque way.

Robert