full-disclosure - Re: OpenSSL, OpenSSH ecdsa authentication code inconsistent return values.. no vulnerability?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5232FE49.50507@0xbadc0de.be>
Date: Fri, 13 Sep 2013 14:00:09 +0200
From: Aris Adamantiadis <aris@...adc0de.be>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: OpenSSL,
 OpenSSH ecdsa authentication code inconsistent return values.. no
 vulnerability?

Hi,

The curve is not user-supplied in SSH. The curve is defined by whatever
is selected during the key exchange process, and the only possible
alternatives are nistp256, nistp384 and nistp521, therefore users can't
send points in weak curves.

Since in openssh all groups are initialized from their names, comparing
the length of a group point is valid and much faster than comparing the
groups themselves.

Aris

Le 13/09/13 08:56, king cope a écrit :
> Georgi thanks for the pointer, though I guess points that are not on
> the curve will be rejected in the case the curve is not user supplied.
> If the curve is user supplied the authentication might succeed if this
> case is not catched before.
> Great work Georgi, always wanted to thank you ;-)
> 
> 2013/9/13 Georgi Guninski <guninski@...inski.com>:
>> Didn't quite understood the checks, but here is an idea:
>>
>> If you can make a user supplied point NOT ON THE curve
>> to be accepted as valid, this might break the other private
>> key (basically it is working on another curve, leaking info
>> about the private key).
>>
>> There is a document describing the exact attack,
>> if you can do this check for a start:
>>
>> http://crypto.stackexchange.com/questions/3820/why-do-public-keys-need-to-be-validated
>>
>>
>> On Fri, Sep 13, 2013 at 08:11:47AM +0200, king cope wrote:
>>> Hello lists,
>>>
>>> Attached is the blog post for the mentioned issues that in its shape
>>> are not a vulnerability, still interesting to see.
>>>
>>> http://kingcope.wordpress.com/2013/09/13/opensslopenssh-ecdsa-authentication-code-inconsistent-return-values-no-vulnerability/
>>>
>>> Cheers,
>>>
>>> Kingcope
>>>
>>> _______________________________________________
>>> Full-Disclosure - We believe in it.
>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> Hosted and sponsored by Secunia - http://secunia.com/
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> 

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/