shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SHIRO-349) Security: Byte arrays (and other memory) holding sensitive data (even temporarily) should be zerod-out
Date Tue, 16 Aug 2016 01:39:20 GMT

    [ https://issues.apache.org/jira/browse/SHIRO-349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422016#comment-15422016
] 

ASF GitHub Bot commented on SHIRO-349:
--------------------------------------

GitHub user eric-cho opened a pull request:

    https://github.com/apache/shiro/pull/35

    SHIRO-349 Security: Byte arrays (and other memory) holding sensitive …

    …data (even temporarily) should be zerod-out

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/eric-cho/shiro SHIRO-349

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/shiro/pull/35.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #35
    
----
commit e2bde8de4b4aa82ddbaacbab88200ddc1e9a3248
Author: Taehun Cho <taehcho@cisco.com>
Date:   2016-08-16T01:37:18Z

    SHIRO-349 Security: Byte arrays (and other memory) holding sensitive data (even temporarily)
should be zerod-out

----


> 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
>             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 was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message