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: Howard Chu via curl-library <curl-library_at_lists.haxx.se>
Date: Sun, 20 Nov 2022 20:07:44 +0000
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.
Date: Sun, 20 Nov 2022 20:07:44 +0000
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.htmlReceived on 2022-11-20