XMMP/Jabber clients DoS vulnerability report

[Andrea Barisani]

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

Cheers

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