Mailing List Archive

On Lunes 17 Agosto 2009 15:48:18 Thomas K Gamble escribió:
> I have noticed that, beginning with the 5.1p1 release, ssh no longer
> interprets ansi escape sequences embeded in the /etc/banner or /etc/issue
> files. Was this deliberate, perhaps due to some security issue, or is this
> a bug that has crept into the code? I can't find anything in the changelog
> that would be related to this.
>

Thomas, i really don't know if the people developing openssh no longer
support ansi on ssh client by security reasons.

One thing is for sure.... Vt-100 escape characters (i mean \033 character)
represent a potential vulnerability on client side sometimes.

Why?

Well, maybe not now, but, a couple years ago in some xterm+bash2
configurations, escape characters enable you to exploit a bug that permit code
execution. Combined with ssh, you could name it: remote code execution.

And more... some systems enable escape characters to do some things that could
be considered privileged.

And moreover... if you try on previous versions of ssh (with escape chars)...
you could dissapear the prompt on the remote host (putting the same color on
background and foreground with escape chars)... That could be considered a
"innocent experiment", but is nasty.

Moreover, try to cat some of "urandom", and then, in some recent systems,
(maybe a 1 or 2 years ago systems), see how the bash prompt changed... And see
how sometimes things are executed after the ctlr-c



> I have verified that the 5.0p1 release and earlier do indeed interpret the
> ansi escape sequences properly.

--
Ing. Aaron G. Mizrachi P.

http://www.unmanarc.com
Mobil 1: + 58 416-6143543
Mobil 2: + 58 424-2412503
BBPIN: 0x 247066C1

On Monday 17 August 2009 02:57:01 pm you wrote:
> On Lunes 17 Agosto 2009 15:48:18 Thomas K Gamble escribió:
> > I have noticed that, beginning with the 5.1p1 release, ssh no longer
> > interprets ansi escape sequences embeded in the /etc/banner or /etc/issue
> > files. Was this deliberate, perhaps due to some security issue, or is
> > this a bug that has crept into the code? I can't find anything in the
> > changelog that would be related to this.
>
> Thomas, i really don't know if the people developing openssh no longer
> support ansi on ssh client by security reasons.
>
> One thing is for sure.... Vt-100 escape characters (i mean \033 character)
> represent a potential vulnerability on client side sometimes.
>
> Why?
>
> Well, maybe not now, but, a couple years ago in some xterm+bash2
> configurations, escape characters enable you to exploit a bug that permit
> code execution. Combined with ssh, you could name it: remote code
> execution.
>
> And more... some systems enable escape characters to do some things that
> could be considered privileged.
>
> And moreover... if you try on previous versions of ssh (with escape
> chars)... you could dissapear the prompt on the remote host (putting the
> same color on background and foreground with escape chars)... That could be
> considered a "innocent experiment", but is nasty.
>
> Moreover, try to cat some of "urandom", and then, in some recent systems,
> (maybe a 1 or 2 years ago systems), see how the bash prompt changed... And
> see how sometimes things are executed after the ctlr-c

After doing some more digging, I found that there is a function in the ssh
source (specifically sshconnect2.c) called "input_userauth_banner" that
displays the banner from the server. The text of the banner is now being
filtered through another function called "strnvis" that encodes non-printable
ascii characters as printable text, ie: octal codes. This is why the ansi
escape sequence is displayed as "\033[.". The documentation for strnvis
doesn't mention any security issues, only "unexpected behavior" that could be
associated with non-printable characters.

The only mention of this change to the ssh code is this rather terse entry in
the changelog:

- djm@cvs.openbsd.org 2008/07/17 08:48:00
[sshconnect2.c]
strnvis preauth banner; pointed out by mpf@ ok markus@

I suppose there might be more discussion about why this change was made on the
developer's list, but I haven't dug in to that yet. Neither have I found
anything on the web refering to security issues associated with ansi codes, as
you alluded to in your message.

It is possible that security issues exist, but if not, I'd personally prefer
that this be coded as a switchable option so that those of us that trust the
banner can display it as intended, escape codes and all.

--
Thomas K. Gamble
System/Network Administrator, Cyber Systems Security Officer
Chemical Diagnostics and Engineering (C-CDE)
Los Alamos National Laboratory
MS-J565,p:505-665-4323 f:505-665-4267

There cannot be a crisis next week. My schedule is already full.
Henry Kissinger