Re: ssh and banners
- From: Thomas K Gamble <tkg@xxxxxxxx>
- Date: Tue, 18 Aug 2009 07:20:02 -0600
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.
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
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
- djm@xxxxxxxxxxxxxxx 2008/07/17 08:48:00
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
There cannot be a crisis next week. My schedule is already full.
- Prev by Date: Re: ssh and banners
- Next by Date: sed command via SSH not working as expected
- Previous by thread: Re: ssh and banners
- Next by thread: sed command via SSH not working as expected