Bug 1452347

This is the result from what I concluded from talking to our CC lab. At the very minimum, there should be two bugs (no telling if there would be more, but at this time, it seems like two as far as I can tell):
1. random number serial change to use JSS/NSS
2. memory overwrite of secure/private data (passwords, keys) after use.  This is especially important since we are going to do KRA encrypt/decrypt with HSM.  In addition to the kra as mentioned, we should identify all area and proceed to do memory wipe with random bits.

(In reply to Christina Fu from comment #2)
> This is the result from what I concluded from talking to our CC lab. At the
> very minimum, there should be two bugs (no telling if there would be more,
> but at this time, it seems like two as far as I can tell):
> 1. random number serial change to use JSS/NSS
> 2. memory overwrite of secure/private data (passwords, keys) after use. 
> This is especially important since we are going to do KRA encrypt/decrypt
> with HSM.  In addition to the kra as mentioned, we should identify all area
> and proceed to do memory wipe with random bits.

From today's meeting, for "2", the lab responded that we could just zero-out instead of writing random bits in case of memory overwrite.

one more thing:
On the CS side, we just need to make sure whatever is deemed as PII needs to be zeroed out in memory after use.

Checkin:

commit b42b58024b801e5c9874e11dfb52de2b45c3a285
Author: Jack Magne <jmagne>
Date:   Thu Oct 5 11:55:12 2017 -0700

    Fix: #2695 Replacing Random with SecureRandom.
    
    This is addressed by creating one centralized method to get
    the SecureRandom number generator in JssSubsytem, which alread exists.
    
    Another fix by edewata allowed us to be able to access the
    JssSubsystem from most other server code. Thus only one method
    required.
    
    In a future ticket we can centralize the method calls TO the secure
    random object to allows us to easily log when they are called.
    
    Added a centralized method to CryptoUtil, which can be used by java clients.
    
    Change-Id: I092a6c16b43ddc6bb33ff0b6084ece1f34285844

I tested this bug on 10.5.1-5.el7. 

As per Endi's suggestions, there should be two log events for RANDOM_GENERATION.

One for secure random generation and one for the nonce.

Here I saw two RANDOM_GENERATION events. But both of them are identical.


- [AuditEvent=RANDOM_GENERATION][SubjectID=caadmin][Outcome=Success][Info=Caller;;com.netscape.cms.servlet.cert.CertRequestDAO.reviewRequest(CertRequestDAO.java:151)+Size;;4] Random number generation

- [AuditEvent=RANDOM_GENERATION][SubjectID=caadmin][Outcome=Success][Info=Caller;;com.netscape.cms.servlet.cert.CertRequestDAO.reviewRequest(CertRequestDAO.java:151)+Size;;4] Random number generation

Marking this bug as FailedQA.

Amol,

Actually, the RANDOM_GENERATION event was added in this ticket:
https://pagure.io/dogtagpki/issue/2653

and there's already a separate bug for the above problem:
https://bugzilla.redhat.com/show_bug.cgi?id=1520517

For bug #1452347, the change from Random to SecureRandom was done in a number of places in comment #6, and due to the low-level nature of the changes it's rather difficult to determine the test scenarios for each of the changes and their expected results. I'd suggest that we only do sanity test only for this bug.

I tested this bug on the 10.5.1-5.el7 version. 

I able to see the RANDOM_GENERATION event while approving the certificate request.

Verifying this bug.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0925