Re: questions regarding libmimelib1 as seperate source package
On 24/04/2009 Russ Allbery wrote:
> Jonas Meurer <jonas@freesources.org> writes:
>
> > Unfortunately ron discovered a far worse issue. The way str[ln]cat()
> > is used in mimelib makes it very error-prone to buffer overflows:
> >
> > #define SEND_BUFFER_SIZE 1024
> > ...
> > mSendBuffer = new char[SEND_BUFFER_SIZE];
> > ...
> > strlcpy(mSendBuffer, "PASS ", SEND_BUFFER_SIZE);
> > strlcat(mSendBuffer, aPasswd, SEND_BUFFER_SIZE);
> > strlcat(mSendBuffer, "\r\n", SEND_BUFFER_SIZE);
> >
> > this without any santising code for aPasswd causes mSendBuffer to be
> > overflowable for at least strlen("PASS ") + strlen("\r\n").
>
> That code is safe from a buffer overflow perspective using strlcpy and
> strlcat, but may not end the buffer with \r\n.
Indeed, you're correct. I didn't realize that up to now. strlcat here is
very different to strncat. strlcat uses something like
SEND_BUFFER_SIZE - strlen(mSendBuffer)
as limit, while strncat uses SEND_BUFFER_SIZE all the time, and that way
is error-prone to buffer-overflows.
That indeed is a good reason to revert all my changes from
strlcpy/strlcat to strncpy/strncat and instead use the strlcpy/strlcat
defines from kdecore/fakes.c.
But in that case I've a simple question: if I put both defines into a
seperate c source file strl___.c, how do I teach the autotools to use
this file when compiling nntp.cpp, pop.cpp and uuencode.cpp?
greetings,
jonas
Reply to: