432469 - Remaining buffer overflow issues mailnews/mime/src/comi18n.cpp

Status: RESOLVED DUPLICATE of bug 430193

(MailNews Core :: MIME, defect)

Description

[Mats Palmgren (inactive)]

I looked throught the patch in bug 413874 and it seems to me that
buffer overflow is still possible even when using PL_strncpyz().
An example:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/mailnews/mime/src/comi18n.cpp&rev=1.133&root=/cvsroot&mark=349,352-353#348

'obufsize' is declared as PRInt32.
The buffer size parameter of PL_strncpyz() is declared PRUint32.

Suppose the buffer is near full such that PL_strncpyz() cannot
write the full length of 'encodedword_head'.
We still do "obufsize -= encodedword_headlen" causing 'obufsize'
to become negative.  The next PL_strncpyz() to 'o' will be a
buffer overflow.

Briefly looking through the patch, I think all the places that updates
the remaining buffer length needs to use strlen() to find out how much
was actually copied.

Also, I looked at the code for PL_strncpyz():
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/nsprpub/lib/libc/src/strcpy.c&rev=3.8&root=/cvsroot&mark=74-75#69
Silently accepting NULL src/dest hides programming errors.
I'd like a fatal assert there in debug builds.

Comment 1

[Emre Birol]

Can we consolidate this bug with Bug 430193?

Comment 2

[Mats Palmgren (inactive)]

Sure, bug 413874 didn't mention any followup bug so assumed there
wasn't one...