DNSSEC?

Mark Andrews marka at isc.org
Fri Apr 11 23:39:56 UTC 2014


In message <534874D8.3050205 at direcpath.com>, Robert Drake writes:
> 
> On 4/11/2014 5:47 PM, Matt Palmer wrote:
> > That's not DNSSEC that's broken, then. - Matt 
> 
> You're correct about that, but everything depends on your level of 
> paranoia.
> 
> The bug has a potential to show 64k of memory that may or may not be a 
> part of the TLS/SSL connection*.  In that 64k their may be ssh keys, 
> dnssec keys, pictures of cats, or anything else that needs to be safely 
> protected.  If something is very important to keep secure and it was on 
> a box that has a TLS/SSL connection then you should regenerate keys for 
> it, but largely this effort would be just in case and not because it's 
> compromised.

That bug has the potential to show what is in them memory of the
process it is connecting to.  Note I said process not machine.  Now
unless you are using SSL to take to a process that is signing DNSSEC
keys there is no exposure of the private keys.

Named doesn't use ssl.  There are however nameservers that do use
ssl to work around broken middle boxes.  If they are also signing
zones then there is potential to expose private keys.  That said
it also depends on how the process manages the memory it frees.

Named for example overwrites freed memory with 0xde.  It also
initialises allocated memory with 0xbe.  Doing so help detect use
after free and use of uninitialised structure elements.  We want
to catch these sorts of bugs before they get to the internal review
stage.

> * technically it is part of the connection, it's just malloc() and not 
> zeroed so whatever data was in it before was not cleared.  If you can be 
> sure all your cat picture applications zero memory on exit and none of 
> them exited uncleanly then this isn't a problem. At high levels of 
> paranoia this isn't really something that you can be sure of though.  
> I'm not even sure if it's done in most crypto apps aside from gpg.  
> OpenSSL is double-faulted here for both not checking the length and not 
> zeroing the memory on malloc**.
> 
> ** probably making this all up since I haven't done a real look at the 
> library, I'm just going by what I've read on the internet.
> 
> I expect we may see more bugs revealed in openssl soon.  It's getting 
> lots of scrutiny from this so I expect the code is being audit by 
> everyone and that's good.

I also expect to see more bugs revealed in MacOS, Windows, FreeBSD and
any other program written by humans or written by programs written by
humans.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org




More information about the NANOG mailing list