OpenSSH banner doesnot display multibyte characters like korean

[Ron Frederick]

On Jul 17, 2014, at 7:04 AM, Petr Lautrbach <plautrba at redhat.com> wrote:
> On 10/05/2012 02:39 AM, Darren Tucker wrote:
>> On Tue, Sep 25, 2012 at 9:12 PM, balu chandra <balu9463 at gmail.com> wrote:
>>> I also found little information inthe changelog on why strnvis() was
>>> introduced in input_userauth_banner. Is it added to address any
>>> security vulnerability.
>> 
>> I believe the intent was to prevent a malicious server from sending a
>> banner containing a terminal answerback command sequence.  I'm not
>> aware of any UTF-8 aware equivalent of strnvis, though (if someone
>> knows of one we'll look at using it).
>> 
> 
> I've asked my colleagues for help with [1] and it comes to that the case you describe might
> not be an issue at all.
> 
> The banner is sent after a server is authenticated to a client and a client can always suppress
> printing a banner using -q option if he doesn't trust it.
> 
> And what would stop a malicious server from sending a terminal answerback command sequence
> during a session instead in preauth phase?
> 
> Is there any relevant discussion related to this problem from past with more specific information?

I can’t speak to the history of when this got added to OpenSSH, but the SSH RFCs do specifically discuss this point. In particular in section 5.4 about the auth banner, RFC 4252 says:

   If the 'message' string is displayed, control character filtering,
   discussed in [SSH-ARCH], SHOULD be used to avoid attacks by sending
   terminal control characters.

It defines the banner text as follows, though:

   string    message in ISO-10646 UTF-8 encoding [RFC3629]

So, any control character filtering should not be stripping out printable Unicode characters if they are properly encoded as UTF-8.

SSH-ARCH here refers to RFC 4251, which covers this topic in section 9.2, Control Character Filtering:

9.2.  Control Character Filtering

   When displaying text to a user, such as error or debug messages, the
   client software SHOULD replace any control characters (except tab,
   carriage return, and newline) with safe sequences to avoid attacks by
   sending terminal control characters.

Looking at the OpenSSH sources, the strnvis() function is definitely not UTF-8 aware, so this is technically a violation of the spec. 
-- 
Ron Frederick
ronf at timeheart.net