From jean-francois.hren at stormshield.eu  Fri Oct  1 11:40:30 2021
From: jean-francois.hren at stormshield.eu (Jean-Francois HREN)
Date: Fri, 1 Oct 2021 11:40:30 +0200 (CEST)
Subject: [strongSwan-dev] Memwipe of loaded secrets through VICI
In-Reply-To: <322054bd-bb83-530f-c2a5-eb3d186edca0@strongswan.org>
References: <348180694.2223752.1632991228698.JavaMail.zimbra@stormshield.eu>
 <322054bd-bb83-530f-c2a5-eb3d186edca0@strongswan.org>
Message-ID: <141653972.2716558.1633081230432.JavaMail.zimbra@stormshield.eu>

Hi Tobias, 

Thank you for your answer. I tested the branch and it works for me. 
For the mmap, I'm not expert and I use Strongswan under FreeBSD so I'm not sure the behavior is the same. 
However since decrypted private key blobs are written in the mmap chunk, memory should be allocated somewhere. This memory can be read by some other rogue processes later if not wiped properly. 

In src/swanctl/commands/load_creds.c:load_containers(), a call to chunk_unmap_clear() should be done too maybe ? 
The static buffer returned by getpass() calls in swanctl should be wiped too after use. 


De: "Tobias Brunner" <tobias at strongswan.org> 
À: "jean-francois hren" <jean-francois.hren at stormshield.eu>, "dev" <dev at lists.strongswan.org> 
Envoyé: Jeudi 30 Septembre 2021 15:42:18 
Objet: Re: [strongSwan-dev] Memwipe of loaded secrets through VICI 

Hi Jean-Francois, 

Thanks for the report and patch. I pushed several of these fixes (some 
with modifications) to the wipe-secrets branch, plus also added code to 
wipe the swanctl.conf file from memory in swanctl. 

I'm not entirely sure about the chunk_map() changes, though. As far as 
I can tell, after munmap() has been called, the process can't access 
that memory anymore (causes a segmentation fault). And mapping the same 
memory with MAP_ANONYMOUS and MAP_UNINITIALIZED (to prevent the 
initialization of the non-file backed area to zero) doesn't seem 
possible on generic kernels as it requires the 
CONFIG_MMAP_ALLOW_UNINITIALIZED kernel option, which is usually not 
enabled for security reasons. But since it's useful on platform that 
don't provide mmap() (e.g. Windows), I still pushed patches. 

Let me know what you think. 

Regards, 
Tobias 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20211001/ab9b9a22/attachment.html>

From tobias at strongswan.org  Fri Oct  1 13:55:46 2021
From: tobias at strongswan.org (Tobias Brunner)
Date: Fri, 1 Oct 2021 13:55:46 +0200
Subject: [strongSwan-dev] Memwipe of loaded secrets through VICI
In-Reply-To: <141653972.2716558.1633081230432.JavaMail.zimbra@stormshield.eu>
References: <348180694.2223752.1632991228698.JavaMail.zimbra@stormshield.eu>
 <322054bd-bb83-530f-c2a5-eb3d186edca0@strongswan.org>
 <141653972.2716558.1633081230432.JavaMail.zimbra@stormshield.eu>
Message-ID: <3d933905-83c8-9e9e-1da2-60c9203771f3@strongswan.org>

Hi Jean-Francois,

> For the mmap, I'm not expert and I use Strongswan under FreeBSD so I'm 
> not sure the behavior is the same.

Yeah, don't know either.

> However since decrypted private key blobs are written in the mmap chunk, 

As far as I can tell, that's not the case.  The first thing the pem 
plugin does is cloning the chunk (pem_builder_t:load_from_blob()).  But 
if the key is not encrypted and mmap() is not available, there will 
definitely be another copy of the key in memory that we have to clean.

> In src/swanctl/commands/load_creds.c:load_containers(), a call to 
> chunk_unmap_clear() should be done too maybe ?

While it's possible to create PKCS#12 containers without encryption, I 
don't think that's very common in practice.  But sure, we can add it 
just to be safe.

> The static buffer returned by getpass() calls in swanctl should be wiped 
> too after use.

Thanks, I've pushed another commit that changes that for all getpass() 
calls.

Regards,
Tobias

From jean-francois.hren at stormshield.eu  Fri Oct  1 14:25:53 2021
From: jean-francois.hren at stormshield.eu (Jean-Francois HREN)
Date: Fri, 1 Oct 2021 14:25:53 +0200 (CEST)
Subject: [strongSwan-dev] Memwipe of loaded secrets through VICI
In-Reply-To: <3d933905-83c8-9e9e-1da2-60c9203771f3@strongswan.org>
References: <348180694.2223752.1632991228698.JavaMail.zimbra@stormshield.eu>
 <322054bd-bb83-530f-c2a5-eb3d186edca0@strongswan.org>
 <141653972.2716558.1633081230432.JavaMail.zimbra@stormshield.eu>
 <3d933905-83c8-9e9e-1da2-60c9203771f3@strongswan.org>
Message-ID: <1275580332.2877429.1633091153948.JavaMail.zimbra@stormshield.eu>

Thank you for help again. 
It looks good to me. 
Thank you. 


De: "Tobias Brunner" <tobias at strongswan.org> 
À: "jean-francois hren" <jean-francois.hren at stormshield.eu> 
Cc: "dev" <dev at lists.strongswan.org> 
Envoyé: Vendredi 1 Octobre 2021 13:55:46 
Objet: Re: [strongSwan-dev] Memwipe of loaded secrets through VICI 

Hi Jean-Francois, 

> For the mmap, I'm not expert and I use Strongswan under FreeBSD so I'm 
> not sure the behavior is the same. 

Yeah, don't know either. 

> However since decrypted private key blobs are written in the mmap chunk, 

As far as I can tell, that's not the case. The first thing the pem 
plugin does is cloning the chunk (pem_builder_t:load_from_blob()). But 
if the key is not encrypted and mmap() is not available, there will 
definitely be another copy of the key in memory that we have to clean. 

> In src/swanctl/commands/load_creds.c:load_containers(), a call to 
> chunk_unmap_clear() should be done too maybe ? 

While it's possible to create PKCS#12 containers without encryption, I 
don't think that's very common in practice. But sure, we can add it 
just to be safe. 

> The static buffer returned by getpass() calls in swanctl should be wiped 
> too after use. 

Thanks, I've pushed another commit that changes that for all getpass() 
calls. 

Regards, 
Tobias 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20211001/e8620ea4/attachment.html>