cve-2017-

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

cve-2017-

Jeff Courtade
This particular cve came out in the mailing list. Fed 12th


CVE-2017-3164 SSRF issue in Apache Solr

 I need to know what the exploit for this could be?


can a user send a bogus shards param via a web request and get a local file?


What does an attack vector look like for this?


I am being asked specifically this...


-          How would we know if the vulnerability in the Solr CVE was
taking advantage of? What are signs of us being exploited? What is the
worst case scenario with this CVE?

Could someone help me answer this please?



http://mail-archives.apache.org/mod_mbox/www-announce/201902.mbox/%3CCAECwjAVjBN=wO5rYs6ktAX-5=-f5JDFwbbTSM2TTjEbGO5jKKA@...%3E



the bug is



https://issues.apache.org/jira/browse/SOLR-12770



the mitigation is upgrading to solr 7.7
Reply | Threaded
Open this post in threaded view
|

Re: cve-2017-

Tomás Fernández Löbbe
I updated the description of SOLR-12770
<https://issues.apache.org/jira/browse/SOLR-12770> a bit. The problem
stated is that, since the "shards" parameter allows any URL, someone could
make an insecure Solr instance hit some other (secure) web endpoint. Solr
would throw an exception, but the error may include information from such
endpoint (parsing error). I don't believe this would allow access to a
local file (though, if you know of a way, please report to
[hidden email])

The only way to know (to my knowledge) if your Solr instance was affected
is by looking at your Solr logs. If you log queries, you should be able to
see what's being included in the "shards" parameter and detect something
that's not looking right. Also, if Solr is fooled to hit some other
endpoint, it would fail with a parsing error, so you should probably see
exceptions in your logs. The worst case, I guess, depends on how much
access the Solr process has and how much damage it can cause to an adjacent
web endpoint via a GET request.

Note that this can only impact you if your Solr instance can be directly
accessed by untrusted sources.

HTH

On Thu, Feb 28, 2019 at 11:54 AM Jeff Courtade <[hidden email]>
wrote:

> This particular cve came out in the mailing list. Fed 12th
>
>
> CVE-2017-3164 SSRF issue in Apache Solr
>
>  I need to know what the exploit for this could be?
>
>
> can a user send a bogus shards param via a web request and get a local
> file?
>
>
> What does an attack vector look like for this?
>
>
> I am being asked specifically this...
>
>
> -          How would we know if the vulnerability in the Solr CVE was
> taking advantage of? What are signs of us being exploited? What is the
> worst case scenario with this CVE?
>
> Could someone help me answer this please?
>
>
>
>
> http://mail-archives.apache.org/mod_mbox/www-announce/201902.mbox/%3CCAECwjAVjBN=wO5rYs6ktAX-5=-f5JDFwbbTSM2TTjEbGO5jKKA@...%3E
>
>
>
> the bug is
>
>
>
> https://issues.apache.org/jira/browse/SOLR-12770
>
>
>
> the mitigation is upgrading to solr 7.7
>
Reply | Threaded
Open this post in threaded view
|

Re: cve-2017-

Walter Underwood
Thanks, very helpful. We make an internal Jira for every Solr vulnerability and I was checking this one out this week.

wunder
Walter Underwood
[hidden email]
http://observer.wunderwood.org/  (my blog)

