Re: PATCH: Support for encrypted host keys

On Tue, Jan 31, 2012 at 13:39:09 -0600, Nico Kadel-Garcia wrote:
> On Tue, Jan 31, 2012 at 9:56 AM, Daniel Kahn Gillmor
> <dkg <at> fifthhorseman.net> wrote:
> > Hi Zev--
> >
> > On 01/28/2012 04:25 AM, Zev Weiss wrote:
> >> I recently found myself wanting to run sshd with passphrase-protected host keys rather than the usual
unencrypted format, and was somewhat surprised to discover that sshd did not support this. ?I'm not sure
if there's any particular reason for that, but I've developed the below patch (relative to current CVS at
time of writing) that implements this. ?It prompts for the passphrase when the daemon is started,
similarly to Apache's behavior with encrypted SSL certificates.
> >
> > Can i ask what threats you hope to mitigate with this approach? ?What
> > are your concerns about having a cleartext ~/.ssh/known_hosts?
> 
> One concern is pretending to be the designated host with host keys
> retrieved from backup or from sites that deploy identical hostkeys via
> a base installation or replicated OS image in virtualization. Since
> the sshd handles passwords in many environments, and there is no
> mechanism for revocation or expiration of host keys in
> $HOME/.ssh/known_hosts, the ability to pretend to be a previously
> accepted host with stolen keys has presented a functional security
> issue since SSH was first written.

With recent versions of OpenSSH, 5.4p1 and later, you can use host
certificates which can be expired or revoked. Also, regarding backups,
it is possible to exclude the private keys from being backed up. That is
only a partial solution and would mean that new keys would have to be
created if the old ones were lost.

Re: PATCH: Support for encrypted host keys

On Tue, Jan 31, 2012 at 7:53 PM, Iain Morgan <imorgan <at> nas.nasa.gov> wrote:
> On Tue, Jan 31, 2012 at 13:39:09 -0600, Nico Kadel-Garcia wrote:
>> On Tue, Jan 31, 2012 at 9:56 AM, Daniel Kahn Gillmor
>> <dkg <at> fifthhorseman.net> wrote:
>> > Hi Zev--
>> >
>> > On 01/28/2012 04:25 AM, Zev Weiss wrote:
>> >> I recently found myself wanting to run sshd with passphrase-protected host keys rather than the usual
unencrypted format, and was somewhat surprised to discover that sshd did not support this. ?I'm not sure
if there's any particular reason for that, but I've developed the below patch (relative to current CVS at
time of writing) that implements this. ?It prompts for the passphrase when the daemon is started,
similarly to Apache's behavior with encrypted SSL certificates.
>> >
>> > Can i ask what threats you hope to mitigate with this approach? ?What
>> > are your concerns about having a cleartext ~/.ssh/known_hosts?
>>
>> One concern is pretending to be the designated host with host keys
>> retrieved from backup or from sites that deploy identical hostkeys via
>> a base installation or replicated OS image in virtualization. Since
>> the sshd handles passwords in many environments, and there is no
>> mechanism for revocation or expiration of host keys in
>> $HOME/.ssh/known_hosts, the ability to pretend to be a previously
>> accepted host with stolen keys has presented a functional security
>> issue since SSH was first written.
>
> With recent versions of OpenSSH, 5.4p1 and later, you can use host
> certificates which can be expired or revoked. Also, regarding backups,
> it is possible to exclude the private keys from being backed up. That is
> only a partial solution and would mean that new keys would have to be
> created if the old ones were lost.

Potential memory leak in sshd [detected by melton]

Hi all,

