356595 - On Windows, RNG_SystemInfoForRNG calls GetCurrentProcess, which returns the constant (HANDLE)-1.

Status: RESOLVED FIXED

(NSS :: Libraries, defect)

Description

[Wan-Teh Chang]

On Windows, RNG_SystemInfoForRNG calls GetCurrentProcess to
get the current process's handle.  But this handle is a
pseudo handle and is a special constant, currently 0xffffffff,
or (HANDLE)-1.  There is no time-varying or machine-varying
bit in that value.

Comment 1

[Wan-Teh Chang]

Attachment: Proposed patch

It is possible to call DuplicateHandle on the pseudo process handle
to get the real process handle, but I am going to do a quick fix today.
I'm going to replace the GetCurrentProcess call with a GetCurrentThreadId
call.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

What "fix"?
It never hurts to input constant data into a PRNG.  
It doesn't lessen the PRNG's entropy any.
This can't be high priority.

Comment 3

[Wan-Teh Chang]

The GetCurrentProcess call is useless and it's easy to
replace it with a GetCurrentThreadId call, which returns
a time-varying (system global) thread id.  I can keep the
GetCurrentProcess call with a comment noting that it returns
a constant.  If you don't want me to add the GetCurrentThreadId
call on the NSS_3_11_BRANCH, I'll only add it to the NSS trunk.

Comment 4

[Wan-Teh Chang]

Attachment: Patch as checked in

I did not remove the GetCurrentProcess call.  I just
noted in the comment that it returns a constant pseudo
handle.

I only checked in the patch on the NSS trunk (NSS 3.12).

Checking in win_rand.c;
/cvsroot/mozilla/security/nss/lib/freebl/win_rand.c,v  <--  win_rand.c
new revision: 1.12; previous revision: 1.11
done

Comment 5

[Wan-Teh Chang]

GetCurrentProcess returns 0xffffffff, or (HANDLE) -1.
GetCurrentThread returns 0xfffffffe.  Both are pseudo
handles.