prevent inclusion of stack trace in response (leak of detailed error information)

[rursprung]

Is your feature request related to a problem? Please describe.
there are currently two options to include a stack trace in the server response in case of errors:

• set the http.detailed_errors.enabled config option (undocumented for OpenSearch, documented for ES 7.10.2)
• add the error_trace=true URL parameter (see the OpenSearch documentation)

the former can only be done by a system administrator, however the latter can be done by anyone who can call OpenSearch.

thus, when an exception is raised, the following parameter can be added to the request URL to include the error stack trace in the response error_trace=true

Example Request:

GET /opensearch/_search?error_trace=true

Such technical details are not supposed to be visible to clients as it does not provide any added value. To an attacker however, this information might give valuable hints as to which frameworks and libraries are used by the web application. Apart from that, technical details can help in the analysis of errors and simplify the search for security issues.

Describe the solution you'd like
Because the client should only receive information that is necessary to handle the error, it should be possible to disable the corresponding parameter globally using a config option.

i could e.g. imagine changing http.detailed_errors.enabled from a boolean parameter to an enum in a backwards compatible way so that it accepts false (by default no trace is printed, the HTTP param is accepted), true (trace printed by default) and disabled (HTTP param is ignored, trace is never printed).

Describe alternatives you've considered
arguing with the security reviewers about the finding is usually not the best alternative 😆

Additional context
scoring acc. to our reviewers:

CVSS 3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N CVSS Base Score: 5.3

note: i'm raising this as a feature request instead reporting it via email as a security issue as it is IMHO not a direct security problem and thus can be discussed openly. in a proper setup OpenSearch should also not be reachable from the outside, i.e. this can only be exploited if the attacker is already in the network.

[BhumikaSaini-Amazon]

Should this have been reported via the channels outlined in https://github.com/opensearch-project/OpenSearch/blob/main/SECURITY.md first, to avoid a false negative?

[rursprung]

Should this have been reported via the channels outlined in https://github.com/opensearch-project/OpenSearch/blob/main/SECURITY.md first, to avoid a false negative?

as written in my initial post, i explicitly decided against this as it isn't a (direct) attack vector. it's just reporting a bit more information than what is considered prudent by security experts. think of it more like a webserver (apache, nginx, etc.) which reports its exact version and the versions of all installed modules on error pages (which is something generally disabled on a hardened environment).

[xuezhou25]

The documentation for ES 7.10.2 might have some mistake(It is documented right on ES 8.4) about the option to include error_trace in the server response by setting the http.detailed_errors.enabled: false

When the config setting http.detailed_errors.enabled: false, the request of error_trace=true will return 400 error.

$ curl "http://localhost:9200/opensearch/_search?error_trace=false"
{"error":"IndexNotFoundException[no such index [opensearch]]","status":404}

$ curl "http://localhost:9200/opensearch/_search?error_trace=true" 
{"error":"error traces in responses are disabled.","status":400}   

This code regarding to this setting is from: https://github.com/opensearch-project/OpenSearch/blob/2.2.1/server/src/main/java/org/opensearch/rest/RestController.java#L368-L375

When there is no config setting for http.detailed_errors.enabled or http.detailed_errors.enabled: true, the response of URL parameter is:

$ curl "http://localhost:9200/opensearch/_search?error_trace=true&pretty"
{
  "error" : {
    "root_cause" : [
      {
        "type" : "index_not_found_exception",
        "reason" : "no such index [opensearch]",
        "index" : "opensearch",
        "resource.id" : "opensearch",
        "resource.type" : "index_or_alias",
        "index_uuid" : "_na_",
        "stack_trace" : "[opensearch] IndexNotFoundException[no such index [opensearch]]\n\tat org.opensearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.indexNotFoundException(IndexNameExpressionResolver.java:1067)\n\tat org.opensearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.innerResolve(IndexNameExpressionResolver.java:1004)

I think this can solve your concern @rursprung What's your opinion?

[anasalkouz]

@xuezhou25 could you please add this to OpenSearch Documentation?

[xuezhou25]

Raised an issue on Documentation Repo to update the error_trace URL parameter description.

[rursprung]

thanks for checking this, @xuezhou25! i've verified that http.detailed_errors.enabled: false works as expected on OpenSearch 2.x.
i'm fine with closing this issue in favour of opensearch-project/documentation-website#1235 - feel free to close it if you agree with this.

[rursprung]

small update: http.detailed_errors.enabled does more than just prevent the inclusion of the stack trace / the usage of the error_trace parameter: it also suppresses (sometimes vital) information from error messages. see #4545

[xuezhou25]

Closing this by tracking on 1235