Hi,

I bring back an old discussion as I think it might be worth having it again.

libcurl hold credentials (passwords for servers and proxies) in memory in clear text, potentially for a long time. If something goes wrong and that memory is accessed by an external party, things would be bad.

We work really hard on preventing and avoiding the "something goes wrong" part, but every once in a while we come back to the fact that we still keep credentials in the clear in memory. This is also something that our good friends at Trail of Bits have commented on during the ongoing security audit they are performing on curl.

Is it worth doing something about?

If it is, what's a reasonable mitigation? We need to be able to use them in the clear, so whatever we do we cannot just hash them. We would need to have a way to store them encrypted and decrypt them on demand when they are needed and then only use them "in the clear" for as a short period as possible.

This would mostly remove them from being readable as-is, like if there's a stack reveal or heap leak as a result of a vulnerability perhaps, the risk for credential leaks would be reduced.

The "encryption" then wouldn't have to be complicated and could use a randomly generated "key", probably created when the handle is created.

Of course, since the passwords are passed in to libcurl from applications, this dance is less effective if they then keep the credentials around in the clear in memory anyway, but I think maybe they typically keep them around for a shorter time in general.

Thoughts? Pointless? Improvements?


--

 / daniel.haxx.se
 | Commercial curl support up to 24x7 is available!
 | Private help, bug fixes, support, ports, new features
 | https://curl.se/support.html
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Reply via email to