[pve-devel] [PATCH storage] ZFSPlugin: untaint lun number

[pve-devel] [PATCH storage] ZFSPlugin: untaint lun number

[Stoiko Ivanov]

ZFS over iSCSI fetches information about the disk-images via ssh, thus
the obtainted data is tainted (perlsec (1)).

Since pvedaemon runs with '-T' enabled trying to start a VM via GUI/API failed,
while it still worked via `qm` or `pvesh`.

The issue surfaced after commit cb9db10c1a9855cf40ff13e81f9dd97d6a9b2698 in
pve-common ('run_command: improve performance for logging and long lines'),
and results from concatenating the original (tainted) buffer to a variable,
instead of a captured subgroup.

Untainting the value in ZFSPlugin should not cause any regressiosn, since the
other 3 target providers already have a match on '\d+' for retrieving the
lun number.

reported via pve-user [0].

reproduced and tested by setting up a LIO-target (on top of a virtual PVE),
adding it as storage and trying to start a guest (with a disk on the
ZFS over iSCSI storage) with `perl -T /usr/sbin/qm start $vmid`

[0] https://lists.proxmox.com/pipermail/pve-user/2020-October/172055.html

Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
---
 PVE/Storage/ZFSPlugin.pm | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/PVE/Storage/ZFSPlugin.pm b/PVE/Storage/ZFSPlugin.pm
index 383f0a0..63b9551 100644
--- a/PVE/Storage/ZFSPlugin.pm
+++ b/PVE/Storage/ZFSPlugin.pm
@@ -159,7 +159,11 @@ sub zfs_get_lun_number {
 
     die "could not find lun_number for guid $guid" if !$guid;
 
-    return $class->zfs_request($scfg, undef, 'list_view', $guid);
+    if ($class->zfs_request($scfg, undef, 'list_view', $guid) =~ /^(\d+)$/) {
+	return $1;
+    }
+
+    die "lun_number for guid $guid is not a number";
 }
 
 # Configuration
-- 
2.20.1

Re: [pve-devel] [PATCH storage] ZFSPlugin: untaint lun number

[Daniel Berteaud]

----- Le 9 Oct 20, à 17:13, Stoiko Ivanov s.ivanov@proxmox.com a écrit :

> ZFS over iSCSI fetches information about the disk-images via ssh, thus
> the obtainted data is tainted (perlsec (1)).
> 
> Since pvedaemon runs with '-T' enabled trying to start a VM via GUI/API failed,
> while it still worked via `qm` or `pvesh`.
> 
> The issue surfaced after commit cb9db10c1a9855cf40ff13e81f9dd97d6a9b2698 in
> pve-common ('run_command: improve performance for logging and long lines'),
> and results from concatenating the original (tainted) buffer to a variable,
> instead of a captured subgroup.
> 
> Untainting the value in ZFSPlugin should not cause any regressiosn, since the
> other 3 target providers already have a match on '\d+' for retrieving the
> lun number.
> 
> reported via pve-user [0].
> 
> reproduced and tested by setting up a LIO-target (on top of a virtual PVE),
> adding it as storage and trying to start a guest (with a disk on the
> ZFS over iSCSI storage) with `perl -T /usr/sbin/qm start $vmid`
> 
> [0] https://lists.proxmox.com/pipermail/pve-user/2020-October/172055.html
> 
> Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
> ---
> PVE/Storage/ZFSPlugin.pm | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/PVE/Storage/ZFSPlugin.pm b/PVE/Storage/ZFSPlugin.pm
> index 383f0a0..63b9551 100644
> --- a/PVE/Storage/ZFSPlugin.pm
> +++ b/PVE/Storage/ZFSPlugin.pm
> @@ -159,7 +159,11 @@ sub zfs_get_lun_number {
> 
>     die "could not find lun_number for guid $guid" if !$guid;
> 
> -    return $class->zfs_request($scfg, undef, 'list_view', $guid);
> +    if ($class->zfs_request($scfg, undef, 'list_view', $guid) =~ /^(\d+)$/) {
> +	return $1;
> +    }
> +
> +    die "lun_number for guid $guid is not a number";
> }


Will give this a try ASAP !
Thanks


