shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James House (Created) (JIRA)" <j...@apache.org>
Subject [jira] [Created] (SHIRO-349) Security: Byte arrays (and other memory) holding sensitive data (even temporarily) should be zerod-out
Date Fri, 09 Mar 2012 17:04:57 GMT
Security: Byte arrays (and other memory) holding sensitive data (even temporarily) should be
zerod-out
------------------------------------------------------------------------------------------------------

                 Key: SHIRO-349
                 URL: https://issues.apache.org/jira/browse/SHIRO-349
             Project: Shiro
          Issue Type: Bug
          Components: Authentication (log-in), Cryptography & Hashing
    Affects Versions: 1.2.0
            Reporter: James House
            Priority: Critical


Shiro provides features related to end-users interacting with sensitive information.  For
instance passwords, but also the cryptography features could be used for all sorts of sensitive
information, such as credit card numbers.  

Policy-driven environments require compliance with rules that include the requirement to use
FIPS 140.2 compliant JCA implementations, and that the application code that works with such
crypto libraries also take care to leave no sensitive data as artifacts in memory (vulnerable
to core dumps, etc.).  See PCI DSS, DoD Application Security STIG, etc..

A quick review raises flags about various points in Shiro code that handle sensitive data
and do not properly comply.  For example within JcaCipherService copies of data are made in
byte arrays which (which, base upon quick review) never get zeroed out (all of the bytes set
to 0x0 or some other meaningless values).  Also decryption results are returned via ByteSource.
  SimpleByteSource holds the byte[] of decrypted data but provides no way of clearing it.
 By coincidence, the internal representation is 'leaked' through the getBytes() implementation,
and the end user could clear the array themselves, but reliance on the internal representation
being passed out by all implmentations of ByteSource is rather risky.

Suggest a review of all points of encrypt/decrypt to ensure temporary (internal) copies of
data are always cleared, and suggest ByteSource have a new method added to the interface,
such as wipe() that the end user can call when they are finished with the ByteSource.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message