Lots of crashes (exploitable?) reported in Fedora

[Vincent Danen]

* [2012-04-17 21:09:41 -0400] Elliott Sales de Andrade wrote:

>
>
>On Tue, Apr 17, 2012 at 3:09 PM, Vincent Danen <vdanen at redhat.com> wrote:
>
>    * [2012-04-13 14:19:51 -0400] Ethan Blanton wrote:
>
>
>        Vincent Danen spake unto us the following wisdom:
>
>            Hi folks. Â I'm not sure whether this should be considered
>            security-sensitive or not, but we've had a number of crashes
>            reported on
>            pidgin in Fedora:
>
>            https://bugzilla.redhat.com/show_bug.cgi?id=720781
>
>
>        Are the extra threads created by the crash-reporting process, or is
>        Fedora doing something stupid with plugins? Â I see at least some of
>        those include third-party plugins, some of which I do not recognize.
>
>
>    Sorry for not getting back to this sooner.
>
>    I don't believe abrt would be adding anything to those calls, but I'm
>    not 100% familiar with it. Â They could very well be third-party plugins
>    causing this (I suspect users can download and install their own plugins
>    outside of what we provide in Fedora).
>
>
>
>The additional threads may be caused by something like pulseaudio.
>
>There are definitely some crashes there in the msn-pecan and sipe third-part
>plugins.
>Â 
>
>
>
>        The threads seem to be using different glib contexts, so they may be
>        safe, but ...
>
>
>            The bug is public as these were all sent by abrt collecting info on
>            Pidgin crashes and they seem to be all over the place. Â I have not
>            much
>            experience with Pidgin or trying to determine whether or not these
>            might
>            be considered security flaws, but could you take a look at the bug
>            and
>            see if might be?
>
>            Again, the bug is public but I wanted to give you a heads-up. Â I
>            don't
>            believe these are more than crashes, but at least one user in the
>            bug
>            seems to think these should be security-relevant.
>
>
>        The crash-on-demand from a jabber call is indeed concerning.
>
>
>
>
>This may have been reported separately here already.
>Â 
>
>    I'm cc'ing Jonathan who maintains pidgin on RHEL, as he may have more
>    insight into this than I, and Stu who is the Fedora maintainer of
>    pidgin.
>
>    From what I understand of abrt, if the hash is the same (which it should
>    be since all these reports keep getting added to this one bug), then the
>    issue is being triggered in the same place (if it were triggered
>    somewhere else, my understanding is that the abrt hash would change).
>    So it looks like the underlying problem might be the same across the
>    board, but it just shows up in different ways or circumstances?
>
>
>
>abrt is clearly broken in this case, though, unless the underlying problem is
>some sort of random memory corruption. Some of the backtraces are in cairo/X,
>some in third-party plugins, and a few more in Pidgin/libpurple. And this one
>isn't even in Pidgin: https://bugzilla.redhat.com/attachment.cgi?id=572234

Ok, solved this particular mystery.  One of the guys on my team noted
this:


"Another problem here is that pidgin comes with its own signal handler.
So if we e.g. run into a segfault somewhere, pidgin's internal signal
handler will catch this before the abrt tool has the chance. Pidgin's
signal handler eventually triggers the abort, which is what we see in
all the backtraces. That's one step too late and we end up with less
than optimal backtraces that appear to be caused by the same issue
(since it's always pidgin's signal handler), although I believe that
they're actually caused by separate issues."


Which is really annoying and makes abrt not very useful in this case.

The third-party issues don't concern me as much as the core things,
which is what I wanted to bring up and make you folks aware of, since
that may affect upstream pidgin as well.

--
Vincent Danen / Red Hat Security Response Team