[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20150701161241.4E08636E002@smtpvbsrv1.mitre.org>
Date: Wed, 1 Jul 2015 12:12:41 -0400 (EDT)
From: cve-assign@...re.org
To: astieger@...e.de
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE Request: two security issues in openSSH 6.9
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> The openSSH 6.9 release contains the following changes declared as
> security issues:
We don't know whether the upstream vendor uses:
Security
--------
exclusively to mean that they are announcing vulnerability fixes, or
sometimes instead to mean that a change is otherwise related to
security.
> https://anongit.mindrot.org/openssh.git/commit/?h=V_6_9&id=1bf477d3cdf1a864646d59820878783d42357a1d
Use CVE-2015-5352 for the issue in which the refusal deadline was not
checked within the x11_open_helper function. (There's extra code to
make the x11_refuse_time value usable within two source-code files,
but adding that code doesn't seem to be related to any independent
problem.)
We didn't completely understand the rationale for moving "system(cmd)"
after the x11_refuse_time assignment, or whether this is addressing an
independent problem. It seems conceivable that there's a very slow
network connection to the X server, and an "xauth generate" may
therefore take a very long time. So, we think this might add a risk
that, by the time system(cmd) finishes, the refusal deadline has
already passed. If we're misunderstanding this or there's a
vulnerability fixed by moving the system(cmd) call, please let us
know.
> - if (x11_refuse_time != 0 && monotime() >= x11_refuse_time) {
> + if (x11_refuse_time != 0 && (u_int)monotime() >= x11_refuse_time) {
We're guessing that this isn't a vulnerability fix, and that the
author just somehow doesn't want x11_refuse_time to be a time_t.
> "fail open"
> behaviour in the X11 server when clients attempted connections with
> expired credentials.
The scope of CVE-2015-5352 does not include any fail-open
characteristics of an X server. There could possibly be a separate CVE
ID if there is an error that needs to be fixed in the X codebase.
> * ssh-agent(1): fix weakness of agent locking (ssh-add -x) to
> password guessing by implementing an increasing failure delay,
> storing a salted hash of the password rather than the password
> itself and using a timing-safe comparison function for verifying
> unlock attempts.
Our current thought is that a CVE ID may not be needed because attacks
against ssh-agent locking don't cross a privilege boundary. In other
words, the changelog entry could be interpreted to mean addition of a
new security feature related to a threat model that wasn't in the
previous design goals (e.g., password guessing by malware running
under the same account).
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJVlBB+AAoJEKllVAevmvms7U0IAJ/pkfdTyBGALMZ9cGuQ3drG
Y4k+4sD105NJ6skzjfGOrssX9fjgc0z/ZRo+E7oups8/FrZeKwAshVATh1kxkOPe
tCyFFSSIVohbNM1xIluSGLgtlXSTjM7useVL589YFyrO6sXrqYjh27fu616XDPPq
etQA+P07uj/AdPR+REWIyeX7Err9D9LEIB8kP42CYcHxblxZe5tfKixFeq6+q7bm
p/MDDckK374YoE7LXXPzF1e93CM2opAykI+W2J8W5IwL0I2C8vKO2eLUFZxkvVAH
IAV168RI5oAZnw7uwpI5evYuvM+VWwAJwWXtaPh+u054g4TuEWdw+Gi2tDb2j5o=
=kcq2
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
