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: Stefan Eissing via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 30 Sep 2022 13:49:40 +0200
> Am 30.09.2022 um 13:41 schrieb Daniel Stenberg <daniel_at_haxx.se>:
>
> On Fri, 30 Sep 2022, Stefan Eissing wrote:
>
>> I know of threee patterns to solve this problem (and increase usability as a side effect):
>
> Those methods transfer the data to another process, and that is certainly even more safe since then the sensitive data is not even present in the heap of the first process.
>
> But: introducing a second process or a daemon or something for this purpose, while safer, would be a significant new factor and complication that would basically prevent a huge portion of our users from using it.
>
> I think a simpler first step could be to just "scramble" the data while "long-term stored" in memory.
It's certainly simpler and it makes leaking the "interesting" parts of memory easier. But for cases where someone gets access to all the memory or a core dump, it will not make things more secure, just obscure.
One thing I have seen for memory scanning protection is to put protected pages around the location where sensitive data is. So someone scanning memory from above or below will run into a segfault.
-Stefan
Date: Fri, 30 Sep 2022 13:49:40 +0200
> Am 30.09.2022 um 13:41 schrieb Daniel Stenberg <daniel_at_haxx.se>:
>
> On Fri, 30 Sep 2022, Stefan Eissing wrote:
>
>> I know of threee patterns to solve this problem (and increase usability as a side effect):
>
> Those methods transfer the data to another process, and that is certainly even more safe since then the sensitive data is not even present in the heap of the first process.
>
> But: introducing a second process or a daemon or something for this purpose, while safer, would be a significant new factor and complication that would basically prevent a huge portion of our users from using it.
>
> I think a simpler first step could be to just "scramble" the data while "long-term stored" in memory.
It's certainly simpler and it makes leaking the "interesting" parts of memory easier. But for cases where someone gets access to all the memory or a core dump, it will not make things more secure, just obscure.
One thing I have seen for memory scanning protection is to put protected pages around the location where sensitive data is. So someone scanning memory from above or below will run into a segfault.
-Stefan
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-09-30