[
https://issues.apache.org/jira/browse/SHIRO-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15273938#comment-15273938
]
Richard Bradley commented on SHIRO-550:
---------------------------------------
> This is really really serious, should get a CVE and a security fix released
> ASAP.
+1
I understand that Open Source projects may or may not be actively maintained,
and that you use them at your own risk, but It seems to me to be simply
irresponsible to be distributing Apache Shiro when it has a known RCE attack in
its default configuration.
It seems to me that Shiro is not safe to use (in its default configuration)
while this bug is open and a deprecation warning should be put on the Shiro
homepage until this can be fixed.
I don't see this on Metasploit yet, but is that what is needed for this to get
any attention?
> 5 months and no fix.
The underlying bug, SHIRO-441, that the RememberMe key is hardcoded and
publicly available (and enabled by default) has been open since May 2013, so
I'd say this has been open for 3 years.
I've tried to cross-reference the recent committers in git with the mailing
list to see who is responsible for Shiro.
[~bdemers] -- do you have commit rights? Are you a Shiro maintainer? Do you
agree that this needs attention ASAP and that all Shiro users need to be
alerted that their webapps have an easy RCE attack hole wide open?
[~ankon] -- you have recent commits in
https://git-wip-us.apache.org/repos/asf?p=shiro.git , but it sounds from your
comments above that you are not a Shiro maintainer?
I'll email the dev list as well
> Pre-authentication deserialization vulnerability
> ------------------------------------------------
>
> Key: SHIRO-550
> URL: https://issues.apache.org/jira/browse/SHIRO-550
> Project: Shiro
> Issue Type: Bug
> Components: RememberMe
> Affects Versions: 1.2.4
> Reporter: Tim Stibbs
>
> The way shiro is set up by default exposes a web application to
> deserialization attacks. This is dangerous anyway, but particularly in light
> of the recent exploits using commons-collections (see
> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
> for more info).
> By default, shiro uses the {{CookieRememberMeManager}}. This serializes,
> encrypts and encodes the users identity for later retrieval. Therefore, when
> it receives a request from an unauthenticated user, it looks for their
> remembered identity by doing the following:
> * Retrieve the value of the {{rememberMe}} cookie
> * Base 64 decode
> * Decrypt using AES
> * Deserialize using java serialization ({{ObjectInputStream}}).
> However, the default encryption key is hardcoded, meaning anyone with access
> to the source code knows what the default encryption key is. So, an attacker
> can create a malicious object, serialize it, encode it, then send it as a
> cookie. Shiro will then decode and deserialize, meaning that your malicious
> object is now live on the server. With careful construction of the objects,
> they can be made to run some malicious code (see link above for more detail).
> Note this is not theoretical; I have a working exploit using the [ysoserial
> commons-collections4
> exploit|https://github.com/frohoff/ysoserial/blob/master/src/main/java/ysoserial/payloads/CommonsCollections2.java]
> and http client. I can provide my test code if required.
> I understand that this requires your shiro to be set up using the default
> remember me settings, but in my case my application doesn't even make use of
> the remember me functionality (there’s no way for the user to ask to be
> remembered), so I didn't even consider that I needed to secure this part.
> Yet, my application still has this vulnerability.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
