The reason that we go to all this trouble to examine alternative sources of randomness other than CryptGetRandom() is that Microsoft has refused to publish the sources of randomness which are used. Therefore, we have no ability to know whether or not the randomness reported by Windows is in fact random.

The fundamental trouble with the ToolHelp32 and HKEY_PERFORMANCE_DATA when used in "Services" is that at the time the service is being loaded and this code may be executing we are unaware of what other services must first be loaded and initialized in order for them to work properly.
We never hear of problems for client applications. Nor do I ever see problems with this code in the Internet Kermit Service when loaded on NT/2000/2003 server. The IKS installs a small Windows Service which then spawns processes which execute RAND_poll(). My assumption is that those users who are having problems do not have the proper set of dependencies set. Therefore, RAND_poll() is executed when the necessary conditions are not quite met.

Of course, I have never had time to investigate this in detail. I wish I had the time.

I wish we had a function that could determine if we were running as a service. If so, we might be able to tailor this code to behave differently.

Jeffrey Altman


Richard Levitte - VMS Whacker wrote:

cardbox> As for the Windows 2003 Server crash: I agree that disabling
cardbox> sections of code is a Bad Thing. What I've done (pending more
cardbox> people researching the problem) is to put
cardbox> BOOL bMJKGotRandomness=FALSE;
cardbox> at the start of RAND_poll
cardbox> bMJKGotRandomness=TRUE;
cardbox> when either of the CryptGenRandom calls succeeds. Then cardbox> if (kernel)
cardbox> can become
cardbox> if (!bMJKGotRandomness && kernel)
cardbox> cardbox> ... which seems a reasonably conservative way round the
cardbox> problem. [The variable name isn't vanity, it's just that I
cardbox> want to be able to recognise my own code so I know what
cardbox> patches to re-apply to later releases of OpenSSL].

OK, I'll look at that later today.

cardbox> For those who are trying to reproduce the bug: I wonder if
cardbox> perhaps MS have decided that ToolHelp is too powerful to be
cardbox> safe and have started requiring that you have some sort of
cardbox> special permissions to access it. This is just a thought in
cardbox> case the bug turns out to be hard to reproduce.

Hmm, again, I think "don't say it..." applies again.  The gods may
have a wry sense of humor today, and you may get what you wish for
(regardless of whether you actually do or don't).

*sacrifices a rubber ducky on a VAX altar*

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature



Reply via email to