From: Matt Mackall <mpm@selenic.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Andrew Morton <akpm@osdl.org>, Andreas Steinmetz <ast@domdv.de>,
linux-kernel@vger.kernel.org
Subject: Re: [swsusp] encrypt suspend data for easy wiping
Date: Tue, 26 Jul 2005 16:53:14 -0700 [thread overview]
Message-ID: <20050726235314.GM12006@waste.org> (raw)
In-Reply-To: <20050726231249.GB29638@elf.ucw.cz>
On Wed, Jul 27, 2005 at 01:12:49AM +0200, Pavel Machek wrote:
> Hi!
>
> > > Well, "how long are my keys going to stay in swap after
> > > swsusp"... that's pretty scary.
> >
> > Either they're likely in RAM _anyway_ and are thus already trivially
> > accessible to the attacker (for things like dm_crypt or IPSEC or
> > ssh-agent), or the application took care to zero them out, or the
> > application has a security bug.
> >
> > There are about 4 attack cases, in order of likelihood:
> >
> > 1) An attacker steals your suspended laptop. He has access to all your
> > suspended data. This patch gets us exactly nothing.
>
> Wrong. Without this Andreas' patch, he'll get access to your
> half-a-year-old GPG passphrases, too.
Ok, I'll revise that to "very close to nothing". See below.
> > 2) An attacker breaks into your machine remotely while you're using
> > it. He has access to all your RAM, which if you're actually using it,
> > very likely including the same IPSEC, dm_crypt, and ssh-agent keys as
> > are saved on suspend. Further, he can trivially capture your
> > keystrokes and thus capture any keys you use from that point forward.
> > This patch gets us very close to nothing.
> >
> > 3) An attacker steals your unsuspended laptop. He has access to all
> > your RAM, which in all likelihood includes your IPSEC, dm_crypt, and
> > ssh-agent keys. Odds are good that he invokes swsusp by closing the
> > laptop. This patch gets us very close to nothing.
> >
> > 4) You suspend your laptop between typing your GPG key password and
> > hitting enter, thus leaving your password in memory when it would
> > otherwise be cleared. Then you resume your laptop and hit enter, thus
> > clearing the password from RAM but leaving it on the suspend
> > partition. Then an attacker steals your machine (without re-suspending
> > it!) and manages to recover the swsusp image which contains the
>
> Why without resuspending it? Position of critical data in swap is
> pretty much random.
Typical swap partition sizes are about the same as RAM sizes. So the
odds of any given thing in a previous suspend getting overwritten by
the next one are high.
> What I'm worried is: attacker steals your laptop after you were using
> swsusp for half a year. Now your swap partition contains random pieces
> of GPG keys you were using for last half a year. That's bad.
And it's incredibly unlikely. Suspending while a supposedly
short-lived key is in RAM should be rare. Surviving on disk after half
a year of swapping and suspending should be negligible probability.
It's not worth even thinking about when we have real suspended laptops
getting stolen every day in REAL LIFE. Anyone who cares about your
highly contrived case also cares about 1000 times more about the real
life case of the stolen laptop. Otherwise they're fooling themselves.
This code is bad. It attacks a very rare problem, gives its users (and
apparently its authors) a false sense of security, reimplements
dm_crypt functionality apparently without much attention to the
subtleties of block device encryption and without serious review, and
it stands in the way of doing things right.
If we're going to encrypt the suspend image, let's do it right. Let's
cover the real life cases and reuse code that's intended for this
purpose.
--
Mathematics is the supreme nostalgia of our time.
next prev parent reply other threads:[~2005-07-26 23:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-03 21:35 Pavel Machek
2005-07-06 9:02 ` Andrew Morton
2005-07-06 9:11 ` Pavel Machek
2005-07-06 12:49 ` Grzegorz Kulewski
2005-07-07 19:14 ` Pavel Machek
2005-07-07 19:30 ` Grzegorz Kulewski
2005-07-17 15:36 ` Andreas Steinmetz
2005-07-26 3:10 ` Andrew Morton
2005-07-26 22:04 ` Matt Mackall
2005-07-26 22:14 ` Pavel Machek
2005-07-26 22:58 ` Matt Mackall
2005-07-26 23:12 ` Pavel Machek
2005-07-26 23:53 ` Matt Mackall [this message]
2005-07-27 7:38 ` Pavel Machek
2005-07-27 14:22 ` Andreas Steinmetz
2005-07-26 22:26 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050726235314.GM12006@waste.org \
--to=mpm@selenic.com \
--cc=akpm@osdl.org \
--cc=ast@domdv.de \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®