> On Feb 28, 2019, at 9:23 PM, Tomás Fernández Löbbe <[hidden email]> wrote:
>
> I updated the description of SOLR-12770
> <https://issues.apache.org/jira/browse/SOLR-12770> a bit. The problem
> stated is that, since the "shards" parameter allows any URL, someone could
> make an insecure Solr instance hit some other (secure) web endpoint. Solr
> would throw an exception, but the error may include information from such
> endpoint (parsing error). I don't believe this would allow access to a
> local file (though, if you know of a way, please report to
> [hidden email])
>
> The only way to know (to my knowledge) if your Solr instance was affected
> is by looking at your Solr logs. If you log queries, you should be able to
> see what's being included in the "shards" parameter and detect something
> that's not looking right. Also, if Solr is fooled to hit some other
> endpoint, it would fail with a parsing error, so you should probably see
> exceptions in your logs. The worst case, I guess, depends on how much
> access the Solr process has and how much damage it can cause to an adjacent
> web endpoint via a GET request.
>
> Note that this can only impact you if your Solr instance can be directly
> accessed by untrusted sources.
>
> HTH
>
> On Thu, Feb 28, 2019 at 11:54 AM Jeff Courtade <[hidden email]>
> wrote:
>
>> This particular cve came out in the mailing list. Fed 12th
>>
>>
>> CVE-2017-3164 SSRF issue in Apache Solr
>>
>> I need to know what the exploit for this could be?
>>
>>
>> can a user send a bogus shards param via a web request and get a local
>> file?
>>
>>
>> What does an attack vector look like for this?
>>
>>
>> I am being asked specifically this...
>>
>>
>> -          How would we know if the vulnerability in the Solr CVE was
>> taking advantage of? What are signs of us being exploited? What is the
>> worst case scenario with this CVE?
>>
>> Could someone help me answer this please?
>>
>>
>>
>>
>> http://mail-archives.apache.org/mod_mbox/www-announce/201902.mbox/%3CCAECwjAVjBN=wO5rYs6ktAX-5=-f5JDFwbbTSM2TTjEbGO5jKKA@...%3E
>>
>>
>>
>> the bug is
>>
>>
>>
>> https://issues.apache.org/jira/browse/SOLR-12770
>>
>>
>>
>> the mitigation is upgrading to solr 7.7
>>

Reply | Threaded
Open this post in threaded view
|

Re: cve-2017-

Jeff Courtade
In reply to this post by Tomás Fernández Löbbe
Thank you very much

On Fri, Mar 1, 2019 at 12:24 AM Tomás Fernández Löbbe <[hidden email]>
wrote:

> I updated the description of SOLR-12770
> <https://issues.apache.org/jira/browse/SOLR-12770> a bit. The problem
> stated is that, since the "shards" parameter allows any URL, someone could
> make an insecure Solr instance hit some other (secure) web endpoint. Solr
> would throw an exception, but the error may include information from such
> endpoint (parsing error). I don't believe this would allow access to a
> local file (though, if you know of a way, please report to
> [hidden email])
>
> The only way to know (to my knowledge) if your Solr instance was affected
> is by looking at your Solr logs. If you log queries, you should be able to
> see what's being included in the "shards" parameter and detect something
> that's not looking right. Also, if Solr is fooled to hit some other
> endpoint, it would fail with a parsing error, so you should probably see
> exceptions in your logs. The worst case, I guess, depends on how much
> access the Solr process has and how much damage it can cause to an adjacent
> web endpoint via a GET request.
>
> Note that this can only impact you if your Solr instance can be directly
> accessed by untrusted sources.
>
> HTH
>
> On Thu, Feb 28, 2019 at 11:54 AM Jeff Courtade <[hidden email]>
> wrote:
>
> > This particular cve came out in the mailing list. Fed 12th
> >
> >
> > CVE-2017-3164 SSRF issue in Apache Solr
> >
> >  I need to know what the exploit for this could be?
> >
> >
> > can a user send a bogus shards param via a web request and get a local
> > file?
> >
> >
> > What does an attack vector look like for this?
> >
> >
> > I am being asked specifically this...
> >
> >
> > -          How would we know if the vulnerability in the Solr CVE was
> > taking advantage of? What are signs of us being exploited? What is the
> > worst case scenario with this CVE?
> >
> > Could someone help me answer this please?
> >
> >
> >
> >
> >
> http://mail-archives.apache.org/mod_mbox/www-announce/201902.mbox/%3CCAECwjAVjBN=wO5rYs6ktAX-5=-f5JDFwbbTSM2TTjEbGO5jKKA@...%3E
> >
> >
> >
> > the bug is
> >
> >
> >
> > https://issues.apache.org/jira/browse/SOLR-12770
> >
> >
> >
> > the mitigation is upgrading to solr 7.7
> >
>