Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 22 May 2012 18:23:33 -0600
From: Kurt Seifried <>
CC: Keith Winstein <keithw@....EDU>,, mosh-devel@....EDU,
        "Steven M. Christey" <>
Subject: Re: Re: CVE Request -- mosh (and probably vte too):
 mosh server DoS (long loop) due improper parsing of terminal parameters in
 terminal dispatcher

Hash: SHA1

On 05/22/2012 01:29 PM, Keith Winstein wrote:
> Hello,
> I am the author of Mosh, and somebody pointed me to your CVE
> request:
> I have not been part of this process before -- do we (the upstream)
> have a role here?

Yes, ideally you should include the CVE # where appropriate in
ChangeLogs, NEWS files, web pages, email announcements, source code
comments, etc. This will make tracking the issue easier, and allow
vendors to quickly locate the vulnerable code, the code fix and so on.

In a perfect world a patch file labled something like
mosh-version-CVE-2012-2385.patch linked from your security web page
makes life really easy especially for vendors that backport security
fixes (e.g. Red Hat) rather than rebasing to a newer version (e.g.

> I don't want to butt in inappropriately, but I also don't want it
> to seem (by our silence) like we agree with the description in the
> CVE request.

Feel free to correct it =) Obviously the chances of getting an
accurate description are much better if the vendor participates.

> The writeup is not accurate. We're grateful for the bug report by
> Timo Juhani Lindfors, but to say "issue confirmed by mosh upstream"
> makes it sound like we confirm _this_ issue.
> We have written about this issue in the URL linked from the
> request:
> In general, the application sending ANSI escape sequences is a
> trusted party. It is allowed to do things like disable the user's
> keyboard by sending "\e[2h", which is interpreted by xterm and
> That's a DoS as well, but (like this one) it's not really a
> security vulnerability. Because ANSI escape sequences can do
> arbitrary things to the user's terminal, programs that allow
> untrusted user-to-user communication (including write(1), wall(1),
> and e-mail and newsgroup readers) need to filter these out.
> Here's my suggested text for the issue description:
> === Mosh versions 1.2 and earlier allow an application to cause
> the mosh-server to consume large amounts of CPU time with a short
> ANSI escape sequence. In addition, a malicious mosh-server can
> cause the mosh-client to consume large amounts of CPU time with a
> short ANSI escape sequence. This arises because there was no limit
> on the value of the "repeat" parameter in some ANSI escape
> sequences, so even large and nonsensical values would be
> interpreted by Mosh's terminal emulator. ===
> This gets away from the suggestion that the problem relates to
> "improper parsing" or the "count of parameters" (it's about wanting
> a limit on the _value_ of parameters so the terminal emulator
> doesn't do huge amounts of work to execute a very short sequence),
> or to data coming from "a remote attacker."

CC'ing Steve @Mitre so he has a copy.

> Best regards, Keith

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.