Dan Fandrich via curl-library wrote: > However, if the attacker somehow only has access to the memory and not the > rest > of the process' assets (case 2.), then use of a hardware security device can > protect the > keys from directly being stolen, But, there will be some times that curl needs > the raw secrets in order to pass them to other dependencies or write them into > buffers, and when they're in memory, the attacker can still get them. And if > they're in memory, then can end up on disk in a core or hibernation file where > the attacker can read them. > > The 3. case is the most interesting one that this proposal could help > mitigate. > A Heartbleed-style bug that gives arbitrary memory to an attacker could return > memory containing a secret. If secrets are not stored in plaintext in RAM, > then > it becomes much harder to obtain those secrets. But it's still not perfect. > > Here are some possible mitigations we could implement in curl:
Store sensitive keys in a dedicated mmap'd region, mprotect the region to remove read access whenever the key isn't actively being used. -- -- 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.html
