Mailing List Archive

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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: OpenSSH banner doesnot display multibyte characters like korean [ In reply to ]
On Tue, Sep 25, 2012 at 9:12 PM, balu chandra <balu9463@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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: OpenSSH banner doesnot display multibyte characters like korean [ In reply to ]
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@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
@@ -50,6 +50,19 @@
(c) == '\007' || (c) == '\r' || \
isgraph((u_char)(c)))))

+int multi_byte_banner = 0;
+#ifdef WORDS_BIGENDIAN
+#define FIRST_BYTE 0
+#define SECOND_BYTE 1
+#define THIRD_BYTE 2
+#define FOURTH_BYTE 3
+#else
+#define FIRST_BYTE 3
+#define SECOND_BYTE 2
+#define THIRD_BYTE 1
+#define FOURTH_BYTE 0
+#endif
+
/*
* vis - visually encode characters
*/
@@ -168,9 +181,15 @@
char *start, *end;
char tbuf[5];
int c, i;
+ int multi_byte_num;

i = 0;
for (start = dst, end = start + siz - 1; (c = *src) && dst < end; ) {
+ multi_byte_num = 0;
+/* if ( ( 0300 & c ) == 0200 ) {
+ *dst++ = c;
+ src++;
+ } */
if (isvisible(c)) {
i = 1;
*dst++ = c;
@@ -185,6 +204,33 @@
}
}
src++;
+/* Though ISO defines 6 bytes for UTF8, a valid unicode char is
defined by 1-4 byte UTF8 sequence
+ For a one byte UTF8 char:
+ same as ASCII (0x00 - 0x7F)
+ two byte UTF8 char:
+ 1st byte is bit-110?????
+ 2nd byte is bit-10??????
+ three byte UTF8 char:
+ 1st byte is bit-1110????
+ 2nd and 3rd bytes are bit-10??????
+ four byte UTF8 char:
+ 1st byte is bit-11110???
+ 2nd, 3rd and 4th bytes are bit-10?????? */
+ } else if ( multi_byte_banner && (((*src+FIRST_BYTE) &
0xE0) == 0xC0) &&
+ ((*(src+SECOND_BYTE) & 0xC0) == 0x80) ) {
+ /* 2-byte char */
+ multi_byte_num = 2;
+ } else if ( multi_byte_banner && (((*src+FIRST_BYTE)
& 0xF0) == 0xE0) &&
+ ((*(src+SECOND_BYTE) & 0xC0) == 0x80) &&
+ ((*(src+THIRD_BYTE) & 0xC0) == 0x80) ) {
+ /* 3-byte char */
+ multi_byte_num = 3;
+ } else if ( multi_byte_banner && (((*src+FIRST_BYTE) &
0xF1) == 0xF0) &&
+ ((*(src+SECOND_BYTE) & 0xC0) == 0x80) &&
+ ((*(src+THIRD_BYTE) & 0xC0) == 0x80) &&
+ ((*(src+FOURTH_BYTE) & 0xC0) == 0x80) ) {
+ /* 4-byte char */
+ multi_byte_num = 4;
} else {
i = vis(tbuf, c, flag, *++src) - tbuf;
if (dst + i <= end) {
@@ -195,6 +241,9 @@
break;
}
}
+ while (multi_byte_num--) {
+ *dst++ = *src++;
+ }
}
if (siz > 0)
*dst = '\0';
@@ -203,6 +252,7 @@
while ((c = *src))
dst += vis(tbuf, c, flag, *++src) - tbuf;
}
+ multi_byte_banner = 0;
return (dst - start);
}

diff -ur openssh6.1/sshconnect2.c openssh6.1_mod/sshconnect2.c
--- openssh6.1/sshconnect2.c 2012-11-27 16:11:34.084649708 +0530
+++ openssh6.1_mod/sshconnect2.c 2012-11-27 16:10:58.950588684 +0530
@@ -103,6 +103,7 @@

Kex *xxx_kex = NULL;

