Remote crash in Finch

Sadrul Habib Chowdhury sadrul at
Wed Feb 10 12:17:44 EST 2010

* Tomas Hoger had this to say on [10 Feb 2010, 17:05:15 +0100]:
> Hi Sadrul!
> On Tue, 9 Feb 2010 22:11:10 -0500 Sadrul Habib Chowdhury
> <sadrul at> wrote:
> > In an XMPP MUC, if someone changes the nick to '<br>' (using '/nick
> > <br>' for example), then libpurple ends up having two users with
> > username '\n' in the room, and finch crashes in this situation.
> Why does it crash?  Can it be more than a crash?  Does libpurple
> created two '\n' users from that one changing nick to <br>, or does it
> have the first one for some other purpose?


> By "remote exploitability", do you mean whether it's more than a crash?

The crash happens when Finch tries to read memory it has already freed. I
do not believe it can be used to execute code, or do anything malicious
of that nature. 'remote crashibility' is probably more appropriate
(except that doesn't seem to be a real word).

libpurple incorrectly parses the username as '\n', where it should really
be '<br>'. This is due to some libxml2 weirdness, and is fixed by

The fix for the crash itself in finch has not yet been committed.

> > From the looks of things, it appears the remote exploitability in
> > finch is still 'unknown'. I have CC'ed this mail to Josh Bressers. I
> > believe you can issue a CVE# for this yet-undisclosed issue?
> Josh is not reading his mails too often these days, but we can help you
> with CVE assignment, if you as upstream are going to treat this as
> security issue.  CVE can be assigned before the issue is publicly
> disclosed, so you can use it in e.g. new release announcements.

I believe we treat remotely triggerable crashes as security issues. Once
we get the CVE#, we plan to make a release sometime next week


More information about the Packagers mailing list