You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Kevin Schmidt <kt...@gmail.com> on 2017/02/23 22:28:43 UTC
Installing pax-war feature makes Gogo console available unsecured
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
Re: Installing pax-war feature makes Gogo console available unsecured
Posted by Kevin Schmidt <kt...@gmail.com>.
It appears this issue may have been introduced as a result of issue 2634 (
https://issues.apache.org/jira/browse/KARAF-2634). The change log shows an
alias property was added to the plugin service registration which to my
understanding, would result in the extender whiteboard publishing the
endpoint at the specified URI. The subject of the ticket says it was just
to eliminate a warning, so was it really desired to cause this duplicate
registration? Is the fix for this issue to just remove the alias from the
registration?
On Thu, Feb 23, 2017 at 2:28 PM, Kevin Schmidt <kt...@gmail.com> 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
>
Re: Installing pax-war feature makes Gogo console available unsecured
Posted by Christian Schneider <ch...@die-schneider.net>.
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
> <chris@die-schneider.net <ma...@die-schneider.net>> 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
Re: Installing pax-war feature makes Gogo console available unsecured
Posted by Christian Schneider <ch...@die-schneider.net>.
I opened an issue for this:
https://issues.apache.org/jira/browse/KARAF-4993
The actual problem is probably rather in webconsole or pax web but we
need to track this at karaf as we should not release karaf 4.1.1 without
a fix for this.
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
> <chris@die-schneider.net <ma...@die-schneider.net>> 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
Re: Installing pax-war feature makes Gogo console available unsecured
Posted by Kevin Schmidt <kt...@gmail.com>.
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 <
chris@die-schneider.net> 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
>
>
Re: Installing pax-war feature makes Gogo console available unsecured
Posted by Kevin Schmidt <kt...@gmail.com>.
Sure, I can do that.
On Fri, Feb 24, 2017 at 12:14 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> 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é <jb@nanthrax.net
> > <ma...@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é
> > jbonofre@apache.org <ma...@apache.org>
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Installing pax-war feature makes Gogo console available unsecured
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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� <jb@nanthrax.net
> <ma...@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�
> jbonofre@apache.org <ma...@apache.org>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Installing pax-war feature makes Gogo console available unsecured
Posted by Kevin Schmidt <kt...@gmail.com>.
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é <jb...@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.renderT
>> opNavigation(AbstractWebConsolePlugin.java:681)
>> at org.apache.felix.webconsole.AbstractWebConsolePlugin.doGet(A
>> bstractWebConsolePlugin.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.doFilte
>> r(ServletHandler.java:1772)
>> at org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.do
>> Filter(WebSocketUpgradeFilter.java:193)
>> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilte
>> r(ServletHandler.java:1759)
>> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHan
>> dler.java:582)
>> at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletH
>> andler.doHandle(HttpServiceServletHandler.java:70)
>> at org.eclipse.jetty.server.handler.ScopedHandler.handle(Scoped
>> Handler.java:143)
>> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHa
>> ndler.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(ServletHand
>> ler.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(Scoped
>> Handler.java:141)
>> at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerC
>> ollection.handle(JettyServerHandlerCollection.java:80)
>> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(Handl
>> erWrapper.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(HttpConne
>> ction.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(SelectChann
>> elEndPoint.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(Queued
>> ThreadPool.java:671)
>> at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedT
>> hreadPool.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 Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Installing pax-war feature makes Gogo console available unsecured
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
I think it exists since the beginning ;)
If you access gogo via the webconsole it's OK, but directly on the gogo
URL, it's "open".
Regards
JB
On 02/24/2017 09:06 AM, Christian Schneider wrote:
> I was able to reproduce in karaf 4.0.8. This is pretty serious as we
> already have the 4.x line in production. Did you also reproduce on 3.x?
>
> Christian
>
> On 24.02.2017 09:03, Jean-Baptiste Onofr� 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.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 Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>>
>
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Installing pax-war feature makes Gogo console available unsecured
Posted by Christian Schneider <ch...@die-schneider.net>.
I was able to reproduce in karaf 4.0.8. This is pretty serious as we
already have the 4.x line in production. Did you also reproduce on 3.x?
Christian
On 24.02.2017 09:03, Jean-Baptiste Onofr� 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.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 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
Re: Installing pax-war feature makes Gogo console available unsecured
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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.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 Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Installing pax-war feature makes Gogo console available unsecured
Posted by Christian Schneider <ch...@die-schneider.net>.
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 Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Installing pax-war feature makes Gogo console available unsecured
Posted by Kevin Schmidt <kt...@gmail.com>.
JB,
Yep, that is correct. Note the trailing slash is important, I think
http://localhost:8181/gogo will return a 404 but http://localhost:8181/gogo/
will bring up the gogo console without requiring authentication.
Kevin
On Thu, Feb 23, 2017 at 10:42 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> Hi Kevin,
>
> Let me try to reproduce. You mean that I can access to
> http://localhost:8181/gogo without authentication, right ?
>
> Regards
> JB
>
>
> On 02/23/2017 11:28 PM, 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
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Installing pax-war feature makes Gogo console available unsecured
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Kevin,
Let me try to reproduce. You mean that I can access to
http://localhost:8181/gogo without authentication, right ?
Regards
JB
On 02/23/2017 11:28 PM, 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
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com