Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
credentials in memory
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 30 Sep 2022 09:43:39 +0200 (CEST)
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?
Date: Fri, 30 Sep 2022 09:43:39 +0200 (CEST)
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.htmlReceived on 2022-09-30