Re: CVS commit: src/crypto/external/bsd/netpgp/dist

[Adam Hoka <adam.hoka%gmail.com@localhost>]

On Sat, 9 May 2009 03:46:28 +0100
Alistair Crooks <agc%pkgsrc.org@localhost> wrote:

> On Fri, May 08, 2009 at 01:18:38PM -0400, Perry E. Metzger wrote:
> > 
> > "Alistair G. Crooks" <agc%netbsd.org@localhost> writes:
> > 
> > > Module Name:      src
> > > Committed By:     agc
> > > Date:             Fri May  8 06:06:39 UTC 2009
> > >
> > > Modified Files:
> > >   src/crypto/external/bsd/netpgp/dist: TODO configure configure.ac
> > >   src/crypto/external/bsd/netpgp/dist/src/bin: netpgp.c
> > >   src/crypto/external/bsd/netpgp/dist/src/lib: config.h config.h.in
> > >       crypto.c misc.c netpgp.c openssl_crypto.c reader.c signature.c
> > >       signature.h version.h
> > >
> > > Log Message:
> > [...]
> > > + if setrlimit exists, set the core dump size to be 0
> > >   (with thanks to mrg for the reference implementation)
> > [...]
> > 
> > What's the threat model this is protecting against? Presumably, if a
> > user can execute the program, and the program can read his keys, the
> > uesr can already read his own keys, so having a core dump doesn't give
> > the user information he didn't already have.
> 
> Heh, yeah, it's not really to do with keys, much more the passphrase,
> which is dynamically allocated in a number of places in the library,
> and I haven't finished auditing all of the places just yet.  I've
> added code to zero out that memory after use when I can - some more
> are still needed.
> 
> The threat that I'm protecting against here is that of information
> disclosure coming from committing the passphrase to disk in a core
> dump.  Having to remember to rm -P the core dump file is a pain, you
> don't get a second chance at it, and after that there is still the
> problem of any spared sectors.  I suspect you don't want a re-run of
> the tls vs.  agc wars from a month ago.  Whilst most people will use
> an encrypted block device of some description, others are prevented
> from doing that for various reasons.  I'm especially sensitive about
> passphrases here, since there's no way of changing a PGP passphrase
> short of generating a new key.
> 
> I'd really recommend source-changes-full for reviewing the changes
> that are made - the setrlimit(2) call is only made in the driver
> program, not the library.
> 
> Regards,
> Alistair

I recall reading a paper about storing sensitive data in shared memory
blocks, I just can seem to find it.

-- 
Adam Hoka <adam.hoka%gmail.com@localhost>