Yep, same behavior I see.

It appears the gogo plugin both registers with the web console, but also
registers its service in a way that the extender whiteboard publishes the
/gogo/ endpoint.

On Thu, Feb 23, 2017 at 11:48 PM, Christian Schneider <
[email protected]> 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.server.WebSocketUpgradeFilter.doFilter(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.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
>       at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:110)
>       at 
> 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 and it requires authentication, and I can navigate to the Gogo
> console (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 Schneiderhttp://www.liquid-reality.de
>
> Open Source Architecthttp://www.talend.com
>
>

Reply via email to