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: Howard Chu via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 30 Sep 2022 16:45:30 +0100
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?
Long ago when I was developing PC/Mac Kerberos client libraries, my solution was to encrypt secrets in an in-memory credential
cache using the contents of the stack as the encryption key. As such, the key could only be constructed by calling the same
sequence of functions with the same parameters as the original call, and the key would generally be different for every app/
program invocation. (My in-memory credential cache is still part of MIT Kerberos5 libraries today, but I guess not in the same
form as 25 years ago...)
Today I would try something similar, with an explicitly managed mmap'd buffer region for the credential cache. On some platforms
you can mark a mapping as non-swappable, so there's no danger of it persisting to disk. Also you can mprotect to remove its read
access until you actually need to retrieve a value.
Date: Fri, 30 Sep 2022 16:45:30 +0100
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?
Long ago when I was developing PC/Mac Kerberos client libraries, my solution was to encrypt secrets in an in-memory credential
cache using the contents of the stack as the encryption key. As such, the key could only be constructed by calling the same
sequence of functions with the same parameters as the original call, and the key would generally be different for every app/
program invocation. (My in-memory credential cache is still part of MIT Kerberos5 libraries today, but I guess not in the same
form as 25 years ago...)
Today I would try something similar, with an explicitly managed mmap'd buffer region for the credential cache. On some platforms
you can mark a mapping as non-swappable, so there's no danger of it persisting to disk. Also you can mprotect to remove its read
access until you actually need to retrieve a value.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-09-30