On Fri, 30 Sept 2022 at 10:12, Stefan Eissing via curl-library <[email protected]> wrote: > > > > > Am 30.09.2022 um 09:43 schrieb Daniel Stenberg via curl-library > > <[email protected]>: > > > > 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.html
