Date: Sat, 18 Apr 2015 12:37:03 -0400 From: Rich Felker <dalias@...c.org> To: Harald Becker <ralda@....de> Cc: musl@...ts.openwall.com, Matt Johnston <matt@....asn.au> Subject: Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] On Sat, Apr 18, 2015 at 06:27:48PM +0200, Harald Becker wrote: > Hi ! > > @Rich: I still get DNS error (Mozilla Thunderbird) for > dalias@...c.org, when tying to send mail :( Odd. I just verified that Google's 220.127.116.11 resolves it right, so I don't know what's wrong, but it seems to be on your end. Let me know if you find anything that looks like a problem on my side. > On 18.04.2015 17:58, Rich Felker wrote: > >On Sat, Apr 18, 2015 at 05:49:51PM +0200, Harald Becker wrote: > >>On 18.04.2015 17:25, Rich Felker wrote: > >>>>The server hostkey will remain in process memory since it's > >>>>required for rekeying - not as bad as root code execution > >>>>though. > >>> > >>>Ugly. I don't see how this can be solved without a more advanced > >>>privsep model. I agree it's lower-severity though. > >> > >>IMO you may put the host keys in a file readable (not writable) > >>with a dropbear group, and only using that group for dropbear (no > >>other users or programs using that group). So you may read the keys > >>even if not root, if you add this dropbear group to setgroups (not > >>setgid) before dropping root privileges. > > > >The key is already in memory. > > As far as I understand it, the question was, *not to have* the key > hanging around in memory, but still have access without requirement to > keep root privileges. My suggestion is to solve this, with a very simple > and easy to implement solution. I consider it a slight increased > security, as the dropbear process can drop root privileges (and has to > do so), but still has access to the host keys. Well anything that gets code execution in the dropbear session process would be able to steal the key still. The only added protection you'd get is is against heartbleed-type attacks (arbitrary memory read but no code exeution). > >To make it more secure, the session process would not have any access > >to the key and would have to communicate with an existing privileged > >process to rekey. > > ACK, much better, but this would need major restructuring, wouldn't it? Yes. > So consider my suggestion a simpler to implement solution, in > between having full root privileges or hanging keys in memory, and > an external process to do the rekey steps (in addition: with the > possibility to let that process use the dropbear group and not root > to access keys - even better than let that process hang around as > root) If this external process is setuid/setgid, I consider that a much bigger vuln. It would have to somehow verify that it's being invoked by a valid dropbear session process and not some other caller that just wants to use it to steal keys/forge key negotiations, and you have all the usual issues with setuid programs having to be defensive about the state they inherit when invoked. If on the other hand the session process just kept gid=dropbear to open and reload the key, it wouldn't be so bad. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.