Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NPE in _analyze api in 6.5.4 with security #38097

Closed
markharwood opened this issue Jan 31, 2019 · 6 comments
Closed

NPE in _analyze api in 6.5.4 with security #38097

markharwood opened this issue Jan 31, 2019 · 6 comments
Assignees
Labels
>bug :Search Relevance/Analysis How text is split into tokens :Security/Audit X-Pack Audit logging Team:Search Relevance Meta label for the Search Relevance team in Elasticsearch v6.5.4

Comments

@markharwood
Copy link
Contributor

A user has reported that this causes a NullPointerException

POST _analyze?error_trace=true
{
  "tokenizer": "standard",
  "text": "The foo_bar_size's is 5."
}

@eedugon has reproduced but it would not reproduce for me on 6.5.4 without security.
The reported stack trace starts with security performing a filter for index names

java.lang.NullPointerException: null
		at org.apache.lucene.util.automaton.CharacterRunAutomaton.run(CharacterRunAutomaton.java:47) ~[lucene-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - jimczi - 2018-09-18 13:01:13]
		at org.elasticsearch.xpack.core.security.support.Automatons$1.test(Automatons.java:213) ~[?:?]
		at org.elasticsearch.xpack.core.security.support.Automatons$1.test(Automatons.java:210) ~[?:?]
		at java.util.stream.MatchOps$1MatchSink.accept(MatchOps.java:90) ~[?:1.8.0_161]
		at java.util.Spliterators$ArraySpliterator.tryAdvance(Spliterators.java:958) ~[?:1.8.0_161]
		at java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:126) ~[?:1.8.0_161]
		at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:498) ~[?:1.8.0_161]
		at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:485) ~[?:1.8.0_161]
		at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) ~[?:1.8.0_161]
		at java.util.stream.MatchOps$MatchOp.evaluateSequential(MatchOps.java:230) ~[?:1.8.0_161]
		at java.util.stream.MatchOps$MatchOp.evaluateSequential(MatchOps.java:196) ~[?:1.8.0_161]
		at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:1.8.0_161]
		at java.util.stream.ReferencePipeline.allMatch(ReferencePipeline.java:454) ~[?:1.8.0_161]
		at org.elasticsearch.xpack.security.audit.logfile.LoggingAuditTrail$EventFilterPolicy.lambda$ignorePredicate$1(LoggingAuditTrail.java:860) ~[?:?]
...

..note however that this REST call does not target an index which is likely the source of the problem.

@markharwood markharwood added >bug :Search Relevance/Analysis How text is split into tokens :Security/Audit X-Pack Audit logging v6.5.4 labels Jan 31, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search

@albertzaharovits albertzaharovits self-assigned this Jan 31, 2019
@markharwood
Copy link
Contributor Author

@albertzaharovits apparently @eedugon has not reproduced. My bad.
The issue seems like there may be something environmental to it. User has 2 self hosted systems with same setup but one started exhibiting this problem where previously it worked OK.

@albertzaharovits
Copy link
Contributor

@markharwood I have reproduced it. You are right with your assumption about the indices request with a null index ;) I will have a fix soon.

@markharwood
Copy link
Contributor Author

markharwood commented Jan 31, 2019

@albertzaharovits
Great, thanks! I presume adding any accessible index name into the URL would be a temporary workaround? (Bearing in mind they're testing with core's standard tokenizer)

@albertzaharovits
Copy link
Contributor

@markharwood

I presume adding any accessible index name into the URL would be a temporary workaround? (Bearing in mind they're testing with core's standard tokenizer)

Yes, that is correct!

albertzaharovits added a commit that referenced this issue Feb 3, 2019
The culprit in #38097 is an `IndicesRequest` that has no indices,
but instead of `request.indices()` returning `null` or `String[0]`
it returned `String[] {null}` . This tripped the audit filter.

I have addressed this in two ways:
1. `request.indices()` returning `String[] {null}` is treated as `null`
    or `String[0]`, i.e. no indices
2. `null` values among the roles and indices lists, which are
    unexpected, will never again stumble the audit filter; `null` values
    are treated as special values that will not match any policy,
    i.e. their events will always be printed.

Closes #38097
albertzaharovits added a commit to albertzaharovits/elasticsearch that referenced this issue Feb 3, 2019
The culprit in elastic#38097 is an `IndicesRequest` that has no indices,
but instead of `request.indices()` returning `null` or `String[0]`
it returned `String[] {null}` . This tripped the audit filter.

I have addressed this in two ways:
1. `request.indices()` returning `String[] {null}` is treated as `null`
    or `String[0]`, i.e. no indices
2. `null` values among the roles and indices lists, which are
    unexpected, will never again stumble the audit filter; `null` values
    are treated as special values that will not match any policy,
    i.e. their events will always be printed.

Closes elastic#38097
albertzaharovits added a commit to albertzaharovits/elasticsearch that referenced this issue Feb 3, 2019
The culprit in elastic#38097 is an `IndicesRequest` that has no indices,
but instead of `request.indices()` returning `null` or `String[0]`
it returned `String[] {null}` . This tripped the audit filter.

I have addressed this in two ways:
1. `request.indices()` returning `String[] {null}` is treated as `null`
    or `String[0]`, i.e. no indices
2. `null` values among the roles and indices lists, which are
    unexpected, will never again stumble the audit filter; `null` values
    are treated as special values that will not match any policy,
    i.e. their events will always be printed.

Closes elastic#38097
albertzaharovits added a commit that referenced this issue Feb 3, 2019
The culprit in #38097 is an `IndicesRequest` that has no indices,
but instead of `request.indices()` returning `null` or `String[0]`
it returned `String[] {null}` . This tripped the audit filter.

I have addressed this in two ways:
1. `request.indices()` returning `String[] {null}` is treated as `null`
    or `String[0]`, i.e. no indices
2. `null` values among the roles and indices lists, which are
    unexpected, will never again stumble the audit filter; `null` values
    are treated as special values that will not match any policy,
    i.e. their events will always be printed.

Closes #38097
albertzaharovits added a commit that referenced this issue Feb 3, 2019
The culprit in #38097 is an `IndicesRequest` that has no indices,
but instead of `request.indices()` returning `null` or `String[0]`
it returned `String[] {null}` . This tripped the audit filter.

I have addressed this in two ways:
1. `request.indices()` returning `String[] {null}` is treated as `null`
    or `String[0]`, i.e. no indices
2. `null` values among the roles and indices lists, which are
    unexpected, will never again stumble the audit filter; `null` values
    are treated as special values that will not match any policy,
    i.e. their events will always be printed.

Closes #38097
albertzaharovits added a commit that referenced this issue Feb 3, 2019
The culprit in #38097 is an `IndicesRequest` that has no indices,
but instead of `request.indices()` returning `null` or `String[0]`
it returned `String[] {null}` . This tripped the audit filter.

I have addressed this in two ways:
1. `request.indices()` returning `String[] {null}` is treated as `null`
    or `String[0]`, i.e. no indices
2. `null` values among the roles and indices lists, which are
    unexpected, will never again stumble the audit filter; `null` values
    are treated as special values that will not match any policy,
    i.e. their events will always be printed.

Closes #38097
@javanna javanna added the Team:Search Relevance Meta label for the Search Relevance team in Elasticsearch label Jul 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug :Search Relevance/Analysis How text is split into tokens :Security/Audit X-Pack Audit logging Team:Search Relevance Meta label for the Search Relevance team in Elasticsearch v6.5.4
Projects
None yet
Development

No branches or pull requests

4 participants