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: Ville Likitalo via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 30 Sep 2022 14:55:09 +0300
On Fri, Sep 30, 2022 at 01:49:40PM +0200, Stefan Eissing via curl-library wrote:
>
>
> > 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.
Hi,
Plus (on platforms supporting this) lock the pages into memory
and exclude them from dump. Further question as I did exactly
this for libcurl data with custom memory management; Does libcurl
use the custom memory management also for the passwords?
- Ville
Date: Fri, 30 Sep 2022 14:55:09 +0300
On Fri, Sep 30, 2022 at 01:49:40PM +0200, Stefan Eissing via curl-library wrote:
>
>
> > 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.
Hi,
Plus (on platforms supporting this) lock the pages into memory
and exclude them from dump. Further question as I did exactly
this for libcurl data with custom memory management; Does libcurl
use the custom memory management also for the passwords?
- Ville
-- "I want to move to Theory, everything works in theory." [liki_at_iki.fi][+358-50-386 6269] -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-09-30