Bug#568291: possible buffer overflows

[Moritz Muehlenhoff]

On Thu, Feb 04, 2010 at 12:52:06PM +0100, Steffen Joeris wrote:
> Hi Mirco
> 
> > > Hi
> > >
> > > GMime upstream has released latest 2.4.15 [1] version of the
> > > library fixing one security issue. From 2.4.15-changes [2] file:
> > >
> > > 2010-01-31  Jeffrey Stedfast  <fejj at novell.com>
> > >
> > >         * gmime/gmime-encodings.h (GMIME_UUENCODE_LEN): Fixed to
> > > prevent possible buffer overflows.
> > >
> > > The vulnerable code seems to be in gmime/gmime-utils.h, I've attached
> > > upstream's patch for your convenience, but I did not have a deeper
> > > look at the buffer sizes, so it is unchecked.
> > >
> > > stable is also affected and would need to be fixed as well I guess.
> > > Please contact the secuirty team (team at security.debian.org), if you've
> > > checked the patch and have packages ready for lenny.
> > 
> > Upstream contacted me already and said that gmime2.2 is not
> > affected, only gmime2.4 is.
> I have my doubts about this. Looking at gmime/gmime-utils.h we're having the 
> same declaration for GMIME_UUENCODE_LEN that was declared vulnerable.
> 
> For gmime2.2, GMIME_UUENCODE_LEN is used by g_mime_filter_set_size() in 
> filter_filter(). The latter is also taking a size_t, so I'd suspect that it 
> should be possible to overflow this as well? Note that I have not dived deeper 
> into the code, but a short talk with RedHat revealed that fedora seems to be 
> pushing updates for gmime2.2. Could you please have a look at it and clarify 
> things?
> Upstream's patch seems to increase the buffer by 2, I am not sure where their 
> buffer calculation comes from, could you please double check that as well?

What's the status?

Do GNOME maintainers plan to include gmime2.2 in Squeeze or will it
dropped in favour of gmime2.4?

Cheers,
        Moritz