[
https://issues.apache.org/jira/browse/SOLR-15330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380784#comment-17380784
]
Michael Gibney commented on SOLR-15330:
---------------------------------------
Sorry for the delayed response. I _would_ guess this is likely to interact with
SOLR-13336 in some way; particularly if by "doesn't happen on 8.8" you mean
"doesn't crash the servers on 8.8" -- fwiw the fix for SOLR-13336 should still
result in these types of queries failing (throwing an exception), but should
prevent them from taking down clusters.
That said, I'm still a bit uncertain: I was kind of expecting the query-time
analysis chain to be capable of producing a graph, but as best I can tell, the
chain you posted would _not_ produce a graph. Is it possible that there are
other fieldTypes involved, with different query-time analysis? If there's no
"smoking gun" graph-producing query-time analysis chain, then some _other_
component may have been constructing enormous boolean queries as a consequence
of this input? Perhaps even an issue in some other component that was
incidentally fixed between 7.5 and 8.8?
These are complete shots in the dark, but I'm not sure what else can be done
with the information available. If 8.8 fixes the issue for you, then perhaps it
makes sense to not sink further energy into this issue. On the other hand, now
that your clusters aren't crashing, if that means you're getting proper
exceptions thrown for this kind of input, the stack traces could help
illuminate the underlying cause. If in your logs you're getting stack traces
for this type of input and post them, I'd be happy to take a look.
> Solr 7.5 memory leak and crash with sql injection type queries
> --------------------------------------------------------------
>
> Key: SOLR-15330
> URL: https://issues.apache.org/jira/browse/SOLR-15330
> Project: Solr
> Issue Type: Bug
> Components: query, Server
> Affects Versions: 7.5
> Environment: Java 8 on CentOS 7.
> Reporter: Jitesh J Vidhani
> Priority: Major
>
> We have a set of standalone solr nodes running on Solr 7.5. We recently had a
> few episodes where the entire cluster crashed and died all together. Digging
> in a little, we found the culprits were some SQL injection attacks happening
> on our site where the search term had SQL injection in it and that was fed
> into the q param in solr. I was able to take a stable solr and isolate it and
> just run 1 query and make it crash. Every time I would run a regular query
> and see it work and then just change the q= parameter and that would time out
> and eventually crash the solr instance. Here is the q param for the query I
> ran:
> q=-6792)))+UNION+ALL+SELECT+NULL,NULL,NULL,NULL,CHR(113)||CHR(98)||CHR(118)||CHR(113)||CHR(113)||CHR(104)||CHR(68)||CHR(86)||CHR(114)||CHR(109)||CHR(97)||CHR(89)||CHR(89)||CHR(112)||CHR(76)||CHR(90)||CHR(105)||CHR(113)||CHR(86)||CHR(102)||CHR(97)||CHR(108)||CHR(89)||CHR(83)||CHR(81)||CHR(107)||CHR(69)||CHR(111)||CHR(97)||CHR(75)||CHR(87)||CHR(68)||CHR(108)||CHR(73)||CHR(68)||CHR(86)||CHR(118)||CHR(101)||CHR(71)||CHR(78)||CHR(106)||CHR(106)||CHR(76)||CHR(65)||CHR(82)||CHR(113)||CHR(106)||CHR(98)||CHR(98)||CHR(113)+FROM+DUAL--+gKiW
> I even stripped out the "||" characters and replaced them with "," and it
> still crashes. Please note these were SQL injection attacks and not real good
> queries. The Solr GC log exposes the problem and shows the memory footprint
> ballooning (from 2GB to 18GB within a minute) to the point where full garbage
> collection fails and the Solr instance is unresponsive. So 1 query is able to
> push it to the tipping point and consume 18GB of memory.
> I have tried searching for long description texts but that works fine. So
> something with these characters is probably causing this. Does anyone know
> how/why this might be happening?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
