Mailing List Archive

1 2  View All
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
Hi,

At the risk of wading into a discussion that I haven't followed closely:
the SSH protocol does include a language negotiation mechanism that
allows the server and client to agree on a language at KEXINIT time. Per
RFC4253 section 7.1

> languages
> This is a name-list of language tags in order of preference
> [RFC3066]. Both parties MAY ignore this name-list. If there
> are no language preferences, this name-list SHOULD be empty as
> defined in Section 5 of [SSH-ARCH]. Language tags SHOULD NOT
> be present unless they are known to be needed by the sending
> party.

Very few implementations have ever used this (maybe SunSSH did once?)
and OpenSSH doesn't attempt language negotiation at all.

It might be possible to work this protocol feature up to a proposal
for how it could be practically used to the problems mentioned in this
thread. Most of the OpenSSH developers lack the expertise needed to do
this, so if it ever happens then it will probably need to come from the
community.

IMO preparing an internet-draft would be a good way for someone
interested to start this conversation, since you'll want a standards
document at the end of the process to convince implementators to adopt
it.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
Christoph Anton Mitterer writes:
> On Fri, 2022-04-29 at 12:53 +0200, Ingo Schwarze wrote:
>> [...]
>> > But how could it use this to for code execution on the local
>> > machine?
>>
>> By the remote attacker sending whatever of
>>
>> https://invisible-island.net/xterm/ctlseqs/ctlseqs.html
>>
>> is most inconvenient for you, the user on the client? Good
>> luck making sure nothing from that next to interminable list
>> is inconvenient for you. Other terminals and terminal emulations
>> may have similar lists of in-band controls.
>
> Any concrete example which allows *local* (i.e. client side)
> execution of code/commands?

The closest one I know about:

https://unparalleled.eu/blog/2021/20210518-using-xterm-to-navigate-the-huge-color-space/

In the end it exploited an integer overflow in libx11, most likely
introduced in _1986_! The POC injects X11 protocol commands to gain
full control over your local desktop (injecting keystrokes, key
logging).


But in the end you do not even need that to compromise the client.
Terminals seem to be more designed with usability in mind than
security. That is understandable as 1) they are the main user
interface for text based communication and 2) terminals usually
are used to access local applications, so malicious input or
output most likely means, that it is game over already. So their
attack surface may be huge, not only the terminal code itself,
but also those functions invoked by it, e.g. UTF-8-decoding,
terminal control sequences and clipboard interacting with the
graphics system, window manager, other applications again listening
to those, ...


If I may voice an opinion, instead of having a complicated
"LANG LC_*" negotiation algorithm, I would more like to see
an integrated SSH data filter to run all unencrypted data
through before reaching the other side (both directions).

-o "TerminalDataFilter [some program]"

On a trusted server, the "LANG LC_*" usecase would be easy to
implement, as the filter could (hiddenly) negotiate whatever
it wants before doing plain input/output forwarding.

Paranoid users may use the filter instead for full data sanitation,
e.g. replacing all non-whitelisted control sequences, all parts
of UTF specification, they will not use anyway, ... with some
escape code (thus messing up the display, but I would rather like
to know when someone is trying to hit me than have a nice display).
Insanely paranoid user may even think of implementing an application
layer firewalling for terming-data, e.g. blocking unexpected
(e.g. very large) copy&paste inputs, whitelist the commands allowed
to be sent to the server, warn on known dangerous commands
(tail -f /var/log/syslog), ...

Kind regards,
hd
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
On Mon, 2022-05-02 at 08:25 +0000, halfdog wrote:
> > Any concrete example which allows *local* (i.e. client side)
> > execution of code/commands?
>
> https://unparalleled.eu/blog/2021/20210518-using-xterm-to-navigate-the-huge-color-space/

Interesting one...

> In the end it exploited an integer overflow in libx11, most likely
> introduced in _1986_! The POC injects X11 protocol commands to gain
> full control over your local desktop (injecting keystrokes, key
> logging).

... such a simple feature... where no one would have imagined that it
could lead to such big compromise.



