Hi Kevin, do you mind to report a CVE for that (http://www.apache.org/security/) ?
Thanks, Regards JB On 02/24/2017 09:07 AM, Kevin Schmidt wrote:
I saw it with 3.0.6 and 3.0.8 too. I'm guessing it is due to the addition of the alias property on the service registration that was part of https://issues.apache.org/jira/browse/KARAF-2634 On Fri, Feb 24, 2017 at 12:03 AM, Jean-Baptiste Onofré <j...@nanthrax.net <mailto:j...@nanthrax.net>> wrote: I don't think it's only Karaf 4.1.0, I'm pretty sure it was already the case on 4.0.x. Regards JB On 02/24/2017 08:48 AM, Christian Schneider wrote: I can reproduce the issue: Start plain karaf 4.1.0 feature:install webconsole pax-war Acess http://localhost:8181/gogo/ If I use http://localhost:8181/gogo I get a NPE like below. Christian java.lang.NullPointerException at org.apache.felix.webconsole.AbstractWebConsolePlugin.renderTopNavigation(AbstractWebConsolePlugin.java:681) at org.apache.felix.webconsole.AbstractWebConsolePlugin.doGet(AbstractWebConsolePlugin.java:190) at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1772) at org.eclipse.jetty.websocket.se <http://org.eclipse.jetty.websocket.se>rver.WebSocketUpgradeFilter.do <http://rver.WebSocketUpgradeFilter.do>Filter(WebSocketUpgradeFilter.java:193) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180) at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:284) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) at org.eclipse.jetty.server.Server.handle(Server.java:534) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251) at org.eclipse.jetty.io <http://org.eclipse.jetty.io>.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283) at org.eclipse.jetty.io <http://org.eclipse.jetty.io>.FillInterest.fillable(FillInterest.java:110) at org.eclipse.jetty.io <http://org.eclipse.jetty.io>.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303) at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148) at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) at java.lang.Thread.run(Thread.java:745) On 23.02.2017 23:28, Kevin Schmidt wrote: Hi, I've come across a situation where the Gogo console ends up being accessible at a URL that is unsecured. This is of course not a good thing ... When I install a base Karaf 4.0.8 (and 3.0.8 too it appears) and install the webconsole feature, I'm able to go to http://localhost:8181/system/console <http://localhost:8181/system/console> and it requires authentication, and I can navigate to the Gogo console (http://localhost:8181/system/console/gogo <http://localhost:8181/system/console/gogo>) and everything works fine. If I try to go to the Gogo console URL directly in a new browser session, it also requires authentication. All is good. But if I install the pax-war feature, problems arise. All of the above works fine, but the Gogo console is now available at http://localhost:8181/gogo/ and worse, it doesn't require authentication. Prior to installing pax-war, hitting that address would yield a 404. It appears what is happening is that the Gogo console plugin registers its servlet in the service registry with an alias property set to "/gogo" and the Pax Web Extender Whiteboard sees this and publishes the servlet at an endpoint using that alias, and does so unsecured. I'm not sure if the issue is the Gogo plugin registering itself with an alias so the extender whiteboard sees it and publishes it, or if the extender whiteboard is supposed to be smart enough to not publish the new endpoint, or at least it should do it secured. But it is probably pretty common to have a Karaf install with webconsole and pax-war features installed, and if so, this security hole is there to be exploited. The workaround we are doing for now is to stop the Gogo plugin bundle as we don't really need to use it, but I wonder if other endpoints are getting automatically published through this mechanism that might also be a surprise? What is the correct fix for this? Thanks, Kevin -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org <mailto:jbono...@apache.org> http://blog.nanthrax.net Talend - http://www.talend.com
-- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
