shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Les Hazlewood (JIRA)" <>
Subject [jira] [Updated] (SHIRO-349) Security: Byte arrays (and other memory) holding sensitive data (even temporarily) should be zerod-out
Date Sat, 04 May 2013 21:48:15 GMT


Les Hazlewood updated SHIRO-349:

    Fix Version/s: 2.0.0

Because of the API changes this could require, I'm assigning this to 2.x (we'll start work
on 2.x asap)
> Security: Byte arrays (and other memory) holding sensitive data (even temporarily) should
be zerod-out
> ------------------------------------------------------------------------------------------------------
>                 Key: SHIRO-349
>                 URL:
>             Project: Shiro
>          Issue Type: Bug
>          Components: Authentication (log-in), Cryptography & Hashing
>    Affects Versions: 1.2.0
>            Reporter: James House
>            Priority: Critical
>             Fix For: 2.0.0
> 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
For more information on JIRA, see:

View raw message