[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150418163702.GI6817@brightrain.aerifal.cx>
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 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
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.
