Authentication bypass allowing arbitrary code execution

Martin Weusten added a comment - 11/11/08 01:09 PM General workaround Use your firewall to restrict access to admin console ports to required IP ranges only, e.g. your local network. Workaround for Linux systems Block admin console ports (normally 9090 and 9091) in your servers firewall. Use SSH to forward these ports to your local host: ssh -L 9091:localhost:9091 username@yourserver.org You can access to Admin console now via https://localhost:9091/ This should be safe. Workaround using Apache Maybe it's possible to use mod_proxy and mod_rewrite like this: RewriteRule ^/admin/(.*) http://localhost:9090/$1 [P] This could work, because Apache does evaluate the URL before rewriting. However, I did not try this!

Daryl Herzmann added a comment - 11/11/08 02:54 PM blocker needs to block a release.

Martin Weusten added a comment - 11/12/08 12:47 AM Posted a possible fix in forum: http://www.igniterealtime.org/community/thread/35874?start=15&tstart=0

Guus der Kinderen added a comment - 11/12/08 09:40 AM I've linked the other JIRA issues that relate to the same security advisory to this JIRA issue.

Martin Weusten added a comment - 11/12/08 06:04 PM Guus and I worked on a patch for this. This will require changes to several plugins which exclude themself from AuthCheckFilter. I think we will discuss this on the community chat shortly. diff -r -C 4 openfire_src_3_6_0/src/java/org/jivesoftware/admin/AuthCheckFilter.java openfire_patch_3_6_0a/src/java/org/jivesoftware/admin/AuthCheckFilter.java *** openfire_src_3_6_0/src/java/org/jivesoftware/admin/AuthCheckFilter.java 2008-08-29 06:13:22.000000000 +0200 --- openfire_patch_3_6_0a/src/java/org/jivesoftware/admin/AuthCheckFilter.java 2008-11-12 16:53:18.000000000 +0100 *************** *** 77,94 **** String loginPage = defaultLoginPage; if (loginPage == null ) { loginPage = request.getContextPath() + "/login.jsp" ; } // Get the page we're on: ! String url = request.getRequestURL().toString(); // See if it's contained in the exclude list. If so, skip filter execution ! boolean doExclude = false ; ! for ( String exclude : excludes) { ! if (url.indexOf(exclude) > -1) { ! doExclude = true ; ! break ; ! } ! } if (!doExclude) { WebManager manager = new WebManager(); manager.init(request, response, request.getSession(), context); if (manager.getUser() == null ) { --- 77,90 ---- String loginPage = defaultLoginPage; if (loginPage == null ) { loginPage = request.getContextPath() + "/login.jsp" ; } + // Get the page we're on: ! String srvpath = request.getServletPath(); // See if it's contained in the exclude list. If so, skip filter execution ! boolean doExclude = XMPPServer.getInstance().isSetupMode() || excludes.contains(srvpath); ! if (!doExclude) { WebManager manager = new WebManager(); manager.init(request, response, request.getSession(), context); if (manager.getUser() == null ) { diff -r -C 4 openfire_src_3_6_0/src/web/index.jsp openfire_patch_3_6_0a/src/web/index.jsp *** openfire_src_3_6_0/src/web/index.jsp 2008-08-29 06:13:17.000000000 +0200 --- openfire_patch_3_6_0a/src/web/index.jsp 2008-11-12 16:49:22.000000000 +0100 *************** *** 53,60 **** --- 53,68 ---- <%-- Define Administration Bean --%> <jsp:useBean id= "webManager" class= "org.jivesoftware.util.WebManager" /> <% webManager.init(request, response, session, application, out); %> + <%-- Check if in setup mode --%> + <% + if (webManager.isSetupMode()) { + response.sendRedirect( "setup/index.jsp" ); + return ; + } + %> + <%! long lastRRSFecth = 0; SyndFeed lastBlogFeed = null ; SyndFeed lastReleaseFeed = null ; String blogFeedRSS = "http: //www.igniterealtime.org/community/blogs/ignite/feeds/posts" ; diff -r -C 4 openfire_src_3_6_0/src/web/WEB-INF/web.xml openfire_patch_3_6_0a/src/web/WEB-INF/web.xml *** openfire_src_3_6_0/src/web/WEB-INF/web.xml 2008-08-29 06:13:17.000000000 +0200 --- openfire_patch_3_6_0a/src/web/WEB-INF/web.xml 2008-11-12 16:57:05.000000000 +0100 *************** *** 23,31 **** <filter-class>org.jivesoftware.admin.AuthCheckFilter</filter-class> <init-param> <param-name>excludes</param-name> <param-value> ! login.jsp,index.jsp?logout= true ,setup/index.jsp,setup/setup-,.gif,.png,error-serverdown.jsp,setup/clearspace-integration-prelogin.jsp </param-value> </init-param> </filter> --- 23,31 ---- <filter-class>org.jivesoftware.admin.AuthCheckFilter</filter-class> <init-param> <param-name>excludes</param-name> <param-value> ! /login.jsp </param-value> </init-param> </filter>

Matt Tucker added a comment - 11/13/08 02:48 AM I checked in a comprehensive fix to this issue today. Existing behavior is supported, except that exclude rules like the setup rule must now include a wildcard at the end. We are doing some more comprehensive testing of the fix but so far all looks good. Look for a release very soon.

M.Kiesel added a comment - 11/13/08 02:25 PM I would not call http://www.igniterealtime.org/fisheye/browse/svn-org/openfire/trunk/src/java/org/jivesoftware/admin/AuthCheckFilter.java?r1=10204&r2=10870 'comprehensive'. Adding this kind of convoluted matching code to a security-related code path is no good. Also, I think it's broken: Add "setup/setup-/%2E%2E/%2E%2E/log.jsp?log=info&mode=asc&lines=All" to your unit tests.

Martin Weusten added a comment - 11/14/08 03:52 PM This bug is still not solved!!! This does still return the content of info.log without auth: echo "GET /setup/setup-/%2E%2E/%2E%2E/log.jsp?log=info&mode=asc&lines=All" | nc localhost 9090

Daryl Herzmann added a comment - 11/14/08 04:01 PM reopening, cuz I have the power to do so for now

Matt Tucker added a comment - 11/14/08 08:02 PM Fixes can only ever be as comprehensive as the tests. Thanks guys for pointing out more error cases. I'm about to check in logic that checks for %2E. We don't like having complex code either. Another approach I've seen is adding an annotation to actions/JSP pages that indicates what kind of access checking should be done. That's probably a better approach since it's very explicit, but isn't a super quick fix. So, I'd rather go with this approach for now if we believe we can catch all the cases. There's an AuthCheckFilterTest class where we've been adding to. If you guys can think of more cases, let's add them there. I'll leave this issue open for now.

Martin Weusten added a comment - 11/14/08 08:54 PM We don't like having complex code either. Another approach I've seen is adding an annotation to actions/JSP pages that indicates what kind of access checking should be done. What about the fix from Guus and me I posted above?

Gaston Dombiak added a comment - 11/15/08 01:10 AM Reported problem has been fixed. Lets do the release now since known issues have been solved. If more things are found we can fix them in the next release.