On Jul 17, 2014, at 7:04 AM, Petr Lautrbach <plautrba@xxxxxxxxxx> wrote: > On 10/05/2012 02:39 AM, Darren Tucker wrote: >> On Tue, Sep 25, 2012 at 9:12 PM, balu chandra <balu9463@xxxxxxxxx> 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@xxxxxxxxxxxxx _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
