<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 29, 2017 at 5:31 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 09/29/2017 06:19 AM, Luke Hinds wrote:<span class="gmail-"><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Thu, Sep 28, 2017 at 8:38 PM, McClymont Jr, Scott <<a href="mailto:scott.mcclymont@verizonwireless.com" target="_blank">scott.mcclymont@verizonwirele<wbr>ss.com</a> <mailto:<a href="mailto:scott.mcclymont@verizonwireless.com" target="_blank">scott.mcclymont@verizo<wbr>nwireless.com</a>>> wrote:<br>
<br>
    Hey All,<br>
<br>
    I've got a spec up for a change I want to implement in Glance for<br>
    Queens to enhance the current checksum (md5) functionality with a<br>
    stronger hash algorithm. I'm going to do this in such a way that it<br>
    is easily altered in the future for new algorithms as they are<br>
    released.  I'd appreciate it if someone on the security team could<br>
    look it over and comment. Thanks.<br>
<br>
    Review: <a href="https://review.openstack.org/#/c/507568/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/507568/</a><br>
    <<a href="https://review.openstack.org/#/c/507568/" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>#/c/507568/</a>><br>
<br>
<br>
+1 , thanks for undertaking this work. Strong support from the security projects side.<br>
<br>
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.<br>
</blockquote>
<br></span>
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.<br>
<br>
That checksum number never changes since Glance images are immutable once uploaded.<br>
<br>
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?<br></blockquote><div><br></div><div><br></div><div>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. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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.<br></blockquote><div><br></div><div>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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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]<br>
<br>
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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Best,<br>
-jay<br>
<br>
[1] <a href="https://github.com/openstack/nova/blob/master/nova/utils.py#L1067" rel="noreferrer" target="_blank">https://github.com/openstack/n<wbr>ova/blob/master/nova/utils.py#<wbr>L1067</a><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><span style="font-size:12.8px">Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat</span><br style="font-size:12.8px"><span style="font-size:12.8px">e: </span><a href="mailto:lhinds@redhat.com" style="color:rgb(17,85,204);font-size:12.8px" target="_blank">lhinds@redhat.com</a><span style="font-size:12.8px"> | irc: lhinds @freenode | m: </span>+44 77 45 63 98 84<span style="font-size:12.8px"> | t: </span>+44 12 52 36 2483<br style="font-size:12.8px"></div></div>
</div></div>