[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAP145pjFHU2p2cYomcaMqjHBmq4t4_yOqmB_D9U9SWxr0UJagA@mail.gmail.com>
Date: Wed, 3 May 2017 15:41:04 +0200
From: Robert Święcki <robert@...ecki.net>
To: oss-security@...ts.openwall.com
Subject: Re: terminal emulators' processing of escape sequences
> On a slightly different note; memory corruption/abort() problems might
> end up as RCE with some effort, but what *is* RCE is ability to push
> back characters into terminal's input buffer. There are some
> well-known vectors, like setting title of the current terminal and
> printing it back with ESC codes, and hopefully it's something that is
> mitigated in all modern terminal emulator software packages for many
> years now.
>
> But, it's not something that can be discovered simply by waiting for
> SEGV and similar signals. Hence, I'd like to encourage everyone
> looking for bugs in terminal emulators to add some form of
> instrumentation to their fuzz setups aimed at finding such problems
> too.
>
> A harmless example from rxvt - pushing back the new-line character:
>
> $ echo -ne "\eGQ;"
> ;$ 0
> bash: 0: command not found
For those interested in high-speed terminal emulator fuzzing
(typically 300k-700k inputs/sec on a modern i7-6600K), I prepared a
short step-by-step guide:
https://github.com/google/honggfuzz/tree/master/examples/terminal-emulators
--
Robert Święcki
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
