I know the developers at ITL have their hands busy with this right issue
right now, but I have a (long winded) curiosity question in hope to gain
some context when you get a chance to think about it.
I can see that in this particular potential exploit one might use a
client vm's PCI device to exploit an emulated instruction, then used to
generate a memory offset that potentially could be used as a pointer to
break out of the Xen hypervisor jail. Correct?
My question here would be whether the Xen FLASK subsystem might have
given some level of protections against this kind of "emulated"
instruction exploit, given that labeling of virtual devices and memory
is supported (e.g. flask-label-pci). I realize you may need to give
client VMs access to pci devices in general, and this particular pci
label does not protect against use of pointers to memory, but could the
client call then be restricted to just the necessary IO memory in this
case, and thus forcing an AVC denial fault when that generated pointer
is actually used outside that range? Or are these emulated instructions
running in a hypervisor context that would ignore its own FLASK policy?
I am merely asking the above because when it comes to security I am
definitely a belt and suspenders kind of person. My way of thinking
would be to instrument the system such that the FLASK subsystem, in both
the client VM's and in Xen itself, would feed back into an active
intrusion detection mechanism, so that any fault could instantly freeze
a client VM for forensic analysis purposes.
An intruder is going to try certain things, like jiggling door knobs so
to speak, and in this particular case just trying to access any pci
device that has not explicit permissions set, the system would trap the
intruders process, caught right in the very act of trying to take
ownership of the hypervisor. Exploit code still loaded in memory, source
code possibly still available, network context still in tack. Game over.
You loose. Please try again!
From the Xen FLASK docs:
"Device Labeling in Policy
-------------------------
FLASK is capable of labeling devices and enforcing policies associated
with them. There are two methods to label devices: dynamic labeling
using flask-label-pci or similar tools run in dom0, or static labeling
defined in policy. Static labeling will make security policy
machine-specific and may prevent the system from booting after any
hardware changes (adding PCI cards, memory, or even changing certain
BIOS settings). Dynamic labeling requires that the domain performing the
labeling be trusted to label all the devices in the system properly."
and...
"The AVC denials for IRQs, memory, ports, and PCI devices will normally
contain the ranges being denied to more easily determine what resources
are required. When running in permissive mode, only the first denial of
a given source/destination is printed to the log, so labeling devices
using this method may require multiple passes to find all required ranges."
My thoughts. In the default permissive mode (in XSM:FLASK & SELinux) all
avc's generated could be collected and used to auto-generate a security
policy file (e.g audit2allow) specifically for that particular system
and installed software. When installing a new subsystem a user would
place the system/clientVM in this special collection mode, run and
exercise the system for a period of time to allow all the proper avc's
to be identified, then run the avc's it collected back through a policy
generator. Last of all they install that new security policy and
activate it. This way the system knows all features that user/system
needs explicit permissions for, and anything outside of that set would
by default create avc events that either centrally warn the owner of a
potential intrusion or for just certain faults, immediately freeze the
intruders client VM process in place. Carbonite the exploit toolkit
right in place.
The absolute worst possible situation to be in is being hacked _and_ not
knowing it. A good mechanism for detection is paramount if you want to
prevent that. You may not be able to prevent software bugs from being
exploited, but you don't need to give the intruder the chance to clean
you out and take it all. Active policy could simply slam the lid on the
cookie jar and limit the damage done.
In Qubes we deliberately give sudo/root capability by default to the
general user, which is great for the user, but not so great if an
intruder knows how to become persistent and invisible within a VM. That
is rather easy once you have used Qubes and understand its file system
design. If they are editing /rw/usr/local, and it were labeled as off
limits for write by root, and the system actively trapped an intruders
attempt to hook into it, then we would all be much better off not
needing to do useless tripwire on everything, and wasting valuable CPU
time while still missing the files the rootkit has been actively hiding.
APT is likely preventable if you have the tools to trap their initial
probes and exploits rather than log them, and while we watch, the logs
just get removed to clean up behind them. If we don't know to check a
log before its removed then what has it accomplished? The answer is it
needs to be event driven, and then perform active measures in response
to any detectable tampering. Not all is detectable, but a lot of it is.
I realize Joanna has previously expressed her opinion about SELinux
being pretty much useless for prevention of intrusions, in comparison to
the protections that the hypervisor provides. I would agree with that.
But, what I also think is that we are missing out on a good set of
intrusion detection tools, and that a stock Qubes system simply built
and set up in permissive mode by default might be just the ticket for
the development of an active exploit detection system. We would just
need a way to collect all those events into some kind of a policy rule
based decision making service and act on certain high risk events. This
likely needs Xen support of some kind, or an RPC mechanism for passing
events back from the client to be evaluated. If a user wants active
protections they just need to put it in 'learning mode' for a while and
then turn on the new policy for active protection going forward.
We all know ITL developers have their hands full with what you already
have on your plate. We users appreciate everything you do, and I for one
would love to see what can be done to improve on a few things and give
back to the community. I have not yet built Qubes from scratch, and as
dynamic as the development changes have been I had been holding off. If
this does not run counter to the goals of ITL I may look into this one
day, and hopefully it will help prevent other future such exploits like
this one from being successful. Your thoughts would be appreciated.
Thanks again for all that you do,
Steve
On 11/22/2016 07:44 AM, Marek Marczykowski-Górecki wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Dear Qubes users,
We have just released a new Qubes Security Bulletin (QSB #27):
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-027-2016.txt
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJYND2gAAoJENuP0xzK19csZDEH/3khwJcaCdDCLuueMOxQD41D
pA0/uTck63+SvwcUTaCDldWD4RznX4H4F/JQvZz4xjv/xHDkPkeWC9PlGU+g9k+m
yr9U7ae33tLmSrYS/rinVtu0dJp4ttY3iisr2S+3/ZjU7ZFM46fPhMkXQnUcMrI/
ezSfyLVDWHC/LdmYoKZ6mNHZUN3ioILPmb6NsS1cIOA6aEB6XuFdgdq0DvnoIusb
Shb7h6eGiX4K2WhmToem5g2zg5DsVarUq+TLtZG0aPae8iywf7fHGtGT6KGhPHBL
swyGvR/V2+kFOPaG+1c2C7+2t2wE1DrNvz7rWnX6uMG84R0x89MqqJzcH5ZwM10=
=mkFF
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/9c8fc231-742b-b7cb-ac48-e4afd9f0129e%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.
