You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@shiro.apache.org by "Lenny Primak (Jira)" <ji...@apache.org> on 2022/09/20 16:07:00 UTC

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

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

Lenny Primak commented on SHIRO-349:
------------------------------------

This needs to be back-ported to 1.9.x please

> 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 &amp; 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.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org