Clearing out the memory after closing the handle is not an issue, I
understand that the memory will need to be used in subsequent calls and
will need to be present until it is no longer needed. It is valid to have
it present until after the cURL objects are finished with it.

For the modification of the clearfree() method; testing would be tricky,
more than likely external tools would be needed. This would not be ideal
for an automated approach if there were future changes involved. These
could break the functionality unintentionally without being caught and
risk adding defects.

For the first approach of creating a custom allocator have you heard of
people taking this approach before to zero memory. In this case it would
be tested using in house tools and up to the creators of the allocator to
ensure that it works.
My only concern with this approach is in the free callback that cURL uses
to deallocate memory. All that is supplied is an address and not a size,
so to zero the data before freeing would need either a modification of the
callback or a structure to be created around the data which stores the
size, which can lead to issues in itself.

Have you any thoughts on this approach?

Thanks,
Alan

On 21/05/2015 11:41, "Daniel Stenberg" <daniel_at_haxx.se> wrote:

>On Thu, 21 May 2015, Alan Cronin (alcronin) wrote:
>
>> I would like to fix this by setting the memory to zero before freeing
>>it. I
>> have two potential changes which can resolve this issue. One of them is
>>to
>> create a new Curl_safefree definition in memdebug.h which takes in a
>>pointer
>> to a memory location and a size, then overwriting the memory before
>>zeroing.
>> The other method is to create a custom allocator / deallocator in our
>> application which will zero the memory itself, however we will need to
>>store
>> the size with the block of data we allocate to determine how much data
>>to
>> zero.
>
>First, it could of course be done with a completely separate malloc
>replacement that always zeroes out data that is freed. That would come at
>the
>expense of clearing all freed memory and not just the sensitive ones -
>but it
>will also avoid the risk of missing a few sensitive areas. And you can
>also do
>it without changing a single line of libcurl code.
>
>But is this really going to work? If you pass on a user name or password
>in
>one or more libcurl options, they must remain there so that the handle
>can be
>re-used for subsequent requests. Those areas won't be freed until you
>decide
>to close down the handle!
>
>Assuming we think it can be done and that the first option isn't good
>enouh,
>and you would proceed and do a "clearfree()" function for this purpose,
>my
>concerns with that approach are:
>
>How would you make sure that you clear all the necessary memory blocks?
>It is
>very hard to test this, isn't it? It seems like a method that is just
>waiting
>for a future change to break it.
>
>--
>
> / daniel.haxx.se
>-------------------------------------------------------------------
>List admin: http://cool.haxx.se/list/listinfo/curl-library
>Etiquette: http://curl.haxx.se/mail/etiquette.html

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-05-21