[BUG] Bad characters in document causes Search Error

[albgus]

Describe the bug

Trying to search logs with certain illegal characters causes a Search Error. This means that logs submitted by malicious actors or exploit hunters may cause a kind of Denial of Service of OpenSearch dashboards.

The error shown is this:

SyntaxError: Bad escaped character in JSON at position 410488 (line 1 column 410489)
    at fetch_Fetch.fetchResponse (https://staging-opensearch.i.example.com/7969/bundles/core/core.entry.js:15:391967)
    at async interceptResponse (https://staging-opensearch.i.example.com/7969/bundles/core/core.entry.js:15:386867)
    at async https://staging-opensearch.i.example.com/7969/bundles/core/core.entry.js:15:389834

The offending message is this:

"message": "client sent invalid method while reading client request line, client: 10.x.x.x, server: _, request: \"\x03\0\0/*�\0\0\0\0\0Cookie: mstshash=Administr\"",

Specifically it seems to be \x03 (ASCII End of text) that triggers the error (column 410489 is exactly at the start of the escape sequence).

Expected behavior OpenSearch dashboards should be able to safely handling logs, even for sources that may be connected to the internet and receive malicious data.

OpenSearch Version 2.17.1

Dashboards Version 2.17.1

Plugins

Please list all plugins currently enabled.

Screenshots

If applicable, add screenshots to help explain your problem.

Host/Environment (please complete the following information):

• OS: macOS 14.7
• Browser and version: Google Chrome 130.0.6723.69

[dblock]

[Catch All Triage - 1, 2, 3, 4]

[cwperks]

@ashwin-pc Could you take a look at this issue?

[AMoo-Miki]

I am having trouble reproducing this as I am unable to get \x03 in to a doc. OSD and JS client convert that to \u0003 and curl just fails.

I am not giving up though. If you have any tips on how to get it in, plz share.

Also, when you say "search", do you mean just opening it in Discover or anything more?

[ashwin-pc]

Thanks for reporting this issue. After analyzing the impact, here's my assessment:

Impact Analysis:

• The issue only affects searching logs that contain ETX (\x03) characters from external HTTP requests
• The infrastructure and search users are trusted; the only untrusted input is the original HTTP request data being logged
• Primary impact is on incident investigation capabilities when searching logs containing these specific characters
• Not a full DoS vector as it requires:
  1. External clients to send requests with ETX characters
  2. Those requests to be logged
  3. Someone to search for logs containing those specific requests

Important Note on Client Safety: Multiple OpenSearch clients handle these characters safely: (JS, python) JS client automatically converts \x03 to \u0003. need to look to see which clients do not.

Suggested Priority: MEDIUM

• Not a direct security vulnerability as it requires no compromise of trusted components
• Cannot be triggered through normal OpenSearch client interactions
• Workarounds available:
  1. Filter/escape these characters at log ingestion time

Let me know if any of my assumptions used in my analysis here are incorrect