> If I may voice an opinion, instead of having a complicated
> "LANG LC_*" negotiation algorithm, I would more like to see
> an integrated SSH data filter to run all unencrypted data
> through before reaching the other side (both directions).
>
> -o "TerminalDataFilter [some program]"

I've also had that in mind... thus specifically CCing Damien and Darren
so that they see this.

Can you guys imagine to extend ssh, so that when output is connected to
a terminal, it filters escape sequence (to a varying degree, depending
on some configuration setting)?

The default could be just as is, i.e. no filtering. But there could be
an option that allows to specify escape sequence filtering on a per
host basis.
The more the host is trusted, the more one could allow it.

E.g.
Host absolutely-untrusted.example.org
TerminalEscapeSequences !all

Host semi-trusted.example.org
TerminalEscapeSequences !all default

Host fully-trusted.example.org
TerminalEscapeSequences !all default clipboard


starting from the default ("all"), "!all" would first filtering really
all escape sequences (thereby probably breaking everyhing), "default"
would again allow some sequences that are generally considered safe...
and e.g. "clipboard" would specifically allow OSC52... or "links" which
would enable the OSC that makes hyperlinks, "!colours" could disable
any colour escape sequences, and so on.

There could be one "minimal", which is like "default" but without and
fancy stuff (e.g. no colours) just the bare minimum.


Any one could maybe another option, which controls when that filter
kicks in, e.g. never, when connected to a terminal, always (even if no
terminal is detected).


That would make sanitisation available out of the box for SSH users,
not requiring any thing else that cleans possibly problematic sequences
from untrusted remote nodes.


Terminal authors continue to add such features, that may have a
legitimate use case for local terminals, but could be dangerous when
these are controller by remote machines.
So such filtering on SSH level could be a further guard.


Cheers,
Chris.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
On Sat, 2022-04-30 at 03:36 -0400, Demi Marie Obenour wrote:
> The only remaining
> problem is client-side state being messed up, and the easiest
> solution
> to that is to destroy the PTY once the session is complete.

It's not only messing up. Consider you have copied some of your
passphrases into the clipboard, and a remote server can read it out via
some terminal command.

Cheers,
Chris.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
On 5/2/2022 9:05 PM, Christoph Anton Mitterer wrote:

> Can you guys imagine to extend ssh, so that when output is connected to
> a terminal, it filters escape sequence (to a varying degree, depending
> on some configuration setting)?

Fundamentally, you're asking for a firewall for your terminal because
you can't / won't run a secure client. Feel free to write one, but it
neither should nor needs to be part of OpenSSH. It's just a PTY/TTY
proxy, and would work just fine as a stand-alone app. If you really want
to integrate it, a better target would be something like screen or tmux,
so it protects against all malicious terminal apps.

--
Carson
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
On 01.05.22 01:07, Thorsten Glaser wrote:
> On Sun, 1 May 2022, Jochen Bern wrote:
>> If that's your opinion, go ahead and implement it. Which my suggestion of a
>> server-side helper evaluating the client-side-set and server-side-available
>> locales
>
> This could be… challenging. (There’s locale(1) -a, sure, but…)

Which part of it, a) getting the locally known locales, b) verifying
that they're indeed *operational* (OS knows it but your main app doesn't
support it), and/or c) selecting a compromise from them?

If a) and/or b), then that's already a problem in and of itself. What
good is locale support on just this *one* machine, not even doing any
remote connections, if the user has difficulties to pick the one he can
and wants to use?

(OK, we *are* talking about *human languages*. How many Germans, faced
with all "DE" locales being somehow missing/defunct, would know that
"Ripuarian" is actually a family of German dialects, and will likely be
mostly understandable to them ...)

c) is the problem we're trying to solve. Eggs, omelette. ;-)

> It also assumes locale support on both ends in the first place.

If the *client* lacks it, I would guess that $LANG and $LC_* are unset,
will be propagated empty to the server, and not offer any information on
the client and user whatsoever, with or without an attempt at negotiation.

If the *server* lacks it, there's no point in trying to select one on
the server side, anyway. The user will be faced with whatever passes as
the server's one and only locale, whether it's Greek to him or not.

