Re: Security support status of xnf(4) and xbf(4)

[Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx>]

On 3/25/22 18:42, Chris Cappuccio wrote:
> Demi Marie Obenour [demi@xxxxxxxxxxxxxxxxxxxxxx] wrote:
>> Linux???s netfront and blkfront drivers recently had a security
>> vulnerability (XSA-396) that allowed a malicious backend to potentially
>> compromise them.  In follow-up audits, I found that OpenBSD???s xnf(4)
>> currently trusts the backend domain.  I reported this privately to Theo
>> de Raadt, who indicated that OpenBSD does not consider this to be a
>> security concern.
>>
> 
> A malicious backend could completely compromise the virtual host in an
> infinite number of ways.

This is only true if the backend runs in dom0 (the privileged
administrative VM) or is otherwise trusted (perhaps because it stores
the root filesystem).  It is not true in general, and is explicitly
false in Qubes OS.  In Qubes OS, the only backend that can directly
compromise the VM is the disk backend running in dom0 that provides
the default volumes.  The network backend and other disk backends are
explicitly considered to be untrusted.

> Perhaps a small patch to find incorrect values
> would be of value, but even then, a patch would only be a very slight
> improvment. If you patch the manual page, should OpenBSD start putting
> notifications in all manual pages that a compromised virtual machine
> backend may compromise the integrity of the virtual host?

No, because emulated devices are provided by an I/O emulator that is
considered trusted.  xnf(4) and xbf(4) devices can be provided by a
backend that is not dom0 and which has (barring other vulnerabilities)
no other way to attack the guest.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature