On Thursday 15 March 2007 2:27 am, you wrote:
> Dear Jean-Philippe,
>
> First of all, thanks for all the effort you've put into developing curlpp.
>
Thank you for your interest.
> I'm using curlpp in a project and have just noticed a bug that could be a
> potential crasher/security risk under some circumstances. It's not causing
> me any problems, so I'm not expecting a fix. I noticed it while digging for
> memory leaks in my application and thought you might like to know. I can
> confirm its existance in version 0.7.0, maybe you've fixed it in 0.7.1.
>
It isn't. I did some work so that the string overloaded function would use
the char * overloaded and not the other way around, but I don't think it's
gonna be enough. I'll memset the memory to zero, so we'll be sure
that won't have any problems.
BTW, thanks for the bug report, very much appreciated.
(The message is sent to the mailing-list too)
> In the class CurlHandle you have a private data member mErrorBuffer which
> is a simple character array. In the class constructor, this is passed to
> errorBuffer:
>
> cURLpp::CurlHandle::CurlHandle()
>
> : mWriteFunctor(NULL)
>
> , mHeaderFunctor(NULL)
> , mReadFunctor(NULL)
> , mProgressFunctor(NULL)
> , mDebugFunctor(NULL)
> , mSslFunctor(NULL)
> ,mException(NULL)
> {
> mCurl = curl_easy_init();
> runtimeAssert( "Error when trying to curl_easy_init() a handle", mCurl );
> errorBuffer( mErrorBuffer );
> }
>
> However, this char array is never initialized. Eventually, it gets passed
> to (Exception.cpp:114):
>
>
> void cURLpp::libcurlRuntimeAssert(const char *reason, CURLcode code)
> {
> libcurlRuntimeAssert(std::string(reason), code);
> }
>
> where it is used to create an STL string.
>
> std::string's constructor uses strlen() to determine the length of the
> string which is passed to it. Since it is passed uninitialized data, there
> is not necessarily a null char and, thus, it could potentially run off the
> end of the buffer. Also, because of this, Valgrind will bark everytime the
> programme creates a CurlHandle.
>
> Here's the complete backtrace that shows the calls from CurlHandle's
> constructor.
>
>
> #0 0xb7a18d80 in strlen () from /lib/libc.so.6
> #1 0xb7b9bffb in std::basic_string<char, std::char_traits<char>,
> std::allocator<char> >::basic_string () from /usr/lib/libstdc++.so.6 #2
> 0xb78307f7 in cURLpp::libcurlRuntimeAssert (reason=0xb762ef70 "锟?=薹锟?\003",
> code=CURLE_OK) at Exception.cpp:114
> #3 0xb7846dc6 in cURLpp::CurlHandle::option<void*> (this=0xb762ef68,
> optionType=CURLOPT_ERRORBUFFER, value=0xb762ef70)
> at /usr/local/pkgs/curlpp-0.7.0/include/curlpp/CurlHandle.inl:36
> #4 0xb782ee14 in cURLpp::CurlHandle::errorBuffer (this=0xb762ef68,
> buffer=0xb762ef70 "锟?=薹锟?\003") at CurlHandle.cpp:79
> #5 0xb782f081 in CurlHandle (this=0xb762ef68) at CurlHandle.cpp:64
> #6 0xb7831208 in Easy (this=0xb762ef4c) at Easy.cpp:27
>
> The uninitialized buffer is fairly clear from the random characters in the
> function call parameters.
>
> Best wishes,
>
> R. Kay.
--
Jean-Philippe Barrette-LaPierre
_______________________________________________
cURLpp mailing list
[EMAIL PROTECTED]
http://www.rrette.com/mailman/listinfo/curlpp
