Disable ANSI escape codes

[wpb162]

I am unaware of how to filter or disable the processing of ANSI escape codes as recommended by Splunk, due to the recently announced log injection vulnerability. We have a clustered environment running 9.0.5 on AWS EC2 instances running Linux.

How can I implement these recommendations?

[PickleRick · Accepted solution]

There could be a long introduction about history of terminals and so on... But I'll just post a link to a fairly good wikipedia article - https://en.wikipedia.org/wiki/ANSI_escape_code

Long story short - the ANSI escape codes processing in this case refers not to some functionality within Splunk but to the functionality of the terminal you're using.

For the vulnerability to be exploited a specific sequence of events must happen:

1. The ANSI codes are injected (for now let's not dwell into how they are put there) into a log file

2. The log file is read from a predictive (from attacker's point of view) environment - typically a CLI interface running shell on a terminal that inteprets ANSI escape codes using a tool which does not sanitize the data before passing it to the terminal.

In such case the escape codes are passed unaltered to the terminal (xterm, konsole, putty, mobaxterm and so on) which might, depending on its settings interpret them. Unfortunately for us, in this case, while the typical use for ANSI codes is making terminal output colorized/bold/underline/blinking or moving cursor around the screen, some extended escape codes can be abused to interact with your terminal session.

There are two ways to mitigate this:

1) Use a terminal emulator which does not intepret (at least some particuar subset of) those ANSI codes. This option might be tricky and is usually not that well documented. Some programs have easily available options for at least some of that - like putty's Terminal->Features config section, some don't and will happily work on any ANSI codes they get.

In case of unices, setting terminal type to "dumb" type before connecting to remote system via SSH might help mitigate this threat somewhat. The downside is that it limits your display capabilities.

2) Use a tool which sanitizes input before displaying it. The easiest way to do so would be to use the "less" command instead of "cat" or "tail" to view your files. While cat and tail just copy input to output without much processing, less tries to keep things civil by displaying the contents as "printable".

Be aware however that it doesn't mean that you don't get to see unfiltered text as output from - for example - grep command. In such case it's again relatively safe to pipe your grep output to less command.

EDIT: I suppose you could use tmux or screen with a proper terminal type to filter some of the ANSI codes. I haven't tested it though.

[anel]

Not sure if this is exactly the same topic, but here is a good explanation about how to abuse Terminal Emulators with ANSI Escape Characters. 

https://www.cyberark.com/resources/threat-research-blog/dont-trust-this-title-abusing-terminal-emula...

[richgalloway]

The method for disabling ANSI escape codes depends on the terminal program you use (putty, etc.).  It's not a Splunk change/feature.