Vulnerability Update [VU#825121]

Mark Doliner mark at kingant.net
Wed Feb 28 19:03:42 EST 2007


On Wed, 28 Feb 2007 18:00:32 -0500, Luke Schierer wrote
> On Feb 28, 2007, at 17:37 EST, Daniel Atallah wrote:
> > On 2/28/07, Luke Schierer <lschiere at pidgin.im> wrote:
> >> - --- Begin report - Not for public distribution ----------
> >>
> >> There is a function whose prototype is :
> >>
> >> void gaim_debug(GaimDebugLevel level, const char *category, const
> >> char *format, ...);
> >>
> >> declared in my /usr/include/gaim/debug.h header.
> >>
> >>   Now, if you look at the source file in  <somepath>/gaim-1.5.0/
> >> plugins/perl/common/Gaim.c
> >>
> >>   you'll find this function missused in 3 places :
> >>
> >>   line 204: gaim_debug(level, category, string);
> >>   line 220:Â gaim_debug(GAIM_DEBUG_MISC, category, string);
> >>   line 237:Â gaim_debug(GAIM_DEBUG_INFO, category, string);
> >>
> >>   In those 3 places, the "string" variable can allow an attacker to
> >>   inject its own format string, and therefore,
> >>   read or write anywhere in the process's memory, potentially  
> >> allowing
> >>   arbitrary execution.
> >>
> >> - --- End Report - Not for public distribution -----------
> >
> > Has anyone actually verified that this is actually exploitable  
> > remotely?
> >
> > These are just in the Perl bindings - a malicious perl plugin could
> > certainly do bad things with them, but the ability of a plugin to do
> > bad things is hardly a vulnerability.
> >
> > -D
> >
> 
> my reply at the time was:
> 
> We received a report of these potential problems yesterday.  We have 
>  investigated them and found none to be remotely exploitable.  A 
>  couple of them could be exploited if you load a malicious plugin 
> into  gaim, but we consider this very low risk because the same care 
> should  be exercised in choosing plugins as goes into deciding what 
> software  to run,  a plugin does not need for such weak points to 
> exist to do  all sorts of potentially malicious things.
> 
> That being said, we have checked in fixes to these issues for the  
> 2.0.0 beta6 release, which should be this month, unfortunately I do  
> not have exact timing on this release at this time.

That's a fantastic response.  For the vendor statement thing, I dunno, you can
stress that this isn't really a security problem and that users should not use
perl scripts that they don't trust.  It seems kinda dumb to me that they would
even announce this...

-Mark


More information about the Cabal mailing list