Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 27 Mar 2015 14:16:41 -0400 (EDT)
Subject: Re: CVE request: denial of service in Quassel

Hash: SHA1

> The following commit fixed a denial of service in quassel:

> It allows a connected client to cause a core crash by sending a CTCP
> request which would be too long and multibyte.

We're not sure how many CVE IDs would be best.
b5e38970ffd55e2dd9f706ce75af9a8d7730b1b8 seems to describe two items
in terms of bugs and two other items in terms of (somewhat unrelated)

In order of likelihood of CVEs, we have:

> The second is
> the core crash caused by sending an overlength CTCP query ("/me")
> containing only multibyte characters. This bug was caused by the
> old CTCP splitter using the byte index from lastParamOverrun() as
> a character index for a QString.

This seems to be, very roughly, an issue of incorrectly determining a
data-structure length by using a wrong-sized data type for counting.
It happens to be about multibyte characters but that's of secondary
importance. This will almost certainly have a unique CVE ID, but we
will see if there are any comments stating that it occurs for exactly
the same reason as the "garbage characters" issue below.

> Unlike what it replaces, the new splitting code is not recursive
> and cannot cause stack overflows.

If an attacker sends a crafted message and this leads to excessive
stack consumption in an IRC client, making the client crash or hang,
then that is relevant for a CVE. (We are expecting that it is a
"normal" IRC client that supports independent sessions with messages
from different channels or different persons.) However,
b5e38970ffd55e2dd9f706ce75af9a8d7730b1b8 doesn't actually state that
the client would ever crash or hang.

> The first is garbage characters caused
> by accidentally splitting the string in the middle of a multibyte
> character. Since the new code splits at a character level instead
> of a byte level, this will no longer be an issue.

This one seems to be inherently about multibyte characters because
it's an issue of string display (or string interpretation) if whole
characters aren't preserved. However, it doesn't seem to be announced
as a security issue. Although someone might be sending
security-critical messages over IRC and would not want those messages
to be misinterpreted, that's generally too much of a leap to have a
CVE. If nobody else has other analysis, we will probably treat this as
a non-security bug.

> if it is unable
> to split a string, it will give up gracefully and not crash the
> core or cause a thread to run away.

As far as we can tell, this is about:

  // If the QTBF fails to find a split point in Grapheme mode, we give up.
  // This should never happen, but it should be handled anyway.
  qWarning() << "Unexpected failure to split message!";
  return msgsToSend;

in the patched code. If nobody else has other analysis, we will
probably treat this as a defense-in-depth measure that doesn't address
any known vulnerability, and therefore has no CVE.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


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.