You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by Linkezhang <li...@huawei.com> on 2016/10/27 10:58:32 UTC
Dear Community,we find a Vulnerability in
Zookeeper/SOLR/Apache(PHP) about tcp connection exhausted,Waiting for your
reply
Problem:
In the client using some method (such as telnet) to establish a tcp connection with server-side apache listening port , but after the establishment of tcp connection, the client does not send any data. However, apache will not disconnect this tcp connection, may lead to the number of connections exhausted , Resulting in DOS
The attack process：
1. The client executes the telnet service port
[cid:image001.png@01D23070.DA903540]
Start the client telnet server port 60000, do not exit for a long time:
Excuting an order:
telnet 172.22.17.26 60000
Re: Dear Community,we find a Vulnerability in
Zookeeper/SOLR/Apache(PHP) about tcp connection exhausted,Waiting for your
reply
Posted by Shawn Heisey <ap...@elyograg.org>.
On 10/27/2016 4:58 AM, Linkezhang wrote:
>
> *Problem:*
>
> In the client using some method (such as telnet) to establish a tcp
> connection with server-side apache listening port , but after the
> establishment of tcp connection, the client does not send any data.
> However, apache will not disconnect this tcp connection, may lead to
> the number of connections exhausted , Resulting in DOS
>
> *The attack process**\uff1a**
> *1. The client executes the telnet service port
>
> Start the client telnet server port 60000, do not exit for a long time:
I tried this with version 6.2.0, telnetting to port 8983. I find that
the telnet disconnects after a short time. The Jetty config that's in
an unmodified Solr install has a 50 second idle timeout, which is likely
what is causing the disconnect.
It's likely possible to change the Jetty config so that Solr would
behave this way, but I see no evidence of a problem in the default Solr
config.
Your subject mentions "PHP" ... but Solr doesn't use PHP. There are
several PHP clients for Solr, but they are developed by third parties.
The Lucene/Solr project is not involved with their development at all.
Solr defaults to port 8983, but you are connecting to port 60000. Did
you change the port number, or have you installed something between the
user and Solr?
If it's the embedded zookeeper port you are connecting to (which
defaults to port 9983, not 60000), Solr's use of zookeeper is almost
entirely unmodified. The embedded zookeeper server does currently have
code inside Solr that parses the configuration, rather than leaving that
part up to zookeeper itself, but the zookeeper server (and all its
networking) is not a part of Solr's code.
I also tried telnetting to the embedded zookeeper server that Solr (also
version 6.2.0) is capable of starting (on port 9983). It took a little
longer than Solr itself, about four minutes, but it did eventually
disconnect when there was no activity.
The latest version of Solr is 6.2.1, which is nearly identical to 6.2.0,
except for a few minor bugfixes, none of which would involve networking
code. All of the networking code for Solr is actually provided by other
projects -- Jetty and Zookeeper.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Dear Community,we find a Vulnerability in Zookeeper/SOLR/Apache(PHP)
about tcp connection exhausted,Waiting for your reply
Posted by Flavio P JUNQUEIRA <fp...@apache.org>.
Please read this:
http://zookeeper.apache.org/security.html
-Flavio
On 27 Oct 2016 20:16, "Linkezhang" <li...@huawei.com> wrote:
> *Problem:*
>
> In the client using some method (such as telnet) to establish a tcp
> connection with server-side apache listening port , but after the
> establishment of tcp connection, the client does not send any data.
> However, apache will not disconnect this tcp connection, may lead to the
> number of connections exhausted , Resulting in DOS
>
>
>
> *The attack process**：*
> 1. The client executes the telnet service port
>
> [image: cid:image001.png@01D23070.DA903540]
> Start the client telnet server port 60000, do not exit for a long time:
>
> Excuting an order:
> telnet 172.22.17.26 60000
>
>
>
Re: Dear Community,we find a Vulnerability in Zookeeper/SOLR/Apache(PHP)
about tcp connection exhausted,Waiting for your reply
Posted by Flavio P JUNQUEIRA <fp...@apache.org>.
Please read this:
http://zookeeper.apache.org/security.html
-Flavio
On 27 Oct 2016 20:16, "Linkezhang" <li...@huawei.com> wrote:
> *Problem:*
>
> In the client using some method (such as telnet) to establish a tcp
> connection with server-side apache listening port , but after the
> establishment of tcp connection, the client does not send any data.
> However, apache will not disconnect this tcp connection, may lead to the
> number of connections exhausted , Resulting in DOS
>
>
>
> *The attack process**：*
> 1. The client executes the telnet service port
>
> [image: cid:image001.png@01D23070.DA903540]
> Start the client telnet server port 60000, do not exit for a long time:
>
> Excuting an order:
> telnet 172.22.17.26 60000
>
>
>
Re: Dear Community,we find a Vulnerability in Zookeeper/SOLR/Apache(PHP)
about tcp connection exhausted,Waiting for your reply
Posted by Flavio P JUNQUEIRA <fp...@apache.org>.
Please read this:
http://zookeeper.apache.org/security.html
-Flavio
On 27 Oct 2016 20:16, "Linkezhang" <li...@huawei.com> wrote:
> *Problem:*
>
> In the client using some method (such as telnet) to establish a tcp
> connection with server-side apache listening port , but after the
> establishment of tcp connection, the client does not send any data.
> However, apache will not disconnect this tcp connection, may lead to the
> number of connections exhausted , Resulting in DOS
>
>
>
> *The attack process**：*
> 1. The client executes the telnet service port
>
> [image: cid:image001.png@01D23070.DA903540]
> Start the client telnet server port 60000, do not exit for a long time:
>
> Excuting an order:
> telnet 172.22.17.26 60000
>
>
>