You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Trevv <45...@safe-mail.net> on 2008/11/14 05:44:35 UTC
Hmm, that sounds like a security vulnerability.
Gert Vanthienen wrote:
>
> In the current implementation, camel-jetty already binds to all local
> interfaces, even if you use localhost in the uri.
Hmm, that sounds like a security vulnerability. When people specify
that a serversocket should be bound to localhost, often it's because
they are exposing a service that hasn't been "hardened" for exposure
to the hostile Internet.
If Camel is allowing connections from the outside world, when the
person who defined the route indicated that connections should only
be allowed from localhost... that's probably a bad idea.
Are you experiencing any problems with this?
I'm not experiencing a problem with the Jetty consumer, because I'm
using it only in a "test harness," on a virtual machine which the
world can't access.
The problem I'm experiencing is with the Mina consumer: if I specify
localhost, then clients can't connect to my server unless they are
local clients. This is actually the correct behavior when you specify
localhost, but this isn't the behavior that I want. The behavior
that I want is the behavior that you get if you pass null as the
address argument of the InetSocketAddress constructor, at line
#124 of MinaComponent.java version 1.5.0.
I have temporarily solved my problem by specifying 0.0.0.0 instead
of localhost. It's working, but it's a kluge, because: (1) Sun's
javadoc never says that you can use "0.0.0.0" as a substitute for
null; and (2) I suspect that it may not work with IPv6.
My recommendations, for both Jetty and Mina consumers:
DO allow the user to specify the wildcard address.
DO NOT bind to the wildcard address, when the user specifies localhost.
--
View this message in context: http://www.nabble.com/Jetty-and-Mina%3A-how-to-bind-to-%22anylocal%22-AKA-%22wildcard%22-address--tp20475674s22882p20494645.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Hmm, that sounds like a security vulnerability.
Posted by Roman Kalukiewicz <ro...@gmail.com>.
I created a JIIRA for it and I'll try to solve it out:
https://issues.apache.org/activemq/browse/CAMEL-1091
Romek
2008/11/14 Claus Ibsen <cl...@gmail.com>:
> Hi Romek
>
> Could you check the camel-jetty component to see what needs to be
> changed to support the issue with localhost?
> So we could try to fix the issue if possible.
>
> /Claus Ibsen
> Apache Camel Committer
> Blog: http://davsclaus.blogspot.com/
>
>
>
> On Fri, Nov 14, 2008 at 10:58 AM, Roman Kalukiewicz
> <ro...@gmail.com> wrote:
>> Hello Gert!
>>
>> In fact 0.0.0.0 address is specified in (RFC 1700) and it is correct.
>> On IPv6 network similar address is 0:0:0:0:0:0:0:0 (RFC 2373). Both of
>> them are used in C as constants INADDR_ANY and IN6ADDR_ANY (their
>> value are zeros).
>>
>> Of course I agree that if you specify localhost, it should bind to
>> local interface and so on in case of jetty, but MINA behaves OK.
>>
>> Romek
>>
>> 2008/11/14 Trevv <45...@safe-mail.net>:
>>>
>>>
>>> Gert Vanthienen wrote:
>>>>
>>>> In the current implementation, camel-jetty already binds to all local
>>>> interfaces, even if you use localhost in the uri.
>>>
>>> Hmm, that sounds like a security vulnerability. When people specify
>>> that a serversocket should be bound to localhost, often it's because
>>> they are exposing a service that hasn't been "hardened" for exposure
>>> to the hostile Internet.
>>>
>>> If Camel is allowing connections from the outside world, when the
>>> person who defined the route indicated that connections should only
>>> be allowed from localhost... that's probably a bad idea.
>>>
>>>
>>> Are you experiencing any problems with this?
>>>
>>> I'm not experiencing a problem with the Jetty consumer, because I'm
>>> using it only in a "test harness," on a virtual machine which the
>>> world can't access.
>>>
>>> The problem I'm experiencing is with the Mina consumer: if I specify
>>> localhost, then clients can't connect to my server unless they are
>>> local clients. This is actually the correct behavior when you specify
>>> localhost, but this isn't the behavior that I want. The behavior
>>> that I want is the behavior that you get if you pass null as the
>>> address argument of the InetSocketAddress constructor, at line
>>> #124 of MinaComponent.java version 1.5.0.
>>>
>>> I have temporarily solved my problem by specifying 0.0.0.0 instead
>>> of localhost. It's working, but it's a kluge, because: (1) Sun's
>>> javadoc never says that you can use "0.0.0.0" as a substitute for
>>> null; and (2) I suspect that it may not work with IPv6.
>>>
>>> My recommendations, for both Jetty and Mina consumers:
>>>
>>> DO allow the user to specify the wildcard address.
>>>
>>> DO NOT bind to the wildcard address, when the user specifies localhost.
>>> --
>>> View this message in context: http://www.nabble.com/Jetty-and-Mina%3A-how-to-bind-to-%22anylocal%22-AKA-%22wildcard%22-address--tp20475674s22882p20494645.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>>>
>>
>
Re: Hmm, that sounds like a security vulnerability.
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
If the change applies for Camel 2.0 only then I think it's okay to
change the default behavior if we have stated it in the wiki
documentation and release notes as well.
For 1.5.1 if we patch it, then a LOG WARN is fine, maybe on the
endpoint creation, so you wont get the WARN on each message exchange.
/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
On Fri, Nov 14, 2008 at 7:40 PM, Roman Kalukiewicz
<ro...@gmail.com> wrote:
> One concern about this bug (I've already implemented a fix, so it is
> almost there).
>
> I'm afraid that majority of people today have constructs like:
>
> from("jetty:http://localhost:1234/myPath")
>
> while what they want is
>
> from("jetty:http://0.0.0.0:1234/myPath")
>
> This way we may brake some routes that already exist. I believe it
> deserves at least a warning in logs.
>
> My question is if we would like to preserve an old behavior as a
> default one or maybe write a warning and behave in a proper way.
>
> What do you think?
>
> I personally would choose a warning only.
>
> Romek
>
> 2008/11/14 Claus Ibsen <cl...@gmail.com>:
>> Hi Romek
>>
>> Could you check the camel-jetty component to see what needs to be
>> changed to support the issue with localhost?
>> So we could try to fix the issue if possible.
>>
>> /Claus Ibsen
>> Apache Camel Committer
>> Blog: http://davsclaus.blogspot.com/
>>
>>
>>
>> On Fri, Nov 14, 2008 at 10:58 AM, Roman Kalukiewicz
>> <ro...@gmail.com> wrote:
>>> Hello Gert!
>>>
>>> In fact 0.0.0.0 address is specified in (RFC 1700) and it is correct.
>>> On IPv6 network similar address is 0:0:0:0:0:0:0:0 (RFC 2373). Both of
>>> them are used in C as constants INADDR_ANY and IN6ADDR_ANY (their
>>> value are zeros).
>>>
>>> Of course I agree that if you specify localhost, it should bind to
>>> local interface and so on in case of jetty, but MINA behaves OK.
>>>
>>> Romek
>>>
>>> 2008/11/14 Trevv <45...@safe-mail.net>:
>>>>
>>>>
>>>> Gert Vanthienen wrote:
>>>>>
>>>>> In the current implementation, camel-jetty already binds to all local
>>>>> interfaces, even if you use localhost in the uri.
>>>>
>>>> Hmm, that sounds like a security vulnerability. When people specify
>>>> that a serversocket should be bound to localhost, often it's because
>>>> they are exposing a service that hasn't been "hardened" for exposure
>>>> to the hostile Internet.
>>>>
>>>> If Camel is allowing connections from the outside world, when the
>>>> person who defined the route indicated that connections should only
>>>> be allowed from localhost... that's probably a bad idea.
>>>>
>>>>
>>>> Are you experiencing any problems with this?
>>>>
>>>> I'm not experiencing a problem with the Jetty consumer, because I'm
>>>> using it only in a "test harness," on a virtual machine which the
>>>> world can't access.
>>>>
>>>> The problem I'm experiencing is with the Mina consumer: if I specify
>>>> localhost, then clients can't connect to my server unless they are
>>>> local clients. This is actually the correct behavior when you specify
>>>> localhost, but this isn't the behavior that I want. The behavior
>>>> that I want is the behavior that you get if you pass null as the
>>>> address argument of the InetSocketAddress constructor, at line
>>>> #124 of MinaComponent.java version 1.5.0.
>>>>
>>>> I have temporarily solved my problem by specifying 0.0.0.0 instead
>>>> of localhost. It's working, but it's a kluge, because: (1) Sun's
>>>> javadoc never says that you can use "0.0.0.0" as a substitute for
>>>> null; and (2) I suspect that it may not work with IPv6.
>>>>
>>>> My recommendations, for both Jetty and Mina consumers:
>>>>
>>>> DO allow the user to specify the wildcard address.
>>>>
>>>> DO NOT bind to the wildcard address, when the user specifies localhost.
>>>> --
>>>> View this message in context: http://www.nabble.com/Jetty-and-Mina%3A-how-to-bind-to-%22anylocal%22-AKA-%22wildcard%22-address--tp20475674s22882p20494645.html
>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>
>
Re: Hmm, that sounds like a security vulnerability.
Posted by Roman Kalukiewicz <ro...@gmail.com>.
One concern about this bug (I've already implemented a fix, so it is
almost there).
I'm afraid that majority of people today have constructs like:
from("jetty:http://localhost:1234/myPath")
while what they want is
from("jetty:http://0.0.0.0:1234/myPath")
This way we may brake some routes that already exist. I believe it
deserves at least a warning in logs.
My question is if we would like to preserve an old behavior as a
default one or maybe write a warning and behave in a proper way.
What do you think?
I personally would choose a warning only.
Romek
2008/11/14 Claus Ibsen <cl...@gmail.com>:
> Hi Romek
>
> Could you check the camel-jetty component to see what needs to be
> changed to support the issue with localhost?
> So we could try to fix the issue if possible.
>
> /Claus Ibsen
> Apache Camel Committer
> Blog: http://davsclaus.blogspot.com/
>
>
>
> On Fri, Nov 14, 2008 at 10:58 AM, Roman Kalukiewicz
> <ro...@gmail.com> wrote:
>> Hello Gert!
>>
>> In fact 0.0.0.0 address is specified in (RFC 1700) and it is correct.
>> On IPv6 network similar address is 0:0:0:0:0:0:0:0 (RFC 2373). Both of
>> them are used in C as constants INADDR_ANY and IN6ADDR_ANY (their
>> value are zeros).
>>
>> Of course I agree that if you specify localhost, it should bind to
>> local interface and so on in case of jetty, but MINA behaves OK.
>>
>> Romek
>>
>> 2008/11/14 Trevv <45...@safe-mail.net>:
>>>
>>>
>>> Gert Vanthienen wrote:
>>>>
>>>> In the current implementation, camel-jetty already binds to all local
>>>> interfaces, even if you use localhost in the uri.
>>>
>>> Hmm, that sounds like a security vulnerability. When people specify
>>> that a serversocket should be bound to localhost, often it's because
>>> they are exposing a service that hasn't been "hardened" for exposure
>>> to the hostile Internet.
>>>
>>> If Camel is allowing connections from the outside world, when the
>>> person who defined the route indicated that connections should only
>>> be allowed from localhost... that's probably a bad idea.
>>>
>>>
>>> Are you experiencing any problems with this?
>>>
>>> I'm not experiencing a problem with the Jetty consumer, because I'm
>>> using it only in a "test harness," on a virtual machine which the
>>> world can't access.
>>>
>>> The problem I'm experiencing is with the Mina consumer: if I specify
>>> localhost, then clients can't connect to my server unless they are
>>> local clients. This is actually the correct behavior when you specify
>>> localhost, but this isn't the behavior that I want. The behavior
>>> that I want is the behavior that you get if you pass null as the
>>> address argument of the InetSocketAddress constructor, at line
>>> #124 of MinaComponent.java version 1.5.0.
>>>
>>> I have temporarily solved my problem by specifying 0.0.0.0 instead
>>> of localhost. It's working, but it's a kluge, because: (1) Sun's
>>> javadoc never says that you can use "0.0.0.0" as a substitute for
>>> null; and (2) I suspect that it may not work with IPv6.
>>>
>>> My recommendations, for both Jetty and Mina consumers:
>>>
>>> DO allow the user to specify the wildcard address.
>>>
>>> DO NOT bind to the wildcard address, when the user specifies localhost.
>>> --
>>> View this message in context: http://www.nabble.com/Jetty-and-Mina%3A-how-to-bind-to-%22anylocal%22-AKA-%22wildcard%22-address--tp20475674s22882p20494645.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>>>
>>
>
Re: Hmm, that sounds like a security vulnerability.
Posted by Claus Ibsen <cl...@gmail.com>.
Hi Romek
Could you check the camel-jetty component to see what needs to be
changed to support the issue with localhost?
So we could try to fix the issue if possible.
/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
On Fri, Nov 14, 2008 at 10:58 AM, Roman Kalukiewicz
<ro...@gmail.com> wrote:
> Hello Gert!
>
> In fact 0.0.0.0 address is specified in (RFC 1700) and it is correct.
> On IPv6 network similar address is 0:0:0:0:0:0:0:0 (RFC 2373). Both of
> them are used in C as constants INADDR_ANY and IN6ADDR_ANY (their
> value are zeros).
>
> Of course I agree that if you specify localhost, it should bind to
> local interface and so on in case of jetty, but MINA behaves OK.
>
> Romek
>
> 2008/11/14 Trevv <45...@safe-mail.net>:
>>
>>
>> Gert Vanthienen wrote:
>>>
>>> In the current implementation, camel-jetty already binds to all local
>>> interfaces, even if you use localhost in the uri.
>>
>> Hmm, that sounds like a security vulnerability. When people specify
>> that a serversocket should be bound to localhost, often it's because
>> they are exposing a service that hasn't been "hardened" for exposure
>> to the hostile Internet.
>>
>> If Camel is allowing connections from the outside world, when the
>> person who defined the route indicated that connections should only
>> be allowed from localhost... that's probably a bad idea.
>>
>>
>> Are you experiencing any problems with this?
>>
>> I'm not experiencing a problem with the Jetty consumer, because I'm
>> using it only in a "test harness," on a virtual machine which the
>> world can't access.
>>
>> The problem I'm experiencing is with the Mina consumer: if I specify
>> localhost, then clients can't connect to my server unless they are
>> local clients. This is actually the correct behavior when you specify
>> localhost, but this isn't the behavior that I want. The behavior
>> that I want is the behavior that you get if you pass null as the
>> address argument of the InetSocketAddress constructor, at line
>> #124 of MinaComponent.java version 1.5.0.
>>
>> I have temporarily solved my problem by specifying 0.0.0.0 instead
>> of localhost. It's working, but it's a kluge, because: (1) Sun's
>> javadoc never says that you can use "0.0.0.0" as a substitute for
>> null; and (2) I suspect that it may not work with IPv6.
>>
>> My recommendations, for both Jetty and Mina consumers:
>>
>> DO allow the user to specify the wildcard address.
>>
>> DO NOT bind to the wildcard address, when the user specifies localhost.
>> --
>> View this message in context: http://www.nabble.com/Jetty-and-Mina%3A-how-to-bind-to-%22anylocal%22-AKA-%22wildcard%22-address--tp20475674s22882p20494645.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>
Re: Hmm, that sounds like a security vulnerability.
Posted by Hadrian Zbarcea <hz...@gmail.com>.
I agree with Roman, -1 from me as well.
It's interesting that localhost maps to the loopback address, while
the hostname resolves to, well, a nic address, but there's no name
defined by the standard to refer to "all nics". This maybe a
deficiency of the standard :).
I personally see no problem with specifying 0.0.0.0 if that's what's
desired. First of all this is server side configuration, which means
that it needs to be changed in one place only when moving form ipv4 to
ipv6 so clients will not need to be upgraded (plus such an address
won't make any sense there). If a users wants to make that change
with zero code changes, it could use a property for the server address.
My $0.02,
Hadrian
On Nov 17, 2008, at 12:54 PM, Roman Kalukiewicz wrote:
> Right.. it is extremely important because when IPv8 and IPv9 is going
> to mainstream, Camel will already be very popular ;)
>
> But seriously now: I believe that an amount of magic increases when we
> see 'ANY' in a host part of URL and is lower when you see 0.0.0.0
> (look at how 'netstat -an' shows ports bound to all interfaces). Not
> to mention about the fact that 'any' is a legal host name.
>
> What I'm curious about is how 0.0.0.0 would be handled in IPv6, but I
> guess the port will be opened on all interfaces however they are
> addressed - even if they have only IPv6 address assigned (but it is
> something I don't really know). If it is not, then your point about
> 0.0.0.0 and 0:0:0:0:0:0:0:0 is good.
>
> So my opinion here is -1
> because of amount of magic that translates legal hostname to what is
> generally already handled by 0.0.0.0/0:0:0:0:0:0:0:0.
>
> Roman
>
> 2008/11/17 Trevv <45...@safe-mail.net>:
>>
>> Specifying "0.0.0.0" isn't as good as specifying null, because when
>> you
>> specify null you allow Sun's engineers (current or future) to make
>> the
>> decision. They can choose to interpret null as meaning both
>> INADDR_ANY
>> and IN6ADDR_ANY, and they can add IN8ADDR_ANY and IN9ADDR_ANY later.
>>
>> I think requiring a person to specify "0.0.0.0" and "0:0:0:0:0:0:0:0"
>> explicitly would cause some unnecessary brittleness.
>>
>> How about this convention? "jetty:http://any:1234/myPath" in which
>> "any" or "ANY" means to specify null as the bindAddr, or to use one
>> of
>> the ServerSocket constructors that don't require bindAddr.
>> --
>> View this message in context: http://www.nabble.com/Jetty-and-Mina%3A-how-to-bind-to-%22anylocal%22-AKA-%22wildcard%22-address--tp20475674s22882p20536134.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
Re: Hmm, that sounds like a security vulnerability.
Posted by Trevv <45...@safe-mail.net>.
I agree that Claus's idea would solve the problem. "Anylocalhost"
isn't quite right, but I think "anylocal" or "anylocaladdress" or
"allinterfaces" would be good.
RomKal wrote:
> But if you can address an endpoint (I believe you can) exposed with
> jetty:http://0.0.0.0:80/ with IPv6 then flag is not needed so
> definitely -1.
>
> If someone knows it already, lets respond. Otherwise I'll try to
> verify it soon at home (as here I don't have IPv6 at all).
I don't think this is something that you can verify by testing,
because it might be implemented differently in different operating
systems. I did a quick Web search, and the most relevant comment
that I found was this one, by an OS engineer at Sun:
Kacheong Poon wrote:
>
> To make it easy for porting application from using IPv4 to IPv6,
> an interesting feature was introduced. An IPv6 socket is allowed
> to receive both IPv4 and IPv6 traffic by default. For example, an
> IPv6 TCP listening socket bind() to unspecified address and port
> x can receive connection requests from both IPv4 and IPv6 remote
> hosts to port x. While porting is made easier, this is actually
> not "strictly correct." Logically, IPv4 and IPv6 port spaces for
> transport protocols should be separate, hence this check in the
> code.
>
>
> http://mail.opensolaris.org/pipermail/networking-discuss/2005-November/011586.html
> [networking-discuss] Solaris socket bind() behavior
In other words... it's complicated. That's why I think that the
smartest thing to do, if you just want a normal serversocket, is
to leave the bind address as null, and let Sun's Java engineers
decide what to do, instead of trying to find a non-null string
that you think will have the same effect that null would have.
On the other hand... having to specify both 0.0.0.0 and [::] is
unfortunate, but not a disaster. So I don't really need a fix.
--
View this message in context: http://www.nabble.com/Jetty-and-Mina%3A-how-to-bind-to-%22anylocal%22-AKA-%22wildcard%22-address--tp20475674s22882p20575883.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Hmm, that sounds like a security vulnerability.
Posted by Roman Kalukiewicz <ro...@gmail.com>.
2008/11/18 Hadrian Zbarcea <hz...@gmail.com>:
> I really don't see any difference between 0.0.0.0 as a hostname and
> anyLocalhost=true or allInterfaces=true attributes. We'd have to either
> check for an attribute value or the hostname value. When one reads a url,
> the semantics of 0.0.0.0 is pretty clear and we can put in the necessary
> code to deal with ipv6 (which i suspect it should be handled already
> anyway).
I would like to verify that 0.0.0.0 handles all IPv6 addresses also.
If it is the case, then definitelly any flag would be not needed.
> I'll give this a -1. I'll gladly change my vote if I see a compelling
> argument.
But the reason Trevv would like to have this flag is to have an
ability to expose an endpoint on all interfaces regarding of their
address (IPv4 vs. IPv6) so instead of writing:
jetty:http://0.0.0.0:80/test AND jetty:http://[::0]:80/test you can
simply use the flag. Small improvement, but basically additional flag
is not a problem if it helps someone, and doesn't affect others.
But if you can address an endpoint (I believe you can) exposed with
jetty:http://0.0.0.0:80/ with IPv6 then flag is not needed so
definitely -1.
If someone knows it already, lets respond. Otherwise I'll try to
verify it soon at home (as here I don't have IPv6 at all).
>> This is what I really like. This way what we do is clear, and we
>> explicitely mark that we want to ignore host part of the uri.
>
> Yeah, a hostname of 0.0.0.0 would mean precisely the same thing.
> Cheers
> Hadrian
>
>
> On Nov 18, 2008, at 5:17 AM, Roman Kalukiewicz wrote:
>
>> 2008/11/18 Claus Ibsen <cl...@gmail.com>:
>>>
>>> Hi
>>>
>>> We could also add a URI option as a flag for the any/localhost stuff
>>> But what would a good option name be?
>>>
>>>> from("jetty:http://any:1234/myPath?anyLocalhost=true").
>>
>> This is what I really like. This way what we do is clear, and we
>> explicitely mark that we want to ignore host part of the uri.
>>
>> I would just change a parameter name to something like
>> 'allInterfaces=true'. The open question would be if we should default
>> this parameter to true or false?
>> * false is good, because URI is taken as a whole and nothing is
>> silently discarded by default
>> * true is good, because it is the most common usage and it is backward
>> compatible
>>
>> My choice would be *false* but it is only +0.5 - I'm not really convinced
>> ;)
>>
>> Anyway thanks Claus! I believe all interested parties are happy with
>> such a solution!
>>
>> Romek
>
>
Re: Hmm, that sounds like a security vulnerability.
Posted by Hadrian Zbarcea <hz...@gmail.com>.
I really don't see any difference between 0.0.0.0 as a hostname and
anyLocalhost=true or allInterfaces=true attributes. We'd have to
either check for an attribute value or the hostname value. When one
reads a url, the semantics of 0.0.0.0 is pretty clear and we can put
in the necessary code to deal with ipv6 (which i suspect it should be
handled already anyway).
I'll give this a -1. I'll gladly change my vote if I see a compelling
argument.
> This is what I really like. This way what we do is clear, and we
> explicitely mark that we want to ignore host part of the uri.
Yeah, a hostname of 0.0.0.0 would mean precisely the same thing.
Cheers
Hadrian
On Nov 18, 2008, at 5:17 AM, Roman Kalukiewicz wrote:
> 2008/11/18 Claus Ibsen <cl...@gmail.com>:
>> Hi
>>
>> We could also add a URI option as a flag for the any/localhost stuff
>> But what would a good option name be?
>>
>>> from("jetty:http://any:1234/myPath?anyLocalhost=true").
>
> This is what I really like. This way what we do is clear, and we
> explicitely mark that we want to ignore host part of the uri.
>
> I would just change a parameter name to something like
> 'allInterfaces=true'. The open question would be if we should default
> this parameter to true or false?
> * false is good, because URI is taken as a whole and nothing is
> silently discarded by default
> * true is good, because it is the most common usage and it is backward
> compatible
>
> My choice would be *false* but it is only +0.5 - I'm not really
> convinced ;)
>
> Anyway thanks Claus! I believe all interested parties are happy with
> such a solution!
>
> Romek
Re: Hmm, that sounds like a security vulnerability.
Posted by Roman Kalukiewicz <ro...@gmail.com>.
2008/11/18 Claus Ibsen <cl...@gmail.com>:
> Hi
>
> We could also add a URI option as a flag for the any/localhost stuff
> But what would a good option name be?
>
>> from("jetty:http://any:1234/myPath?anyLocalhost=true").
This is what I really like. This way what we do is clear, and we
explicitely mark that we want to ignore host part of the uri.
I would just change a parameter name to something like
'allInterfaces=true'. The open question would be if we should default
this parameter to true or false?
* false is good, because URI is taken as a whole and nothing is
silently discarded by default
* true is good, because it is the most common usage and it is backward
compatible
My choice would be *false* but it is only +0.5 - I'm not really convinced ;)
Anyway thanks Claus! I believe all interested parties are happy with
such a solution!
Romek
Re: Hmm, that sounds like a security vulnerability.
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
We could also add a URI option as a flag for the any/localhost stuff
But what would a good option name be?
> from("jetty:http://any:1234/myPath?anyLocalhost=true").
/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
On Tue, Nov 18, 2008 at 10:32 AM, Trevv <45...@safe-mail.net> wrote:
>
>
> RomKal wrote:
>> (look at how 'netstat -an' shows ports bound to all interfaces).
> When I run 'netstat -an' some ports look like this:
>
> tcp 0 0 0.0.0.0:6031 0.0.0.0:* LISTEN
>
> and some look like this:
>
> tcp6 0 0 :::7254 :::* LISTEN
>
> What I'm curious about is how 0.0.0.0 would be handled in IPv6, but I
>> guess the port will be opened on all interfaces however they are
>> addressed - even if they have only IPv6 address assigned (but it is
>> something I don't really know). If it is not, then your point about
>> 0.0.0.0 and 0:0:0:0:0:0:0:0 is good.
> I'm not currently set up for IPv6 testing, but my intuition is that if
> there isn't any way to leave the bind address unspecified, then a person
> who wants to duplicate the behavior of a normal (unbound) ServerSocket
> might need to do something like this:
>
> from("jetty:http://0.0.0.0:1234/myPath").
> to("direct:xyz");
> from("jetty:http://[::]:1234/myPath").
> to("direct:xyz");
> from("direct:xyz")
>
> which seems unfortunate.
>
> Not to mention about the fact that 'any' is a legal host name.
> You're concerned that there might be someone who has a real interface
> named "any" and might want to bind a serversocket so that it accepts
> connections only through the interface named "any"?
>
> The cleanest solution would be just to omit the hostname, e.g.
>
> from("jetty:http://:1234/myPath")
>
> Unfortunately, although this syntax is legal under RFC 3986, it is illegal
> under RFC 2396. To comply with RFC 2396, it is necessary to put some
> bogus hostname ahead of the port number. And it ought to be a legal
> hostname, to guarantee that it can be stored in a URI without problems.
>
> If you're concerned that someone may want to bind a serversocket to a real
> interface named "any", perhaps it would be better to use a string that
> is more obscure. How about "unspecified" or "anylocal" which are legal
> hostnames, but very unlikely to be used as the name of a real interface?
> Or... how about "wild.camel" as the magic hostname?
>
> from("jetty:http://wild.camel:1234/myPath") // :-)
> --
> View this message in context: http://www.nabble.com/Jetty-and-Mina%3A-how-to-bind-to-%22anylocal%22-AKA-%22wildcard%22-address--tp20475674s22882p20556161.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
Re: Hmm, that sounds like a security vulnerability.
Posted by Trevv <45...@safe-mail.net>.
RomKal wrote:
> (look at how 'netstat -an' shows ports bound to all interfaces).
When I run 'netstat -an' some ports look like this:
tcp 0 0 0.0.0.0:6031 0.0.0.0:* LISTEN
and some look like this:
tcp6 0 0 :::7254 :::* LISTEN
What I'm curious about is how 0.0.0.0 would be handled in IPv6, but I
> guess the port will be opened on all interfaces however they are
> addressed - even if they have only IPv6 address assigned (but it is
> something I don't really know). If it is not, then your point about
> 0.0.0.0 and 0:0:0:0:0:0:0:0 is good.
I'm not currently set up for IPv6 testing, but my intuition is that if
there isn't any way to leave the bind address unspecified, then a person
who wants to duplicate the behavior of a normal (unbound) ServerSocket
might need to do something like this:
from("jetty:http://0.0.0.0:1234/myPath").
to("direct:xyz");
from("jetty:http://[::]:1234/myPath").
to("direct:xyz");
from("direct:xyz")
which seems unfortunate.
Not to mention about the fact that 'any' is a legal host name.
You're concerned that there might be someone who has a real interface
named "any" and might want to bind a serversocket so that it accepts
connections only through the interface named "any"?
The cleanest solution would be just to omit the hostname, e.g.
from("jetty:http://:1234/myPath")
Unfortunately, although this syntax is legal under RFC 3986, it is illegal
under RFC 2396. To comply with RFC 2396, it is necessary to put some
bogus hostname ahead of the port number. And it ought to be a legal
hostname, to guarantee that it can be stored in a URI without problems.
If you're concerned that someone may want to bind a serversocket to a real
interface named "any", perhaps it would be better to use a string that
is more obscure. How about "unspecified" or "anylocal" which are legal
hostnames, but very unlikely to be used as the name of a real interface?
Or... how about "wild.camel" as the magic hostname?
from("jetty:http://wild.camel:1234/myPath") // :-)
--
View this message in context: http://www.nabble.com/Jetty-and-Mina%3A-how-to-bind-to-%22anylocal%22-AKA-%22wildcard%22-address--tp20475674s22882p20556161.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Hmm, that sounds like a security vulnerability.
Posted by Roman Kalukiewicz <ro...@gmail.com>.
Right.. it is extremely important because when IPv8 and IPv9 is going
to mainstream, Camel will already be very popular ;)
But seriously now: I believe that an amount of magic increases when we
see 'ANY' in a host part of URL and is lower when you see 0.0.0.0
(look at how 'netstat -an' shows ports bound to all interfaces). Not
to mention about the fact that 'any' is a legal host name.
What I'm curious about is how 0.0.0.0 would be handled in IPv6, but I
guess the port will be opened on all interfaces however they are
addressed - even if they have only IPv6 address assigned (but it is
something I don't really know). If it is not, then your point about
0.0.0.0 and 0:0:0:0:0:0:0:0 is good.
So my opinion here is -1
because of amount of magic that translates legal hostname to what is
generally already handled by 0.0.0.0/0:0:0:0:0:0:0:0.
Roman
2008/11/17 Trevv <45...@safe-mail.net>:
>
> Specifying "0.0.0.0" isn't as good as specifying null, because when you
> specify null you allow Sun's engineers (current or future) to make the
> decision. They can choose to interpret null as meaning both INADDR_ANY
> and IN6ADDR_ANY, and they can add IN8ADDR_ANY and IN9ADDR_ANY later.
>
> I think requiring a person to specify "0.0.0.0" and "0:0:0:0:0:0:0:0"
> explicitly would cause some unnecessary brittleness.
>
> How about this convention? "jetty:http://any:1234/myPath" in which
> "any" or "ANY" means to specify null as the bindAddr, or to use one of
> the ServerSocket constructors that don't require bindAddr.
> --
> View this message in context: http://www.nabble.com/Jetty-and-Mina%3A-how-to-bind-to-%22anylocal%22-AKA-%22wildcard%22-address--tp20475674s22882p20536134.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
Re: Hmm, that sounds like a security vulnerability.
Posted by Trevv <45...@safe-mail.net>.
Specifying "0.0.0.0" isn't as good as specifying null, because when you
specify null you allow Sun's engineers (current or future) to make the
decision. They can choose to interpret null as meaning both INADDR_ANY
and IN6ADDR_ANY, and they can add IN8ADDR_ANY and IN9ADDR_ANY later.
I think requiring a person to specify "0.0.0.0" and "0:0:0:0:0:0:0:0"
explicitly would cause some unnecessary brittleness.
How about this convention? "jetty:http://any:1234/myPath" in which
"any" or "ANY" means to specify null as the bindAddr, or to use one of
the ServerSocket constructors that don't require bindAddr.
--
View this message in context: http://www.nabble.com/Jetty-and-Mina%3A-how-to-bind-to-%22anylocal%22-AKA-%22wildcard%22-address--tp20475674s22882p20536134.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Hmm, that sounds like a security vulnerability.
Posted by Roman Kalukiewicz <ro...@gmail.com>.
Hello Gert!
In fact 0.0.0.0 address is specified in (RFC 1700) and it is correct.
On IPv6 network similar address is 0:0:0:0:0:0:0:0 (RFC 2373). Both of
them are used in C as constants INADDR_ANY and IN6ADDR_ANY (their
value are zeros).
Of course I agree that if you specify localhost, it should bind to
local interface and so on in case of jetty, but MINA behaves OK.
Romek
2008/11/14 Trevv <45...@safe-mail.net>:
>
>
> Gert Vanthienen wrote:
>>
>> In the current implementation, camel-jetty already binds to all local
>> interfaces, even if you use localhost in the uri.
>
> Hmm, that sounds like a security vulnerability. When people specify
> that a serversocket should be bound to localhost, often it's because
> they are exposing a service that hasn't been "hardened" for exposure
> to the hostile Internet.
>
> If Camel is allowing connections from the outside world, when the
> person who defined the route indicated that connections should only
> be allowed from localhost... that's probably a bad idea.
>
>
> Are you experiencing any problems with this?
>
> I'm not experiencing a problem with the Jetty consumer, because I'm
> using it only in a "test harness," on a virtual machine which the
> world can't access.
>
> The problem I'm experiencing is with the Mina consumer: if I specify
> localhost, then clients can't connect to my server unless they are
> local clients. This is actually the correct behavior when you specify
> localhost, but this isn't the behavior that I want. The behavior
> that I want is the behavior that you get if you pass null as the
> address argument of the InetSocketAddress constructor, at line
> #124 of MinaComponent.java version 1.5.0.
>
> I have temporarily solved my problem by specifying 0.0.0.0 instead
> of localhost. It's working, but it's a kluge, because: (1) Sun's
> javadoc never says that you can use "0.0.0.0" as a substitute for
> null; and (2) I suspect that it may not work with IPv6.
>
> My recommendations, for both Jetty and Mina consumers:
>
> DO allow the user to specify the wildcard address.
>
> DO NOT bind to the wildcard address, when the user specifies localhost.
> --
> View this message in context: http://www.nabble.com/Jetty-and-Mina%3A-how-to-bind-to-%22anylocal%22-AKA-%22wildcard%22-address--tp20475674s22882p20494645.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>