+extern int multi_byte_banner;
static int
verify_host_key_callback(Key *hostkey)
{
@@ -535,6 +536,7 @@
if (len > 65536)
len = 65536;
msg = xmalloc(len * 4 + 1); /* max expansion from strnvis() */
+ multi_byte_banner = 1;
strnvis(msg, raw, len * 4 + 1, VIS_SAFE|VIS_OCTAL|VIS_NOSLASH);
fprintf(stderr, "%s", msg);
xfree(msg);



Regards,
Bala

On 10/5/12, Darren Tucker <dtucker@zip.com.au> wrote:
> On Tue, Sep 25, 2012 at 9:12 PM, balu chandra <balu9463@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.
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: OpenSSH banner doesnot display multibyte characters like korean [ In reply to ]
On Tue, Nov 27, 2012 at 12:17 PM, balu chandra <balu9463@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@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 ?

----

Bye,
Roland

--
__ . . __
(o.\ \/ /.o) roland.mainz@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: OpenSSH banner doesnot display multibyte characters like korean [ In reply to ]
I believe the standard multibyte encodings (Shift-JIS, Big-5, GBK, etc.)
all avoid using bytes in the control character range (0x00 to 0x1F) for
the second character.

Also, doesn't the SSH specification state that UTF-8 is the only allowable
encoding for the banner?

On Tue, 27 Nov 2012, Roland Mainz wrote:

> On Tue, Nov 27, 2012 at 12:17 PM, balu chandra <balu9463@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@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 ?
>
> ----
>
> Bye,
> Roland
>
> --
> __ . . __
> (o.\ \/ /.o) roland.mainz@nrubsig.org
> \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
> /O /==\ O\ TEL +49 641 3992797
> (;O/ \/ \O;)
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
>

Regards,
....Bob Rasmussen, President, Rasmussen Software, Inc.

personal e-mail: ras@anzio.com
company e-mail: rsi@anzio.com
voice: (US) 503-624-0360 (9:00-6:00 Pacific Time)
fax: (US) 503-624-0760
web: http://www.anzio.com
street address: Rasmussen Software, Inc.
10240 SW Nimbus, Suite L9
Portland, OR 97223 USA
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: OpenSSH banner doesnot display multibyte characters like korean [ In reply to ]
On Tue, Nov 27, 2012 at 2:54 PM, Bob Rasmussen <ras@anzio.com> wrote:
> I believe the standard multibyte encodings (Shift-JIS, Big-5, GBK, etc.)
> all avoid using bytes in the control character range (0x00 to 0x1F) for
> the second character.

I think they all have an ascii or ascii-like basis.
>
> Also, doesn't the SSH specification state that UTF-8 is the only allowable
> encoding for the banner?

In that case the PRC government will not allow openssh deployment for
government usage. GB18030 violations are NOT tolerated. The rules for
commercial software products in PRC are quite simple: you support
GB18030 or their government will shut your China branch down.
Permanently. There's no leeway for 'why?', 'if?' or 'can be have more
time?' (than the usual two months you get when they find out that you
violate their law).

>
> On Tue, 27 Nov 2012, Roland Mainz wrote:
>
>> On Tue, Nov 27, 2012 at 12:17 PM, balu chandra <balu9463@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@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 ?
>>
>> ----
>>
>> Bye,
>> Roland
>>
>> --
>> __ . . __
>> (o.\ \/ /.o) roland.mainz@nrubsig.org
>> \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
>> /O /==\ O\ TEL +49 641 3992797
>> (;O/ \/ \O;)
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev@mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>
>>
>
> Regards,
> ....Bob Rasmussen, President, Rasmussen Software, Inc.
>
> personal e-mail: ras@anzio.com
> company e-mail: rsi@anzio.com
> voice: (US) 503-624-0360 (9:00-6:00 Pacific Time)
> fax: (US) 503-624-0760
> web: http://www.anzio.com
> street address: Rasmussen Software, Inc.
> 10240 SW Nimbus, Suite L9
> Portland, OR 97223 USA
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev



Irek
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: OpenSSH banner doesnot display multibyte characters like korean [ In reply to ]
On Tue, Nov 27, 2012 at 2:21 PM, Roland Mainz <roland.mainz@nrubsig.org> wrote:
> On Tue, Nov 27, 2012 at 12:17 PM, balu chandra <balu9463@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@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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: OpenSSH banner doesnot display multibyte characters like korean [ In reply to ]
Bob Rasmussen wrote
>> Also, doesn't the SSH specification state that UTF-8 is the only allowable
>> encoding for the banner?

It does:
> string message in ISO-10646 UTF-8 encoding [RFC3629 <http://tools.ietf.org/html/rfc3629>]
http://tools.ietf.org/html/rfc4252#section-5.4

Irek Szczesniak wrote:

> In that case the PRC government will not allow openssh deployment for
> government usage. GB18030 violations are NOT tolerated. The rules for
> commercial software products in PRC are quite simple: you support
> GB18030 or their government will shut your China branch down.
> Permanently. There's no leeway for 'why?', 'if?' or 'can be have more
> time?' (than the usual two months you get when they find out that you
> violate their law).
If you *must* show the characters in GB18030, then the ssh client should
translate the banner from UTF-8 to GB18030.
The protocol bytes are in UTF-8, but that is an implementation detail, just
as windows workstations using UTF-16 on its filesystem.


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: OpenSSH banner doesnot display multibyte characters like korean [ In reply to ]
On 10/05/2012 02:39 AM, Darren Tucker wrote:
> On Tue, Sep 25, 2012 at 9:12 PM, balu chandra <balu9463@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?


[1] https://bugzilla.mindrot.org/show_bug.cgi?id=2058


Petr
Re: OpenSSH banner doesnot display multibyte characters like korean [ In reply to ]
On Jul 17, 2014, at 7:04 AM, Petr Lautrbach <plautrba@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@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@timeheart.net



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