You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2019/03/12 14:48:00 UTC
[jira] [Commented] (SOLR-12891) Injection Dangers in Streaming
Expressions
[ https://issues.apache.org/jira/browse/SOLR-12891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790623#comment-16790623 ]
ASF subversion and git services commented on SOLR-12891:
--------------------------------------------------------
Commit 9edc557f4526ffbbf35daea06972eb2c595e692b in lucene-solr's branch refs/heads/master from Gus Heck
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9edc557 ]
SOLR-12891 MacroExpander will no longer will expand URL parameters by
default inside of the 'expr' parameter, add InjectionDefense class
for safer handling of untrusted data in streaming expressions and add
-DStreamingExpressionMacros system property to revert to legacy behavior
> Injection Dangers in Streaming Expressions
> ------------------------------------------
>
> Key: SOLR-12891
> URL: https://issues.apache.org/jira/browse/SOLR-12891
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
> Affects Versions: 7.5, 8.0
> Reporter: Gus Heck
> Assignee: Gus Heck
> Priority: Minor
> Labels: security
> Attachments: SOLR-12891.patch, SOLR-12891.patch, SOLR-12891.patch, SOLR-12891.patch, SOLR12819example.java
>
>
> I just spent some time fiddling with streaming expressions for fun, reading Erick Erickson's blog ([https://lucidworks.com/2017/12/06/streaming-expressions-in-solrj/)] and the example given in the ref guide ([https://lucene.apache.org/solr/guide/7_5/streaming-expressions.html#streaming-requests-and-responses)] and it occurred to me that we are recommending string concatenation into an expression language with the power to harm the server, or other network services visible from the server. I'm starting this Jira as a security issue to avoid creating a public impression of insecurity, feel free to undo that if I have guessed wrong. I haven't developed an exploit example, but it would go something like this:
> # Some portion of an expression is built including user supplied data using the techniques we're recommending in the ref guide
> # Malicious user constructs input data that breaks out of the expression (SOLR-10894 is relevant here), probably somewhere inside a let() expression where one could simply define an additional variable taking the value of a malicious expression...
> # update() expression is executed to add/overwrite data, jdbc() makes a JDBC connection to a database visible to the server, or the malicious expression executes some very expensive expression for DOS effect.
> Technically this is of course the fault of the end user who allowed unchecked input into programmatic execution, but when I think about how to check the input I realize that the only way to be sure is to construct for myself a notion of exactly how the parser behaves and then determine what needs to be escaped. To do this I need to dig into the expression parser code...
> How to escape input is also already unclear as shown by SOLR-10894
> There's another important wrinkle that would easily be missed by someone trying to construct their own escaping/protection system relating to parameter substitution as discussed here: SOLR-8458
> I think the solution to this is that SolrJ API should be enhanced to provide an escaping utility at a minimum and possibly a "prepared expression" similar to SQL prepared statements and call this issue to attention in the ref guide once these tools are available...
> Additionally, templating features might be a useful addition to help folks manage large expressions and facilitate re-use of patterns... such templating should also have this issue in mind when/if they are added.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org