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 <[email protected]>:
> >
> > 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."
[[email protected]][+358-50-386 6269]
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
