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