linux-kernel - Re: Security: information leaks in /proc enable keystroke recovery

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 16 Aug 2009 14:09:19 -0700 (PDT)
From:	David Wagner <daw@...berkeley.edu>
To:	rwatson@...eBSD.org (Robert Watson)
Cc:	oliver.pntr@...il.com (Oliver Pinter),
	daw@...berkeley.edu (David Wagner), freebsd-hackers@...eBSD.org,
	linux-kernel@...r.kernel.org
Subject: Re: Security: information leaks in /proc enable keystroke recovery

Thanks for the comments.

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

I agree we certainly shouldn't discuss the keystroke recovery attack
as hypothetical, because it is clearly not hypothetical: the authors
implemented it and found that it works.

> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/