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 21:06:20 +0100
From: Pierre Schweitzer <>
Subject: Re: CVE request: denial of service in Quassel

Hash: SHA1

Thanks for your detailed answer, please find my answers inlined.

On 27/03/2015 19:16, wrote:
> 2
>> 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.

This wouldn't affect the client. All the patch here only affects the
core component, so the stack overflow would happen in the core.

I'm indeed not sure about what would happen in case of a stack
overflow. But, be it a crash or a hang, it would cause a denial of
service for any client connected to core.

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

I don't believe this is to be considered as a security bug.
Especially, because due to the recursive, it would cause
reinterpreting the left string. It's unlikely it would be something
relevant that the core would dispatch to clients or server.

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

I believe this is more about in the removed code:

But I'm not sure about how it could cause a crash, or a thread leak.

- -- 
Pierre Schweitzer <pierre at>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
Version: GnuPG v2.0.22 (GNU/Linux)


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.