You are right. I was able to narrow it down to:
feature:install webconsole http-whiteboard
This is already enough to reproduce the issue. The war feature is not
necessary. It also does not happen with just the http feature. So this
all points to the whiteboard picking up the gogo service.
Christian
On 24.02.2017 08:52, Kevin Schmidt wrote:
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] <mailto:[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)
atorg.eclipse.jetty.io
<http://org.eclipse.jetty.io>.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
atorg.eclipse.jetty.io
<http://org.eclipse.jetty.io>.FillInterest.fillable(FillInterest.java:110)
atorg.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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
