XMMP/Jabber clients DoS vulnerability report

[Mark Doliner]

On Tue, Feb 9, 2010 at 11:27 AM, Mark Doliner <mark at kingant.net> wrote:
> On Fri, Jan 29, 2010 at 5:32 AM, Andrea Barisani <lcars at ocert.org> wrote:
>> On Thu, Jan 28, 2010 at 09:41:32AM +0000, Andrea Barisani wrote:
>>> On Wed, Jan 27, 2010 at 10:45:50PM -0500, Ethan Blanton wrote:
>>> > Andrea Barisani spake unto us the following wisdom:
>>> > > oCERT recently received a report about a DoS condition in Pidgin and Psi,
>>> > > other XMMP clients might be affected (libpurple and libiris ones most
>>> > > likely).
>>> > >
>>> > > The sample message attached to this email causes, according to the reporter,
>>> > > 100% CPU load, the message can be sent by non-buddies as just the target jid
>>> > > is sufficient.
>>> > >
>>> > > Can you confirm the issue?
>>> >
>>> > We can confirm this issue.  The CPU load is caused by Pidgin's
>>> > allocation and display of a large number of smiley emoticons
>>> > corresponding to the ':D' string, and any similar emoticon could be
>>> > used to generate this effect.  The delay is bounded, however, and
>>> > after some time Pidgin will in fact display 20,000 lines
>>> > (approximately) of :D images.
>>> >
>>> > We intend to circumvent the potential DoS in this issue by rendering
>>> > only the first k emoticons in a given message (where k has not yet
>>> > been determined), and this fix will likely be in our next regular
>>> > release.
>>> >
>>>
>>> Thanks.
>>>
>>> > > oCERT is mainly concerned about the issue not being exploitable as we
>>> > > generally don't issue advisory about "simple DoS conditions.
>>> >
>>> > This is not an exploitable bug, it is simply a denial of service
>>> > through resource allocation.
>>> >
>>>
>>> Agreed.
>>>
>>> > > However we would be happy to coordinate with vendors/distributions if you
>>> > > want any help in pushing the eventual fixes around in a coordinated fashion.
>>> > > If this is the case, and the issue is confirmed, I'd like to discuss an
>>> > > embargo date that would allow us to contact all affected vendors with a
>>> > > patch and request not to disclose this issue in public.
>>> >
>>> > This is very much a client-specific fix, and the fixing of this issue
>>> > in one client with a suitable commit message (e.g., "bound maximum
>>> > emoticons in an incoming message to speed rendering of large
>>> > messages") does not immediately imply that there is a DoS to be taken
>>> > advantage of in the client in question or any other client.
>>> >
>>> > We are happy to embargo this until a given date if other projects
>>> > wish to do so; otherwise, we will notify our packagers of this as we
>>> > would any other DoS-related change before release.  We do not wish to
>>> > push an immediate release due to this issue, so if you wish to publish
>>> > a security bulletin on the matter, we would like to embargo for a
>>> > couple of weeks (or more) so that we can go through a normal string
>>> > freeze, translation cycle, etc.
>>> >
>>>
>>> We won't release a public advisory (unless you specifically want us to).
>>> Embargo date sounds good to us, if you send us a patch we will forward it to
>>> vendor-sec and/or other linux vendors pointing out the embargo date to speed
>>> up patching if you like. Just make sure you give us the exact date if
>>> possible, so that I can reference that.
>>>
>>> Thanks!
>>>
>>
>> FYI credit for finding this issues goes to Antti Hayrynen
>> (antti.hayrynen at nokia.com).
>
> How does midnight between Wednesday February 17th and Thursday
> February 18th sound for an embargo date?
>
> We have a small email list of mostly Linux vendors who we notify of
> problems like this.  We'll definitely send them the patch for this
> (once we've written it :-) ).  And we can send the patch to you, too,
> if you would also like to distribute it.

Oh!  I was thinking midnight PST, but it doesn't really matter.

--Mark