>> I expect terminals to gravitate more and more towards implementing
>> it, increasing the pressure on the consortium to include two codepoints to
>> "shift to control" and "shift back" into its standards, laying the groundwork
>> of a *global* algorithm for terminals to tell control data from content.
>
> I highly doubt anything will change now, especially things that break
> compatibility.

How would the Unicode Consortium allocating two codepoints for *this*
purpose be any *more* prone to "breaking compatibiliy" than the
expansion of the emoji list every dozen months or so already is?

Quite to the contrary, it would open the possibility to have the server
side modify its emitted data from

<prnChar> <prnChar> <termCtl> <prnChar> <prnChar> ...

to

<prnChar> <prnChar> <toCtl> <termCtl> <toText> <prnChar> <prnChar> ...

so that a terminal aware of the <toCtl> and <toText> characters could
recognize <termCtl> as a control sequence *even if the sequence is not a
proper one for this term at all*.

Regards,
--
Jochen Bern
Systemingenieur

Binect GmbH
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
On 5/2/22 15:59, Carson Gaspar wrote:
>
>
> On 5/2/2022 9:05 PM, Christoph Anton Mitterer wrote:
>
>> Can you guys imagine to extend ssh, so that when output is connected to
>> a terminal, it filters escape sequence (to a varying degree, depending
>> on some configuration setting)?
>
> Fundamentally, you're asking for a firewall for your terminal because
> you can't / won't run a secure client. Feel free to write one, but it
> neither should nor needs to be part of OpenSSH. It's just a PTY/TTY
> proxy, and would work just fine as a stand-alone app. If you really want
> to integrate it, a better target would be something like screen or tmux,
> so it protects against all malicious terminal apps.

tmux to be specific; I believe screen is unmaintained.

--
Sincerely,
Demi Marie Obenour (she/her/hers)
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
On Mon, 2022-05-02 at 21:59 +0200, Carson Gaspar wrote:
> Fundamentally, you're asking for a firewall for your terminal because
> you can't / won't run a secure client.

I guess so ^^ ... but I haven't said whether or not I personally use
tmux - but I guess many people using ssh don't.

The main goal here should be to protect the average user, who has
likely no idea about possible subtle security issues with terminal
escape sequences.


> but it
> neither should nor needs to be part of OpenSSH. It's just a PTY/TTY
> proxy, and would work just fine as a stand-alone app.

Well, ssh is the client, that would actually "introduce" any unsafe
escape sequences to the system.

So it seems very well to be the appropriate location where such
filtering would be done, just to make sure that it is.

You also don't implement a firewall in the browser, the mail user
agent, etc. - you implement one centrally at the OS level.


> If you really want
> to integrate it, a better target would be something like screen or
> tmux,
> so it protects against all malicious terminal apps.

tmux ain't a firewall either.

And there may be many valid use cases (tmux without any remote
terminals) where people may want such escape sequences like OSC52 going
through.
IMO it's typically the "from remote" property that makes things really
critical.


Cheers,
Chris.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: AcceptEnv LANG LC_* vs available locales [ In reply to ]
On Mon, May 02, 2022 at 02:17:47PM PDT, Demi Marie Obenour wrote:
>On 5/2/22 15:59, Carson Gaspar wrote:
>>
>>
>> On 5/2/2022 9:05 PM, Christoph Anton Mitterer wrote:
>>
>>> Can you guys imagine to extend ssh, so that when output is connected to
>>> a terminal, it filters escape sequence (to a varying degree, depending
>>> on some configuration setting)?
>>
>> Fundamentally, you're asking for a firewall for your terminal because
>> you can't / won't run a secure client. Feel free to write one, but it
>> neither should nor needs to be part of OpenSSH. It's just a PTY/TTY
>> proxy, and would work just fine as a stand-alone app. If you really want
>> to integrate it, a better target would be something like screen or tmux,
>> so it protects against all malicious terminal apps.
>
>tmux to be specific; I believe screen is unmaintained.
>

This is getting somewhat tangential, but for what it's worth while I
recall screen development *was* fairly dead for a while, it had some
life breathed into it circa 2015 or so and has seen semi-regular
releases since then (most recently v4.9 in January).


Zev

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

1 2  View All