Over the years the Samba project has not only introduced and fixed its own unique bugs, as any complex software project generally does, but has also inherited bugs and shortcomings in the underlying protocol, given that its goal has always been to work seamlessly with Windows networks. Astonishingly, the CVE-2022-38023 vulnerability existed in the first place because both Windows and Samba still supported a style of integrity protection based on the long-deprecated hashing algorithm MD5. Simply put, network authentication using Microsofts version of the Kerberos protocol still allowed data to be integrity-protected using flawed cryptography. You shouldnt be using MD5 any more because its considered broken: a determined attacker can easily come up with two different inputs that end up with the same MD5 hash. As you probably already know one of the requirements of any hash that claims cryptographic quality is that this simply shouldnt be possible. In the jargon, two inputs that have the same hash is known as a collision, and there arent supposed to be any programmatic tricks or shortcuts to help you find one quickly. There should be no way to find a collision thats better than simple good luck - trying over and over again with ever-changing input files until you hit the jackpot. Assuming a reliable algorithm, with no exploitable weaknesses, youd expect that a hash with X bits of output would need about 2X-1 tries to find a second input that collided with the hash of an existing file. Even if all you wanted to do was to find any two inputs that just happened to have the same hash, youd expect to need slightly more than 2X/2 tries before you hit upon a collision. Any hashing algorithm that can be reliably be Cracked faster than that isnt cryptographically safe, because youve shown that its internal process for shredding-chopping-and-stirring-up the data thats fed into it doesnt produce a truly pseudorandom result at all. If there are 2X different possible hash outputs, youd hope to hit a 50:50 chance of finding an input with a specific, pre-determined hash after about half as many tries, and 2X/2 = 2X-1. Finding any two files that collide is easier, because every time you try a new input, you win if your new hash collides with any of the previous inputs youve already tried, because any pair of inputs is allowed. For a collision of the Any two files in this giant bucket will do sort, you hit the 50:50 chance of success at just slightly more than the square root of the number of possible hashes, and √2X = 2X/2. So, for a 128-bit hash such as MD5, youd expect, on average, to hash about 2127 blocks to match a specific output value, and 264 blocks to find any pair of colliding inputs. As it happens, you cant easily generate two completely different, unrelated, pseudorandom inputs that have the the same MD5 hash. You cant easily go backwards from an MD5 hash to uncover anything about the specific input that produced it, which is another cryptographic promise that a reliable hash needs to keep. If you start with two identical inputs and carefully insert a deliberately-calculated pair of Collision-building chunks at the same point in each input stream, you can reliably create MD5 collisions in seconds, even on a modest laptop. Using an MD5 research tool called md5 fastcoll, originally created by mathematician Marc Stevens as part of his Masters degree in cryptography back in 2007, we quickly produced two 128-byte MD5 collision-building chunks that we used to replace the comment text shown in the file above. They are visibly different in several bytes, and should therefore have completely different hash values, as the following a code diff reveals. MD5 is a 128-bit hash, as the output strings above make clear. As mentioned before, wed expect to need about 2128/2, or 264 tries on average in order to produce an MD5 collision of any sort. At an estimated peak MD5 hash rate of about 50,000,000 blocks/second on our laptop, that means wed have to wait more than 10,000 years, and although well-funded
This Cyber News was published on nakedsecurity.sophos.com. Publication date: Tue, 31 Jan 2023 11:36:02 +0000