openssh unix dev - Sep 2012 - OpenSSH banner doesnot display multibyte characters like korean

Hello,

The banner message displayed on the screen contain octal values
instead of korean chars. Prior to ssh 5.1 the banner message would
display the charaters properly.
I understand that starting from 5.1 the message is passed through
strnvis() function.
I looked into documentation on strnvis  and found that it does not
support multibyte chars and doesnt work well with international chars.

Could you please share any workaround to display international chars
like korean in banner message.

I also found little information inthe changelog on why strnvis() was
introduced in input_userauth_banner. Is it added to address any
security vulnerability.
Any information on this is appreciated.

Regards,
Bala

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).

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

On Tue, Nov 27, 2012 at 2:21 PM, Roland Mainz <roland.mainz at
nrubsig.org> wrote:
> On Tue, Nov 27, 2012 at 12:17 PM, balu chandra <balu9463 at
gmail.com> wrote:
>> I did not come across any UTF8 implementation of strnvis.
>> Howver have modified strnvis() to display Multibyte char (tested the
>> fix with Korean char).
>> Though all calls to strnvis() could be extended to skip Multibyte char
>> this fix is limited to skipping only for Banner message(introduced a
>> flag for doing so).
>>
>> The fix is provided here for comments.
>>
>> [root at rhel62 bala]# diff -ur openssh6.1 openssh6.1_mod
>> diff -ur openssh6.1/openbsd-compat/vis.c
openssh6.1_mod/openbsd-compat/vis.c
>> --- openssh6.1/openbsd-compat/vis.c     2012-11-27 16:12:23.986690241
+0530
>> +++ openssh6.1_mod/openbsd-compat/vis.c 2012-11-27 16:12:43.559859183
+0530
> [snip]
>
> Erm... the problem with this code is that it is specific to UTF-8
> only... but there are other multibyte encodings which are still in
> common use (like ja_JP.PCK/ShiftJIS on Solaris/Linux, both are used
> and mandated by goverment customers) and GB18030 (which is a)
"modern"
> (e.g. not "legacy" like some people call the EUC encodings) and
b)
> mandatory in PRC[1] (China)).
>
> AFAIK a possible fix would be to pass the data through the libc
> multibyte functions and filter anything out which looks like the ASCII
> control characters (since more or less all multibyte characters have
> ASCII as basis) + anything which matches |iswcntrl()|
>
> [1]=Erm... does anyone know how "Red Flag Linux" solved this ?
Red Flag Linux has disabled everything, including strnvis(), which
interfered with GB18030.

Irek