[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240403205835.GA12974@openwall.com>
Date: Wed, 3 Apr 2024 22:58:35 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: escaping terminal control characters (was Re: backdoor in upstream xz/liblzma leading to ssh server compromise)
On Wed, Apr 03, 2024 at 11:03:17AM +1100, Matthew Fernandez wrote:
> On 4/1/24 08:30, Solar Designer wrote:
> >On Sat, Mar 30, 2024 at 04:37:48PM -0000, Tavis Ormandy wrote:
> >>It was also pointed out they submitted an odd PR to libarchive:
> >>
> >>https://github.com/libarchive/libarchive/pull/1609
> >>
> >>In summary, they replaced calls to safe_fprintf() with fprintf() --
> >>meaning control characters are no longer filtered from errors. That
> >>seems pretty minor, but now that we know they were in the business of
> >>obfuscating the presence of backdoors -- seems a bit suspicious.
> >>
> >>Regardless, that change has now been reverted:
> >>
> >>https://github.com/libarchive/libarchive/pull/2101
> >
> >This does look minor indeed - not usable for large-scale attacks, and
> >libarchive is quite unique in that it even bothered to filter control
> >characters, whereas most command-line tools outputting filenames don't
> >bother. My guess is it could have been an early experiment to see
> >whether the project would accept PRs degrading security.
> >
> >That said, here's an excellent write-up by David Leadbeater on specific
> >ways that specific terminal emulators may be usefully attacked with
> >control sequences:
> >
> >https://dgl.cx/2023/09/ansi-terminal-security#vulnerabilities-using-known-replies
>
> Is the currently accepted wisdom that any application printing to
> stdout/stderr should take steps to avoid control characters in the
> output?
First, let's limit this to cases where the control characters come from
potentially untrusted input to the program. Obviously, many programs
generate terminal escapes on their own (usually via a library), for
their intended functionality (colorized listings, TUIs, etc.) Some
programs pass potential control characters from their trusted input.
Second, I think no, there isn't currently an established opinion on
whether programs should perform such filtering of untrusted input.
On Linux systems, the status quo appears to be that this is done for
process names by procps and for file names in the filesystem by GNU
coreutils. However, it is usually not done e.g. in (un)archivers and
package managers.
I think at least the package managers (by which I mean not only
lower-level e.g. rpm/dpkg, but also higher-level e.g. dnf/apt) should
catch up, especially for output they produce based on package contents
prior to verification of the package signature. The very fact they
choose to verify a signature means they consider the input untrusted, so
they shouldn't be trusting it for printing to a terminal either.
Some programs are commonly used non-interactively in scripts, but are
also commonly used interactively. For example, cat(1) must pass its
input to output verbatim by default, or it'd break scripts. But then
GNU coreutils "cat -v" will encode control characters in a
human-friendly notation. There are many other programs like this, and
most do not even have an option like that.
> This is one of those situations where, if my terminal is
> manipulated this way, I'm not quite sure who is to blame. Intuitively it
> does not seem to scale, to require every (even non-security minded)
> application to mitigate this. But on the other hand, maybe it's not
> possible for terminal emulators to solve without false positives.
Terminal emulators should avoid/remove support for truly dangerous
escape commands. But as long as they allow basic control commands such
as cursor movement, which they need to, they could still be manipulated
into relatively benign yet misleading behavior such as replacing
previously displayed messages with something else.
I wouldn't blame anyone since we arrived at this for good technical and
historical reasons. But there are many things we can do to mitigate
these issues - inside programs, in choice of which programs to use when
(e.g., "cat" vs. "less"), and in how to use them. On "less" options:
https://www.openwall.com/lists/oss-security/2016/04/22/2
Alexander
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.
