XMMP/Jabber clients DoS vulnerability report

[Andrea Barisani]

On Tue, Feb 09, 2010 at 11:27:48AM -0800, Mark Doliner 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?
> 

Sounds good to us.

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

Thanks.

> --Mark

-- 
Andrea Barisani |                Founder & Project Coordinator
          oCERT | Open Source Computer Emergency Response Team

<lcars at ocert.org>                         http://www.ocert.org
 0x864C9B9E 0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E
        "Pluralitas non est ponenda sine necessitate"