Source-Changes-D archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
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>
Home |
Main Index |
Thread Index |
Old Index