Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Rich Felker <dalias@libc.org>]

On Sat, Apr 18, 2015 at 06:27:48PM +0200, Harald Becker wrote:
> Hi !
> 
> @Rich: I still get DNS error (Mozilla Thunderbird) for
> dalias@libc.org, when tying to send mail :(

Odd. I just verified that Google's 8.8.8.8 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