Hide Forgot
This bug is created as a clone of upstream ticket: https://pagure.io/dogtagpki/issue/2695 Some parts of the current code are using Java's Random class to generate random numbers for various purposes. It should be changed into SecureRandom using CSPRNG. The main priority should be the random serial number (see https://github.com/dogtagpki/pki/blob/master/base/server/cmscore/src/com/netscape/cmscore/dbs/CertificateRepository.java). Note that other parts of the code are already using SecureRandom but not very consistently. Some do not specify the algorithm, some are using SHA1PRNG, and some others are using PK11SecureRandom. The current web application session ID is already generated using pkcs11prng (see https://github.com/dogtagpki/pki/blob/master/base/ca/tomcat8/conf/Catalina/localhost/ca.xml). <Valve className="com.netscape.cms.tomcat.SSLAuthenticatorWithFallback" alwaysUseSession="true" secureRandomProvider="Mozilla-JSS" secureRandomAlgorithm="pkcs11prng"/> See also ticket #2023 about Randomizing IVParameterSpec. See also http://stackoverflow.com/questions/15307127/using-seed-in-prng.
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