4 ms·

I had a great bug in libvirt fixed where two machines being deployed in an automated fashion generated the same MAC address for the virbr0. And at least one oth

I had a great bug in libvirt fixed where two machines being deployed in an automated fashion generated the same MAC address for the virbr0. And at least one other person had reported the same issue previously on a mailing list. Details from the bug I filed (https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1710341 https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/17103...): src/util/virrandom.c:virRandomOnceInit seeds the random number generator using this formula: unsigned int seed = time(NULL) ^ getpid(); This seems to be a popular method after a quick google but it's easy to see how this can be problematic. The time is only in seconds, and during boot of a relatively identical system these numbers are both likely to be relatively similar across multiple systems which is quite likely in cloud-like environments. Secondly, by using bitwise OR only a small difference is created and if the 1st or 2nd MSB of the pid or time are 0 then it would be easy to have colliding values. Though problematic from basic logic, I also tested this with a small test program trying 67,921 unique combinations of time() and pid() which produced only 5,693 random seeds using PID range 6799-6810 and time() range 1502484340 to 1502489999. During the actual incident in question, the 4 systems were all booted within 1-2 seconds of each other. We can see from dmesg that the two systems that generated the same MAC did in fact boot during the same second and the other two did not

pjc50 7y ago
Reminds me of mjg's recent attack on Bird: https://mjg59.dreamwidth.org/53258.html https://mjg59.dreamwidth.org/53258.html > Digging through the code revealed 8 bytes worth of key fairly quickly, but the other 8 bytes were less obvious. I finally figured out that 4 more bytes were the value of another Bluetooth variable which could be simply read out by a client. The final 4 bytes were more confusing, because all the evidence made no sense. It looked like it came from passing the scooter serial number to atoi(), which converts an ASCII representation of a number to an integer. But this seemed wrong, because atoi() stops at the first non-numeric value and the scooter serial numbers all started with a letter[2]. It turned out that I was overthinking it and for the vast majority of scooters in the fleet, this section of the key was always "0".
schoen 7y ago
A classic PRNG seeding problem from 1996: https://people.eecs.berkeley.edu/~daw/papers/ddj-netscape.html https://people.eecs.berkeley.edu/~daw/papers/ddj-netscape.ht... Netscape was using a related method for seeing the PRNG to the one you mention, which was still a small enough space of possible seed values that when the resulting values were using in cryptography, an attacker could brute-force the seed.

pjc50 7y ago

Reminds me of mjg's recent attack on Bird: https://mjg59.dreamwidth.org/53258.html https://mjg59.dreamwidth.org/53258.html > Digging through the code revealed 8 bytes worth of key fairly quickly, but the other 8 bytes were less obvious. I finally figured out that 4 more bytes were the value of another Bluetooth variable which could be simply read out by a client. The final 4 bytes were more confusing, because all the evidence made no sense. It looked like it came from passing the scooter serial number to atoi(), which converts an ASCII representation of a number to an integer. But this seemed wrong, because atoi() stops at the first non-numeric value and the scooter serial numbers all started with a letter[2]. It turned out that I was overthinking it and for the vast majority of scooters in the fleet, this section of the key was always "0".

schoen 7y ago

A classic PRNG seeding problem from 1996: https://people.eecs.berkeley.edu/~daw/papers/ddj-netscape.html https://people.eecs.berkeley.edu/~daw/papers/ddj-netscape.ht... Netscape was using a related method for seeing the PRNG to the one you mention, which was still a small enough space of possible seed values that when the resulting values were using in cryptography, an attacker could brute-force the seed.