XMMP/Jabber clients DoS vulnerability report

[Mark Doliner]

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.

--Mark