After the memory leaks (bug 1967
<https://bugzilla.mindrot.org/show_bug.cgi?id=1967>) I reported in
bugzilla are fixed,

I also applied melton(http://lcs.ios.ac.cn/~xuzb/melton.html)

to detect the potential bugs in sshd (openssh-5.9p1).

The url below is the index of bug reports that are checked as real
bugs manually.

http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/index.html

Shall we fix these bugs? Or just let them go since they are not so serious?

Hope for your replies!

--

-- 
Zhenbo Xu

Re: Potential memory leak in sshd [detected by melton]

By the way, I submitted this report in bugzilla a few days ago, but there
is no response.
Should I report bugs in this mailing list rather than in bugzilla?

2012/2/4 Zhenbo Xu <zhenbo1987 <at> gmail.com>

> Hi all,
>
> After the memory leaks (bug 1967 <https://bugzilla.mindrot.org/show_bug.cgi?id=1967>) I reported
in bugzilla are fixed,
>
> I also applied melton(http://lcs.ios.ac.cn/~xuzb/melton.html)
>
> to detect the potential bugs in sshd (openssh-5.9p1).
>
>
> The url below is the index of bug reports that are checked as real bugs manually.
>
> http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/index.html
>
>
> Shall we fix these bugs? Or just let them go since they are not so serious?
>
> Hope for your replies!
>
>
> --
> Zhenbo Xu
>

Re: Potential memory leak in sshd [detected by melton]

ssh uses a unique process for each connection, and sshd forks for each new
connection, so the only memory leaks that are "in scope" are those that
apply to the master sshd.  I don't think that applies to any of these bugs.

Melton looks rather cool though.

On Fri, Feb 3, 2012 at 9:02 PM, Zhenbo Xu <zhenbo1987 <at> gmail.com> wrote:

> By the way, I submitted this report in bugzilla a few days ago, but there
> is no response.
> Should I report bugs in this mailing list rather than in bugzilla?
>
> 2012/2/4 Zhenbo Xu <zhenbo1987 <at> gmail.com>
>
> > Hi all,
> >
> > After the memory leaks (bug 1967 <
> https://bugzilla.mindrot.org/show_bug.cgi?id=1967>) I reported in
> bugzilla are fixed,
> >
> > I also applied melton(http://lcs.ios.ac.cn/~xuzb/melton.html)
> >
> > to detect the potential bugs in sshd (openssh-5.9p1).
> >
> >
> > The url below is the index of bug reports that are checked as real bugs
> manually.
> >
> >
> http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/index.html

Re: Potential memory leak in sshd [detected by melton]

What about this report
http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-uWzwb1.html#EndPath
?
At the end of the function server_accept_loop, fdset leaks. It means each
time the master sshd accept a new connection, it create a new space for
fdset but no free it. Or it is a false positive?

2012/2/4 Dan Kaminsky <dan <at> doxpara.com>

> ssh uses a unique process for each connection, and sshd forks for each new
> connection, so the only memory leaks that are "in scope" are those that
> apply to the master sshd.  I don't think that applies to any of these bugs.
>
> Melton looks rather cool though.
>
> On Fri, Feb 3, 2012 at 9:02 PM, Zhenbo Xu <zhenbo1987 <at> gmail.com> wrote:
>
>> By the way, I submitted this report in bugzilla a few days ago, but there
>> is no response.
>> Should I report bugs in this mailing list rather than in bugzilla?
>>
>> 2012/2/4 Zhenbo Xu <zhenbo1987 <at> gmail.com>
>>
>> > Hi all,
>> >
>> > After the memory leaks (bug 1967 <
>> https://bugzilla.mindrot.org/show_bug.cgi?id=1967>) I reported in
>> bugzilla are fixed,
>>
>> >

Re: Potential memory leak in sshd [detected by melton]

On 04/02/12 02:55, Zhenbo Xu wrote:
> The url below is the index of bug reports that are checked as real
> bugs manually.
>
> http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/index.html
>
>
> Shall we fix these bugs? Or just let them go since they are not so serious?
>
> Hope for your replies!
The third error
Logic error    Memory leak    monitor.i    13658    3
seems like a good catch.
There should be a call to buffer_free(&logmsg); before the return -1 of
monitor_read_log.

Although it only happens if the client closed the socket, in which case
the next poll of
line 13702 should fail and monitor_read_log never called again.
So it probably only leaks once.

Attaching fix.

--- monitor.c	2011-08-05 22:15:18.000000000 +0200
+++ monitor.c2	2012-02-05 22:01:06.000000000 +0100
@@ -508,6 +508,7 @@
 	    buffer_ptr(&logmsg), buffer_len(&logmsg)) != buffer_len(&logmsg)) {
 		if (errno == EPIPE) {

Re: Potential memory leak in sshd [detected by melton]

On 05/02/12 21:51, Ángel González wrote:
> The second leak
> 
> Logic error 	Memory leak 	session.i 	13193 	13 	View Report
> <http://lcs.ios.ac.cn/%7Exuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-zSMfqI.html#EndPath>
> 
> 
> http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-zSMfqI.html#EndPath
> 
> is a false positive.
> 
> The only way to exit the infinite loop is the return of line 13267.
> And line 13266 calls session_close(), which frees s->auth_data in line
> 14994.

The fifth one is a duplicate of this (same path, but the variable
allocated on next line).
12th one is the same issue of freeing at session_close not detected. But
this time with s->auth_display

Re: Potential memory leak in sshd [detected by melton]

On 04/02/12 02:55, Zhenbo Xu wrote:
> I also applied melton(http://lcs.ios.ac.cn/~xuzb/melton.html)
>
> to detect the potential bugs in sshd (openssh-5.9p1).
>
>
> The url below is the index of bug reports that are checked as real
> bugs manually.
>
> http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/index.html
>
>
> Shall we fix these bugs? Or just let them go since they are not so serious?
> Hope for your replies!

The second leak

Logic error 	Memory leak 	session.i 	13193 	13 	View Report
<http://lcs.ios.ac.cn/%7Exuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-zSMfqI.html#EndPath>

http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-zSMfqI.html#EndPath

is a false positive.

The only way to exit the infinite loop is the return of line 13267.
And line 13266 calls session_close(), which frees s->auth_data in line
14994.
(granted, it's tricky to follow...)

The analysis seem to have stopped in line 13193, after step 14.

Re: Potential memory leak in sshd [detected by melton]

On 05/02/12 06:54, Zhenbo Xu wrote:
> What about this report
> http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-uWzwb1.html#EndPath
> ?
> At the end of the function server_accept_loop, fdset leaks. It means each
> time the master sshd accept a new connection, it create a new space for
> fdset but no free it. Or it is a false positive?
No. Before allocating the fdset (line 14156), it frees the previous one
if present (line 14155).

There's a small leak of the last one when it exits the infinite loop. It
should probably free fdset on line 14330.

It seems an odd way, doing the free() + calloc() on every iteration.
Seems easier to do
if (fdset != NULL)
  bzero(fdset, ...);
else
  fdset = xcalloc(...);

maxfd can be decreased in line 14236, but that doesn't require the
xfree() + xcalloc() pattern.