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.
smime.p7s
Description: S/MIME cryptographic signature
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
