curl / Mailing Lists / curl-library / Single Mail


libcurl leaks information in freed memory

From: Gabriel Zachmann via curl-library <>
Date: Wed, 17 Oct 2018 12:33:09 +0200


On 17.10.18 10:25, Daniel Stenberg wrote:
> On Wed, 17 Oct 2018, Gabriel Zachmann wrote:
>> It is possible to obtain sensitive information from memory after
>> cleanup. As far as I looked at the code, curl_easy_cleanup does only
>> free the used memory and does not overwrite it beforehand. This way
>> the information remains in memory and can be read using e.g. gcore.
>> When we send sensitive information (e.g. user credentials, OpenId
>> Connect refresh_tokens) in the request body or an authorization
>> header, they can be leaked to other processes because they remain in
>> memory.
> I think discussions about this
> topic and how and if this should be addressed is better held in public
> on the curl-library mailing list.
> That said: it is *very* hard, if not impossible, to protect memory from
> other users/processes with access and rights to read libcurl's memory.
> Clearing memory before free() is very hard, and won't even be sufficient
> since such a process could still read the memory before it gets cleared.
> This, plus zeroing buffers is really hard.

I understand that this is not quite easy. However, while we won't find
an optimal solution, I think we can do better. Zeroing memory might not
succeed in all cases and there might be still some parts left on the
stack, register, etc. But I think we can still memsetting most and it
will be much harder to get sensitive information.

I also see the problem that a process simply could read the memory
before it is overwritten. However, we can make it harder. Currently a
process can read the memory of a long running program using libcurl
(e.g. daemon) and get information used a long time ago. If the memory is
overwritten the process would have to read memory continuously (more or

> Two related and excellent blog posts on the difficulties on zeroing
> buffers:



Received on 2018-10-17