> Am 30.09.2022 um 09:43 schrieb Daniel Stenberg via curl-library
> <curl-library@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?
Kind Regards,
Stefan
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