-- 
[ https://www.firewall-services.com/ ] 	
Daniel Berteaud 
FIREWALL-SERVICES SAS, La sécurité des réseaux 
Société de Services en Logiciels Libres 
Tél : +33.5 56 64 15 32 
Matrix: @dani:fws.fr 
[ https://www.firewall-services.com/ | https://www.firewall-services.com ]

Re: [pve-devel] [PATCH storage] ZFSPlugin: untaint lun number

[Daniel Berteaud]

----- Le 9 Oct 20, à 17:26, Daniel Berteaud daniel@firewall-services.com a écrit :

> ----- Le 9 Oct 20, à 17:13, Stoiko Ivanov s.ivanov@proxmox.com a écrit :
> 
>> ZFS over iSCSI fetches information about the disk-images via ssh, thus
>> the obtainted data is tainted (perlsec (1)).
>> 
>> Since pvedaemon runs with '-T' enabled trying to start a VM via GUI/API failed,
>> while it still worked via `qm` or `pvesh`.
>> 
>> The issue surfaced after commit cb9db10c1a9855cf40ff13e81f9dd97d6a9b2698 in
>> pve-common ('run_command: improve performance for logging and long lines'),
>> and results from concatenating the original (tainted) buffer to a variable,
>> instead of a captured subgroup.
>> 
>> Untainting the value in ZFSPlugin should not cause any regressiosn, since the
>> other 3 target providers already have a match on '\d+' for retrieving the
>> lun number.
>> 
>> reported via pve-user [0].
>> 
>> reproduced and tested by setting up a LIO-target (on top of a virtual PVE),
>> adding it as storage and trying to start a guest (with a disk on the
>> ZFS over iSCSI storage) with `perl -T /usr/sbin/qm start $vmid`
>> 
>> [0] https://lists.proxmox.com/pipermail/pve-user/2020-October/172055.html
>> 
>> Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
>> ---
>> PVE/Storage/ZFSPlugin.pm | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>> 
>> diff --git a/PVE/Storage/ZFSPlugin.pm b/PVE/Storage/ZFSPlugin.pm
>> index 383f0a0..63b9551 100644
>> --- a/PVE/Storage/ZFSPlugin.pm
>> +++ b/PVE/Storage/ZFSPlugin.pm
>> @@ -159,7 +159,11 @@ sub zfs_get_lun_number {
>> 
>>     die "could not find lun_number for guid $guid" if !$guid;
>> 
>> -    return $class->zfs_request($scfg, undef, 'list_view', $guid);
>> +    if ($class->zfs_request($scfg, undef, 'list_view', $guid) =~ /^(\d+)$/) {
>> +	return $1;
>> +    }
>> +
>> +    die "lun_number for guid $guid is not a number";
>> }
> 


I can confirm this is fixing the issue of the VM not starting from the web interface. There's still a (probably) related issue : ZFS over iSCSI disks can't be removed (eg, at the end of a live disk move) :

Use of uninitialized value in die at /usr/share/perl5/PVE/Storage/LunCmd/LIO.pm line 337.
error during cfs-locked 'storage-iscsi-zfs-zol1-prd' operation: command '/usr/bin/ssh -o 'BatchMode=yes' -i /etc/pve/priv/zfs/10.29.255.252_id_rsa root@10.29.255.252 -- /usr/bin/targetcli /iscsi/iqn.2019-10.fr.fws.pve:prod/tpg1/luns/ delete lun1' failed: Insecure dependency in exec while running with -T switch at /usr/share/perl/5.28/IPC/Open3.pm line 178.
	...propagated at /usr/share/perl5/PVE/Storage/LunCmd/LIO.pm line 337.

It might be only affecting the LIO backend though

Cheers,
Daniel


-- 
[ https://www.firewall-services.com/ ] 	
Daniel Berteaud 
FIREWALL-SERVICES SAS, La sécurité des réseaux 
Société de Services en Logiciels Libres 
Tél : +33.5 56 64 15 32 
Matrix: @dani:fws.fr 
[ https://www.firewall-services.com/ | https://www.firewall-services.com ]

[pve-devel] applied: [PATCH storage] ZFSPlugin: untaint lun number

[Thomas Lamprecht]

On 09.10.20 17:13, Stoiko Ivanov wrote:
> ZFS over iSCSI fetches information about the disk-images via ssh, thus
> the obtainted data is tainted (perlsec (1)).
> 
> Since pvedaemon runs with '-T' enabled trying to start a VM via GUI/API failed,
> while it still worked via `qm` or `pvesh`.
> 
> The issue surfaced after commit cb9db10c1a9855cf40ff13e81f9dd97d6a9b2698 in
> pve-common ('run_command: improve performance for logging and long lines'),
> and results from concatenating the original (tainted) buffer to a variable,
> instead of a captured subgroup.
> 
> Untainting the value in ZFSPlugin should not cause any regressiosn, since the
> other 3 target providers already have a match on '\d+' for retrieving the
> lun number.
> 
> reported via pve-user [0].
> 
> reproduced and tested by setting up a LIO-target (on top of a virtual PVE),
> adding it as storage and trying to start a guest (with a disk on the
> ZFS over iSCSI storage) with `perl -T /usr/sbin/qm start $vmid`
> 
> [0] https://lists.proxmox.com/pipermail/pve-user/2020-October/172055.html
> 
> Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
> ---
>  PVE/Storage/ZFSPlugin.pm | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
>

applied, thanks!

Re: [pve-devel] [PATCH storage] ZFSPlugin: untaint lun number

[Stoiko Ivanov]

On Fri, 9 Oct 2020 17:44:22 +0200 (CEST)
Daniel Berteaud <daniel@firewall-services.com> wrote:

> ----- Le 9 Oct 20, à 17:26, Daniel Berteaud daniel@firewall-services.com a écrit :
> 
> > ----- Le 9 Oct 20, à 17:13, Stoiko Ivanov s.ivanov@proxmox.com a écrit :
> >   
> >> ZFS over iSCSI fetches information about the disk-images via ssh, thus
> >> the obtainted data is tainted (perlsec (1)).
> >> 
> >> Since pvedaemon runs with '-T' enabled trying to start a VM via GUI/API failed,
> >> while it still worked via `qm` or `pvesh`.
> >> 
> >> The issue surfaced after commit cb9db10c1a9855cf40ff13e81f9dd97d6a9b2698 in
> >> pve-common ('run_command: improve performance for logging and long lines'),
> >> and results from concatenating the original (tainted) buffer to a variable,
> >> instead of a captured subgroup.
> >> 
> >> Untainting the value in ZFSPlugin should not cause any regressiosn, since the
> >> other 3 target providers already have a match on '\d+' for retrieving the
> >> lun number.
> >> 
> >> reported via pve-user [0].
> >> 
> >> reproduced and tested by setting up a LIO-target (on top of a virtual PVE),
> >> adding it as storage and trying to start a guest (with a disk on the
> >> ZFS over iSCSI storage) with `perl -T /usr/sbin/qm start $vmid`
> >> 
> >> [0] https://lists.proxmox.com/pipermail/pve-user/2020-October/172055.html
> >> 
> >> Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
> >> ---
> >> PVE/Storage/ZFSPlugin.pm | 6 +++++-
> >> 1 file changed, 5 insertions(+), 1 deletion(-)
> >> 
> >> diff --git a/PVE/Storage/ZFSPlugin.pm b/PVE/Storage/ZFSPlugin.pm
> >> index 383f0a0..63b9551 100644
> >> --- a/PVE/Storage/ZFSPlugin.pm
> >> +++ b/PVE/Storage/ZFSPlugin.pm
> >> @@ -159,7 +159,11 @@ sub zfs_get_lun_number {
> >> 
> >>     die "could not find lun_number for guid $guid" if !$guid;
> >> 
> >> -    return $class->zfs_request($scfg, undef, 'list_view', $guid);
> >> +    if ($class->zfs_request($scfg, undef, 'list_view', $guid) =~ /^(\d+)$/) {
> >> +	return $1;
> >> +    }
> >> +
> >> +    die "lun_number for guid $guid is not a number";
> >> }  
> >   
> 
> 
> I can confirm this is fixing the issue of the VM not starting from the web interface. There's still a (probably) related issue : ZFS over iSCSI disks can't be removed (eg, at the end of a live disk move) :

Thanks for testing it so quickly!
> 
> Use of uninitialized value in die at /usr/share/perl5/PVE/Storage/LunCmd/LIO.pm line 337.
> error during cfs-locked 'storage-iscsi-zfs-zol1-prd' operation: command '/usr/bin/ssh -o 'BatchMode=yes' -i /etc/pve/priv/zfs/10.29.255.252_id_rsa root@10.29.255.252 -- /usr/bin/targetcli /iscsi/iqn.2019-10.fr.fws.pve:prod/tpg1/luns/ delete lun1' failed: Insecure dependency in exec while running with -T switch at /usr/share/perl/5.28/IPC/Open3.pm line 178.
> 	...propagated at /usr/share/perl5/PVE/Storage/LunCmd/LIO.pm line 337.
You're right - I'll come up with a patch for the other places wher the LIO
Backend needs untainting and will send a patch.

Best Regards,
stoiko


> 
> It might be only affecting the LIO backend though
> 
> Cheers,
> Daniel
> 
>