Open Stack

On Fri, Sep 29, 2017 at 5:31 PM, Jay Pipes <jaypipes at gmail.com> wrote:

> On 09/29/2017 06:19 AM, Luke Hinds wrote:
>
>> On Thu, Sep 28, 2017 at 8:38 PM, McClymont Jr, Scott <
>> scott.mcclymont at verizonwireless.com <mailto:scott.mcclymont at verizo
>> nwireless.com>> wrote:
>>
>>     Hey All,
>>
>>     I've got a spec up for a change I want to implement in Glance for
>>     Queens to enhance the current checksum (md5) functionality with a
>>     stronger hash algorithm. I'm going to do this in such a way that it
>>     is easily altered in the future for new algorithms as they are
>>     released.  I'd appreciate it if someone on the security team could
>>     look it over and comment. Thanks.
>>
>>     Review: https://review.openstack.org/#/c/507568/
>>     <https://review.openstack.org/#/c/507568/>
>>
>>
>> +1 , thanks for undertaking this work. Strong support from the security
>> projects side.
>>
>> Would be good to see all projects move on from MD5 use now, its been
>> known to be insecure for sometime and clashes with FIPS-142 compliance.
>>
>
> In the case of Glance's use of MD5 for checksums, it is used to identify
> whether a particular array of bytes that represents an image has changed.
> The client uploads a bytestream to Glance, which does a rolling checksum of
> that byte data for each chunk received and writes the checksum to the
> database upon completion of the upload.
>
> That checksum number never changes since Glance images are immutable once
> uploaded.
>
> Can someone please inform me how changing the checksum algorithm for this
> operation to SHA-1 or something else would improve the security of this
> operation?
>


As I understand it, MD5 has been proven to be susceptible to collision
attacks, so its possible to generate the same hash from two blobs. The same
is also true for SHA-1, and can't be out ruled this may also be the case
for strong cryptos (SHA 256, 512 etc) in the future.


> As someone who recently had to go through thousands of (mostly bogus)
> entries in a spreadsheet generated from the Bandit "security scanning
> tool", I'd like to ask that we approach these kinds of things with some
> common sense and not just as a checking-the-box-off activity.
>

understood, you may already know this, but you can make a # nosec on the
line using hashlib.md5 and Bandit will not false positive. It might seem a
pain it reporting on md5, but it has highlighted a few occurrences of
people using weak hashes for salting , integrity checks etc.

>
> md5 is used in a number of places in many OpenStack services, and often
> those uses have nothing to do with cryptography. Rather, in those cases md5
> is used as a simple mechanism to generate a hash from a name. [1]
>
> All I ask is that we don't have an army of people going out and replacing
> blindly all uses of the MD5 algorithm everywhere, since (as I learned
> recently) that will just lead to a lot of busywork for little gain.
>

I do see you're point, some network protocols also use md5 purely for error
checking, not computing. In OpenStack swift uses MD5 for a non security
case, and its no simple swap out for them.

If anything it would be ideal to insure anyone implementing new
functionality, not use md5 and if anyone can easily swap out uses of md5 /
sha1 then its worth doing, as there may be an edge case not yet seen that
it opens up a hole.


>
> Best,
> -jay
>
> [1] https://github.com/openstack/nova/blob/master/nova/utils.py#L1067
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
e: lhinds at redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 | t: +44
12 52 36 2483
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170929/2ab32c30/attachment.html>