Bug 743006 (CVE-2011-3609)

Acknowledgements:

Red Hat would like to thank David Black for reporting this issue.

"Access-Control-Allow-Origin" depends on the browser and I don't think it make sense to use it. Probably filtering the URL in the application is the way  to go.

This report is a bit confusing. Here's what I make of it:

1) We're not protecting against CSRF. We need to fix that.
2) Setting Access-Control-Allow-Origin: * means that attempts to apply CSRF protection will probably fail. I don't see a good reason for us setting this header, can we just remove it altogether and not set it at all? Or does it serve some purpose I'm not aware of?
3) The PoC JS demonstrates that the management console's JSON interface is open. I don't think this demonstrates the problem with Access-Control-Allow-Origin: * or CSRF, although the reporter might intend it to. To me it just demonstrates that it's open by default.

I'm told that the console will require authentication in EAP 6. The take away message from this report is that we need to protect against CSRF.

Are you saying that the console isn't protected at all or the JSON interface?
I am speak of authorisation and cookies or URL encoded sessionid.

Again the ccess-Control-Allow-Origin: * is a new feature we should be carefull in using it.

David Jorm, my team-mate responsible for dealing with JBoss products flaws, has provided his summary of the flaw at:
https://bugzilla.redhat.com/show_bug.cgi?id=743006#c5 (made it to be a public comment)

Jean, let us know if the above is sufficient or if you would desire some further clarification.

Thanks, Jan.

[jfclere@jfcpc jboss-as-7.1.0.Alpha2-SNAPSHOT]$ bin/jboss-admin.sh -c --file=bin/scripts/secure-standalone-mgmt.cli
Connected to standalone controller at localhost:9999
#1 /core-service=management/security-realm=PropertiesMgmtSecurityRealm:validate-address
#2 /core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=PropertiesMgmtSecurityRealm)
#3 /core-service=management/management-interface=native-interface:write-attribute(name=security-realm,value=PropertiesMgmtSecurityRealm)
The batch executed successfully.
[jfclere@jfcpc jboss-as-7.1.0.Alpha2-SNAPSHOT]$ curl -v localhost:9990/management
* About to connect() to localhost port 9990 (#0)
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 9990 (#0)
> GET /management HTTP/1.1
> User-Agent: curl/7.21.3 (i386-redhat-linux-gnu) libcurl/7.21.3 NSS/3.12.10.0 zlib/1.2.5 libidn/1.19 libssh2/1.2.7
> Host: localhost:9990
> Accept: */*
> 
< HTTP/1.1 401 Unauthorized
< Content-length: 0
< Www-authenticate: Digest realm="PropertiesMgmtSecurityRealm",nonce="8cacd05d3d78d27bbe2eebab39465258"
< Date: Wed, 05 Oct 2011 08:44:14 GMT
< 
* Connection #0 to host localhost left intact
* Closing connection #0

I think you should secure and try again.

With authentication applied as per comment #8, I am unable to reproduce a CSRF attack, but I still think this is something we need to fix. The dmr-encoded JSON API does not seem to allow any actions to be triggered by GET requests, only POST requests. There are two main mechanisms for effecting CSRF attacks using POST requests:

1) Using a <form> with Javascript to auto-submit the form. This is not feasible in this case because the form will generate a POST body consisting of key/value pairs rather than an encoded JSON string.

2) Using Javascript to call XMLHTTPRequest with the encoded JSON string in the POST body. This fails because the request is cross-domain, requiring CORS to function. As previously noted, the Access-Control-Allow-Origin: * header should enable this. It turns out that CORS includes a pre-flight request [0] that calls the URL using the OPTIONS HTTP verb, excluding user credentials. This request fails, with 401 Authentication Required. Enabling the security realm seems to require authentication for all HTTP verbs, and I can't see how to disable it for the OPTIONS verb. If I could do that, I'm confident a CSRF attack is possible.

There could also be other techniques I'm not aware of. There's no CSRF token being used, and I think we need to add one.

[0] http://www.w3.org/TR/cors/#preflight-request

So If you can send a valid json post (non-base64 encoded something) to ES within a text-plain post then something like the following may work:

 <form action="http://localhost:9990/management" method="post" id="sup"  enctype="text/plain">
        <input id=32 name="{'system-property' : 'x" type="hidden" value="likeaboss' }"></input>
</form>

For me adding authentication looks enough and I am -1 adding the stuff like: "Access-Control-Allow-Origin: * header".

(In reply to comment #11)

Hi Jean,

  if under authentication you mean adding CSRF token protection, then right, it should be probably sufficient to remove this deficiency (though David can comment more appropriately, since he is testing this). Agree that "Access-Control-Allow-Origin: * header" might
be new feature not necessarily required to fix this.

Jan.

> For me adding authentication looks enough and I am -1 adding the stuff like:
> "Access-Control-Allow-Origin: * header".

I'll have to have a play and see what the server actually accepts with and without auth. I don't know enough / what the server accepts. From David Jorm's comment it seems like he knows more about what (the server) accepts.

I am now able to reproduce a CSRF attack, using non-encoded JSON as suggested by dave b.

This development is being tracked in JIRA:
https://issues.jboss.org/browse/AS7-2400

This issue has been addressed in the following commit:

https://github.com/jbossas/jboss-as/commit/29cf3610d8dab1af0227842d877b926543b72273

This issue is now resolved in JBoss AS 7.1.0 Beta 1.

Statement:

Not vulnerable. This issue only affects community JBoss AS 7 prior to 7.1.0
Beta 1. It does not affect components shipped with any Red Hat products.