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.
Re: credentials in memory
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: David Woodhouse via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 30 Sep 2022 09:28:12 +0100
On Fri, 2022-09-30 at 09:43 +0200, Daniel Stenberg via curl-library wrote:
> 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?
Don't forget to ensure that all *transitional* storage is securely
wiped, including request buffers in which the password has been
(decrypted and) sent.
Received on 2022-09-30
Date: Fri, 30 Sep 2022 09:28:12 +0100
On Fri, 2022-09-30 at 09:43 +0200, Daniel Stenberg via curl-library wrote:
> 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?
Don't forget to ensure that all *transitional* storage is securely
wiped, including request buffers in which the password has been
(decrypted and) sent.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pkcs7-signature attachment: smime.p7s