rsyslogd terminal escape sequences injection

[Federico Bento]

Hi,

It seems to me that it is possible to inject terminal escape sequences into log files via
syslog(3)

# tail -f /var/log/messages

Aug 23 13:50:33 ghetto kernel: ACPI Error: Method parse/execution failed [\_GPE._L10]
(Node ffff88017b0e47d0), AE_NOT_FOUND (20141107/psparse-536)
(*) Aug 23 13:50:33 ghetto kernel: ACPI Exception: AE_NOT_FOUND, while evaluating GPE
method [_L10] (20141107/evgpe-581)

$ logger `printf 'HELLO\n\033[2AAAAAAAAAAAAAA\033[2B'`

# tail -f /var/log/messages

Aug 23 13:50:33 ghetto kernel: ACPI Error: Method parse/execution failed [\_GPE._L10]
(Node ffff88017b0e47d0), AE_NOT_FOUND (20141107/psparse-536)
(*) Aug 23 13:50:33 ghetto kernel: ACPI AAAAAAAAAAAAA_NOT_FOUND, while evaluating GPE
method [_L10] (20141107/evgpe-581)
Aug 23 13:50:39 ghetto saken: HELLO

On the (*) line, the escape sequence changed its contents, meaning that an unprivileged
user can take advantage of this to hide their presence on the system by changing
legitimate logs, modify a window's title, change background and foreground color, etc.

While researching this, I found that rsyslogd has "$EscapeControlCharactersOnReceive"
which claims that is on by default and that "The intent is to provide a way to stop
non-printable messages from entering the syslog system as whole."

On my system, this does not seem to be true, and actually went ahead and added
"$EscapeControlCharactersOnReceive on" to the /etc/rsyslog.conf file, restarted rsyslog
and the problem still persists.

I am using rsyslogd 7.4.8

Thanks,
Federico Bento.

[Seth Arnold (seth-arnold)]

This is a problem with using cat(1) or tail(1) to inspect potentially malicious files; less(1) does not interpret the control chars by default, so it's safer to use. Something like:

less +F /path/to/file
will behave similar to:
tail -f /path/to/file

For more information, see:

http://www.openwall.com/lists/oss-security/2015/08/11/8

Thanks

[Federico Bento (up201407890)]

Obviously.

Can anyone reproduce this though?

There's an actual feature to try and mitigate this and doesn't seem to work, atleast on my system.

[Tyler Hicks (tyhicks)]

I cannot reproduce this issue with rsyslog as shipped in Ubuntu 14.04 (7.4.4-1ubuntu2.6) or Ubuntu 16.04 (8.16.0-1ubuntu3). rsyslogd seems to be handling the control characters correctly.

$ tail -f /var/log/syslog
...
Dec 1 17:40:16 sec-xenial-amd64 tyhicks: HELLO #033[2AAAAAAAAAAAAAA#033[2B

Marking this bug as invalid as it isn't reproducible with Ubuntu's rsyslog package and, judging from the version (7.4.8), you seem to be running an rsyslogd from a third party or one that you built yourself.