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 <f...@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 (t...@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? Cheers Steffen
signature.asc
Description: This is a digitally signed message part.
