Mailing-List: contact dev-help@shiro.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@shiro.apache.org
Date: Fri, 6 May 2016 11:42:12 +0000 (UTC)
From: "Richard Bradley (JIRA)" <jira@apache.org>
To: dev@shiro.apache.org
Message-ID: <JIRA.12914414.1447928138000.127677.1462534932908@Atlassian.JIRA>
In-Reply-To: <JIRA.12914414.1447928138000@Atlassian.JIRA>
References: <JIRA.12914414.1447928138000@Atlassian.JIRA> <JIRA.12914414.1447928138667@arcas>
Subject: [jira] [Commented] (SHIRO-550) Pre-authentication deserialization
 vulnerability
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Fri, 06 May 2016 11:42:15 -0000


    [ https://issues.apache.org/jira/browse/SHIRO-550?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D15273=
938#comment-15273938 ]=20

Richard Bradley commented on SHIRO-550:
---------------------------------------

> This is really really serious, should get a CVE and a security fix releas=
ed ASAP.

+1=20
I understand that Open Source projects may or may not be actively maintaine=
d, 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 attac=
k 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 Shir=
o homepage until this can be fixed.=20
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 pub=
licly 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 a=
lerted 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=3Dshiro.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 deseriali=
zation 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-applic=
ation-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, whe=
n it receives a request from an unauthenticated user, it looks for their re=
membered 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 acc=
ess to the source code knows what the default encryption key is. So, an att=
acker can create a malicious object, serialize it, encode it, then send it =
as a cookie. Shiro will then decode and deserialize, meaning that your mali=
cious object is now live on the server. With careful construction of the ob=
jects, 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 [ysoseri=
al commons-collections4 exploit|https://github.com/frohoff/ysoserial/blob/m=
aster/src/main/java/ysoserial/payloads/CommonsCollections2.java] and http c=
lient. 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=E2=80=99s no way for the user to as=
k 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)