* Re: [pve-devel] Arbitrary file reading via malicious VM config
[not found] <tencent_C3D2C670AE0CC99C45BA8C83853D3BDE0205@qq.com>
@ 2024-11-27 8:09 ` Thomas Lamprecht
2024-11-27 8:15 ` Thomas Lamprecht
0 siblings, 1 reply; 2+ messages in thread
From: Thomas Lamprecht @ 2024-11-27 8:09 UTC (permalink / raw)
To: James Brown, Fabio Fantoni via pve-devel
Hello,
First, if you, or anybody else, think they found a problem with security implications
then please use our dedicated confidential channels for evaluating that initially:
https://pve.proxmox.com/wiki/Security_Reporting
If it's a real problem then other users might not be happy about a public broadcast
for all potential attackers to read and basically act as how-to.
Am 27.11.24 um 01:14 schrieb James Brown:
> I suspect a security flaw within ESXi VM import. If a malicious actor forges a
> VMWare VM config with root paths such as /var/log/auth.log, could lead to potential
> data leak if the import task is executed.
The core assumption is that the admin doing the import fully controls both sides,
VMWare ESXi and Proxmox VE.
As otherwise this feature makes no sense, if the ESXi isn't trusted, it can do all
sorts of bad things that just cannot be protected against, like e.g., inject some
rootkits into the VM data stream at any time. And yes, it might also leak some
data from the PVE host.
For OVA imports we hedge against that by disallowing disks with additional/external
references. For ESXi we do not do so because 1) it's more common there to have legit
references in the disks (which are not trivial to tell apart from bad ones) and 2)
because compared to allowing third-party/not fully trusted users uploading images
allowing one to add an ESXi storage and then import from there is IMO a rather
non-existent use case, and that would also mean that ESXi and Proxmox VE are either
in the same LAN or tunneled, as otherwise they should be shielded off from public
access already anyway.
But do you have an actual use case we missed and would break our assumptions here?
What we might do is documenting this more explicitly, possibly even showing a hint
in the UI.
- Thomas
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [pve-devel] Arbitrary file reading via malicious VM config
2024-11-27 8:09 ` [pve-devel] Arbitrary file reading via malicious VM config Thomas Lamprecht
@ 2024-11-27 8:15 ` Thomas Lamprecht
0 siblings, 0 replies; 2+ messages in thread
From: Thomas Lamprecht @ 2024-11-27 8:15 UTC (permalink / raw)
To: James Brown, Fabio Fantoni via pve-devel
Am 27.11.24 um 09:09 schrieb Thomas Lamprecht:
> The core assumption is that the admin doing the import fully controls both sides,
> VMWare ESXi and Proxmox VE.
> As otherwise this feature makes no sense, if the ESXi isn't trusted, it can do all
> sorts of bad things that just cannot be protected against, like e.g., inject some
> rootkits into the VM data stream at any time. And yes, it might also leak some
> data from the PVE host.
btw. what I forgot: This is not really special to the ESXi "storage" that can be
used for import, but any storage attached through network in general.
There is no definitive way to check all potential problems in a race-free way.
But stating that core assumptions one more time explicitly definitively won't
hurt for our docs.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2024-11-27 8:15 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <tencent_C3D2C670AE0CC99C45BA8C83853D3BDE0205@qq.com>
2024-11-27 8:09 ` [pve-devel] Arbitrary file reading via malicious VM config Thomas Lamprecht
2024-11-27 8:15 ` Thomas Lamprecht
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox