[Pkg-openssl-devel] Valgrind patch leftovers

[Ernst-Udo Wallenborn]

Kurt Roeckx wrote:

> The "proof-of-concept" just shows that after a fork you should make sure that you reseed the RNG and that OpenSSL
> doesn't do this automaticly for you.  OpenSSL has some basic workaround for this by also mixing in the PID, but that's 
> cleary not enough.  You can hardly say that the PID has entropy.

Well I never said that. My point is: the openssl code has poor entropy after forks. There are two stopgap measures in place to at least make an attacker have to work a little to exploit that. Neither of them is really good, but having both in place is better than having just one of them. The openssl team put both stopgaps in. SuSE and RedHat and all their variants leave them in. Debian removes one of them, leading to repeating random number sequences if developers neglect to reseed the RNG after every fork. In my opinion, Debian should not expose developers to that kind of risk.

> There is nothing "expected" about this.  The difference is that without the valgrind patch it adds some information 
> that might or might not contain entropy.

Well the valgrind patch *did* surprise the ruby developers who *did* expect that a RNG which did not require seeding in the initial call would not suddenly start to require seeding after a fork. Surprising developers is something that library code in my opinion should not do.


> I guess with a 1 line change to the proof-of-concept code, you will see the same behavior without this valgrind patch. 
> That is clearing buf[] before the call to RAND_bytes(). 
> Kurt

You  have a point here. I totally agree that relying on uninitialized memory is just not good enough. There has to be a better way to do this.

Anyway, I still think you should reconsider the decision to leave the valgrind patch in.

Regards,
Ernst-Udo Wallenborn