[
https://issues.apache.org/jira/browse/SHIRO-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francois Papon resolved SHIRO-349.
----------------------------------
Resolution: Resolved
> 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
> Assignee: Francois Papon
> Priority: Critical
> Fix For: 2.0.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> 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 was sent by Atlassian Jira
(v8.3.4#803005)
