lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cassandra Targett (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SOLR-12891) Injection Dangers in Streaming Expressions
Date Tue, 08 Jan 2019 21:49:00 GMT

     [ https://issues.apache.org/jira/browse/SOLR-12891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Cassandra Targett updated SOLR-12891:
-------------------------------------
    Priority: Minor  (was: Blocker)

> 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
>            Priority: Minor
>              Labels: security
>         Attachments: 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


Mime
View raw message