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: James Fuller via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 30 Sep 2022 10:15:42 +0200
On Fri, 30 Sept 2022 at 10:12, Stefan Eissing via curl-library
<curl-library_at_lists.haxx.se> wrote:
>
>
>
> > Am 30.09.2022 um 09:43 schrieb Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>:
> >
> > 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?
>
>
> I know of threee patterns to solve this problem (and increase usability as a side effect):
>
> 1. macOS keychain which persists credentials and makes them available to authorized applications
> 2. ssh-agent
> 3. neverbleed (https://github.com/h2o/neverbleed) that spawns a process, using pipes to handle keys in out-of-process memory
>
> Maybe a "curl-agent" could be a portable approach?
interesting,
a different approach might be smoothing out integration with the
various vaults/secrets (ex. hashicorp, bitwarden, etc).
Jim
Date: Fri, 30 Sep 2022 10:15:42 +0200
On Fri, 30 Sept 2022 at 10:12, Stefan Eissing via curl-library
<curl-library_at_lists.haxx.se> wrote:
>
>
>
> > Am 30.09.2022 um 09:43 schrieb Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>:
> >
> > 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?
>
>
> I know of threee patterns to solve this problem (and increase usability as a side effect):
>
> 1. macOS keychain which persists credentials and makes them available to authorized applications
> 2. ssh-agent
> 3. neverbleed (https://github.com/h2o/neverbleed) that spawns a process, using pipes to handle keys in out-of-process memory
>
> Maybe a "curl-agent" could be a portable approach?
interesting,
a different approach might be smoothing out integration with the
various vaults/secrets (ex. hashicorp, bitwarden, etc).
Jim
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-09-30