XMMP/Jabber clients DoS vulnerability report

Andrea Barisani lcars at ocert.org
Thu Jan 28 04:41:32 EST 2010


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!

> Ethan
> 
> -- 
> The laws that forbid the carrying of arms are laws [that have no remedy
> for evils].  They disarm only those who are neither inclined nor
> determined to commit crimes.
> 		-- Cesare Beccaria, "On Crimes and Punishments", 1764



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


More information about the security mailing list