@offseq Wow, the details are pretty wrong here.

The session ID generation relies on an MD5 hash seeded with the built-in rand() function, which is seeded with predictable 32-bit values derived from process ID, epoch time, and object reference address.

• Perl's built-in PRNG has a 48-bit internal state and is seeded with 48 bits, not 32 bits. Edit: See below. Perl internally seeds its PRNG with 32 bits from /dev/urandom.
• The code in WebDyne::Session does not seed the PRNG explicitly.
• The value passed to rand() is converted to a double-precision floating point value and acts as an upper bound on the generated number. It is not a seed.
• WebDyne::Session effectively generates this bound as (process_id * 10_000_000_000.0 + unix_time()) * 10. The object address plays no part in this calculation. (It tries to, but the code is buggy and always multiplies by 10 instead.)

This predictability makes the session IDs insecure and potentially guessable by attackers, risking unauthorized access.

Yes. The generated session IDs are effectively something like md5_hex("2.84319174058601e+16").

The vulnerability affects versions through 2. 075 and does not apply to versions 1. 042 and earlier, which are distributed separately.

Incorrect. The vulnerability affects all versions of WebDyne::Session. The only difference is that in versions before 2.0, the "multiply by 10" code wasn't there, so the upper bound on generated random numbers was process_id * 10_000_000_000.0 + unix_time(). Everything else (md5_hex(), rand(), etc) was exactly the same.

#perl #CPAN #cve