[Twisted-Python] Regarding the SHA 512 support in twisted.
Adi Roiban
adi at roiban.ro
Mon Mar 27 07:15:51 MDT 2017
On 27 March 2017 at 12:07, jabir Mohammed (jamohamm) <jamohamm at cisco.com> wrote:
>
> Its a security issue even you are allowing a weaker key in case of 64 bytes
> deriving only 40 bytes. Let me know how we issue a tracker bug can you
> please guide me. Since don’t want someone else to waist effort in debugging
> the same issue.
Hi Jabir and sorry for the previous misspelling!
There are a few existing bug reports for KEX related tasks...some are
server side, some are client side
https://twistedmatrix.com/trac/search?q=kex
I think that your bug was already reported (by my) at
https://twistedmatrix.com/trac/ticket/8258
---------
Regarding the help with this patch.
What have you tried so far?
Where are you stuck?
Where/ with what specifically do you need help?
Thanks!
>
> Thanks,
>
> Jabir
>
> \|/
>
> -------
>
> ( o o )
>
> oooO---O---Oooonull
>
>
> From: Alex Gaynor <alex.gaynor at gmail.com>
> Date: Monday, 27 March 2017 4:34 pm
> To: jabir mohammed <jamohamm at cisco.com>
> Cc: Itamar Turner-Trauring <itamar at itamarst.org>,
> "security at twistedmatrix.com" <security at twistedmatrix.com>, Twisted general
> discussion <twisted-python at twistedmatrix.com>,
> "twisted-python-bounces at twistedmatrix.com"
> <twisted-python-bounces at twistedmatrix.com>
> Subject: Re: Regarding the SHA 512 support in twisted.
>
> This is not a security issue, so this address isn't the right place for this
> discussion. Please use the public twisted issue tracker.
>
> Alex
>
> On Mon, Mar 27, 2017 at 5:33 AM, jabir Mohammed (jamohamm)
> <jamohamm at cisco.com> wrote:
>>
>> Hi Team,
>>
>> Wanted to bring one code changes which is really required from twisted
>> side otherwise it is not behaving as per RFC (rfc4253 Section 7.2), twisted
>> is failing when we negotiate any kex algorithm based on SHA1 and we have MAC
>> as hmac-sha2-512. The reason for the failure was the below code
>>
>> hashProcessor = _kex.getHashProcessor(self.kexAlg)
>> k1 = hashProcessor(sharedSecret + exchangeHash + c +
>> self.sessionID)
>> k1 = k1.digest()
>> k2 = hashProcessor(sharedSecret + exchangeHash + k1).digest()
>> return k1 + k2
>>
>> For SHA512 we need 64 byte key and if the Kex is based on SHA1 then it
>> will only generate 40 byte key and that induce a failure. So we need to
>> modify the code as below to make it generic and make it comply with RFC
>> (rfc4253 Section 7.2). So that twisted can work irrespective of what kex is
>> been used. Actual code should plot in is like below
>>
>> hashProcessor = _kex.getHashProcessor(self.kexAlg)
>> k1 = hashProcessor(sharedSecret + exchangeHash + c +
>> self.sessionID)
>> k1 = k1.digest()
>> k2 = hashProcessor(sharedSecret + exchangeHash + k1).digest()
>> k3 = hashProcessor(sharedSecret + exchangeHash + k1 + k2).digest()
>> k4 = hashProcessor(sharedSecret + exchangeHash + k1 + k2 + k3).digest()
>> return k1 + k2 + k3 + k4
>>
>> Can somebody help me to plot this fix so that twisted will work fine with
>> all the other servers out there and even make it comply to the RFC. Thanks
>> in advance and this will be my first findings on twisted code ;). Please let
>> me know in case of any doubt on the same. Code changes should be plotted in
>> to the routine _getKey, file name is src/twisted/conch/ssh/transport.py .
>> Please help me with this commit team.
>>
>>
>> Thanks,
>>
>> Jabir
>>
>> \|/
>>
>> -------
>>
>> ( o o )
>>
>> oooO---O---Oooonull
>>
>>
>> From: Alex Gaynor <alex.gaynor at gmail.com>
>> Date: Wednesday, 1 March 2017 9:26 am
>> To: jabir mohammed <jamohamm at cisco.com>
>> Cc: Itamar Turner-Trauring <itamar at itamarst.org>,
>> "security at twistedmatrix.com" <security at twistedmatrix.com>
>> Subject: Re: Regarding the SHA 512 support in twisted.
>>
>> This doesn't appear to be a security issue. You can file an issue on the
>> public tracker.
>>
>> Alex
>>
>> On Tue, Feb 28, 2017 at 10:54 PM, jabir Mohammed (jamohamm)
>> <jamohamm at cisco.com> wrote:
>>>
>>>
>>> Thanks Alex for the response. In our server we added support of
>>> HMAC-SHA-512 and HMAC-SHA-256 support for MAC. When we try to negotiate this
>>> hmac with most of the other client like Paramiko, OpenSSH and other flavours
>>> of SSH its working fine. But we are seeing a problem with twisted client
>>> that too only with HMAC-SHA-512. We have a limitation from our side to debug
>>> this since we don’t know what is happening from the client side. We have
>>> taken our derived key for the HMAC and as well as the input to derive the
>>> MAC using online tools and it matches with whatever we have generated but
>>> whatever is been sent across the other Twisted side differs and we are
>>> closing the session. This is been tagged critical since most of the
>>> customers are migrating to Twisted and will be a deployment blocker for us.
>>>
>>> What we suspect is the key or the algorithm itself. Please see the
>>> snippet below
>>>
>>> This is our inmac Key
>>> ----------------------------
>>> RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: ssh_integrity_check:
>>> inmac.key
>>> RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0000 - a5 cb a5 bb 4c
>>> 34 a7 bf-95 e9 00 23 1e 09 17 0c ....L4.....#....
>>> RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0010 - 1c e1 3f d9 a7
>>> 42 d9 87-54 23 64 16 e5 e2 c3 76 ..?..B..T#d....v
>>> RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0020 - 2a bc 53 c6 85
>>> 78 81 eb-e4 3e fb f7 cc a3 1f 6e *.S..x...>.....n
>>> RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0030 - d9 a5 0e 73 d0
>>> 44 79 a9-d3 19 32 3b 26 92 bb 70 ...s.Dy...2;&..p
>>>
>>> This is our input data to the hmac-sha-512
>>> -----------------------------------------------------
>>> RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: ssh_integrity_check:
>>> input.data to HMAC API
>>> RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0000 - 00 00 00 03 00
>>> 00 00 1c-0a 05 00 00 00 0c 73 73 ..............ss
>>> RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0010 - 68 2d 75 73 65
>>> 72 61 75-74 68 64 de 66 fb ab 31 h-userauthd.f..1
>>> RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0020 - ba 7e 56 e5
>>> .~V.
>>>
>>> The digest which is been sent from the twisted client side(Red)
>>> -----------------------------------------------------------------------
>>> RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: ssh_integrity_check:
>>> digest
>>> RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0000 - 95 f7 99 27 48
>>> 28 35 da-62 92 0e 51 0f af 62 b1 ...'H(5.b..Q..b.
>>> RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0010 - 93 d1 4d 46 5f
>>> d9 21 7a-b9 fb 86 b6 6e 00 a3 aa ..MF_.!z....n...
>>> RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0020 - 84 a9 58 60 5e
>>> 1c 86 98-b4 1f 00 40 d5 72 aa cf ..X`^...... at .r..
>>> RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0030 - 4b 1d 05 2d a4
>>> 68 96 9c-7b c7 9d 83 1d c2 1d 5b K..-.h..{……[
>>>
>>> The digest which got created from our side using the same key and input
>>> data mentioned above(Green)
>>> ———————————————————————————————————————————————————————————————
>>> RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0000 - 36 36 5c 6e 2d
>>> be f1 d8-ae 4f 5a 72 30 2d 25 c0 66\n-....OZr0-%.
>>> RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0010 - 0e e8 d6 96 6e
>>> 10 38 af-65 15 51 ff a7 ca 7d b4 ....n.8.e.Q...}.
>>> RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0020 - 7c c8 15 b8 5a
>>> 9b 5e c4-b5 ac 4c 51 7e de 77 41 |...Z.^...LQ~.wA
>>> RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0030 - 32 63 61 5e f5
>>> 1a 31 d1-f7 89 d0 0b 11 3c 48 f6 2ca^..1......<H.
>>>
>>> If you see the details this is the useauth first packet and we are not
>>> able to proceed because of the failure. We used online tool to do this
>>> calculation and we are getting the same output as what we generated so the
>>> one marked as red is creating problem.So the root cause could be either the
>>> key which is been derived or the algorithm so to debug that we need to
>>> enable details logging from client side. We can share the details with
>>> respective engineer and show what we are facing. Please help.
>>>
>>> Online tool which we used to check our algorithm is: which result in same
>>> MAC marked as green.
>>>
>>> https://www.liavaag.org/English/SHA-Generator/HMAC/
>>>
>>>
>>> Thanks,
>>>
>>> Jabir
>>>
>>> \|/
>>>
>>> -------
>>>
>>> ( o o )
>>>
>>> oooO---O---Oooonull
>>>
>>>
>>> From: Alex Gaynor <alex.gaynor at gmail.com>
>>> Date: Wednesday, 1 March 2017 6:39 am
>>> To: Itamar Turner-Trauring <itamar at itamarst.org>
>>> Cc: jabir mohammed <jamohamm at cisco.com>, "security at twistedmatrix.com"
>>> <security at twistedmatrix.com>
>>> Subject: Re: FW: Regarding the SHA 512 support in twisted.
>>>
>>> Hi,
>>>
>>> I think I'm missing some context here, what part of twisted are you
>>> trying to use SHA-512 for a MAC with? It sounds like Conch? Can you show how
>>> I could reproduce the problem?
>>>
>>> Alex
>>>
>>> On Tue, Feb 28, 2017 at 8:06 PM, Itamar Turner-Trauring
>>> <itamar at itamarst.org> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Forwarding on to security contact to see if they think it's a security
>>>> problem; otherwise you can probably just file a normal ticket.
>>>>
>>>>
>>>> On Tue, Feb 28, 2017, at 05:01 AM, jabir Mohammed (jamohamm) wrote:
>>>>
>>>> Hi Team,
>>>>
>>>>
>>>> Wanted to cross check on SHA 512 algorithm as MAC while using twisted.
>>>> Few of our customers started using Twisted and even we are trying to
>>>> incorporate some scripts via twisted client. But what we have noticed is
>>>> that when we negotiate SHA 512 MAC with twisted we always get a failure and
>>>> other MAC algorithms are working fine with twisted. So wanted to cross check
>>>> do we have any bug or any issue with SHA 512 and twisted and how we can
>>>> debug this from twisted side.
>>>>
>>>> We checked the same with other OpenSSH client and even paramiko things
>>>> work perfectly fine so wanted to debug further from the twisted side. We
>>>> checked with the same derived key and the output whatever we got from SHA
>>>> 512 is what we are getting from the online tool so we suspect something to
>>>> do with the key or hash algorithm from the other side.
>>>>
>>>> We used the twisted 16.6.0 version for testing, thanks in advance for
>>>> looking in to this email.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Jabir
>>>>
>>>> \|/
>>>>
>>>> -------
>>>>
>>>> ( o o )
>>>>
>>>> oooO---O---Oooonull
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Itamar Turner-Trauring
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> "I disapprove of what you say, but I will defend to the death your right
>>> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
>>> "The people's good is the highest law." -- Cicero
>>> GPG Key fingerprint: D1B3 ADC0 E023 8CA6
>>>
>>
>>
>>
>> --
>> "I disapprove of what you say, but I will defend to the death your right
>> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
>> "The people's good is the highest law." -- Cicero
>> GPG Key fingerprint: D1B3 ADC0 E023 8CA6
>>
>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: D1B3 ADC0 E023 8CA6
>
>
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>
--
Adi Roiban
More information about the Twisted-Python
mailing list