Qubes Security Bulletin #27

[Marek Marczykowski-Górecki]

-----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-----

[Chris Laprise]

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
>
> - --

Updates not visible yet...

I'm assuming if I have Xen 4.6.3-21 from testing, the update from
standard repo should go OK.

Chris

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Did you make sure to enable the qubes-dom0-security-testing repo? I was able
to download the updates just a few minutes ago.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYNEsdAAoJENtN07w5UDAwvcAP/RYlA4ZKz4d/7atCTnGZV7tI
cCYYaUYoL91Q0VfLYIWGkcJbXvs0cpodGDdKapYEFztESMRLZ7fR0+L3zAcftA9k
gEAc12qt2KtcJW2TrYOzcg0lI1OZp7a54VWLjuiRgTfYJutpcZIl77rnbm+qGDzg
MDH+4jgIelWIDL/oLCgmQ4mxR3lxGCpROC4XTcG/GTdV1YgWUnuMWp92FHcfkuwM
1eilKs3MXsy/0Yyo09eEq6AaX2oa9xje/9Qf2DLACzhPiJJ3VTMSbbz6yYVyFlLz
yj/PU5b1PPJYWBW5YKGWZFFQ3azYffHNlxXLXJ+zAb7+wusI67aDZAbxqr8fCTMN
pBI3yYg3QH2m66nsEOBwSmAChLo5hbkEWpun7OpQ4MBRDZ212Xi0WlEpCzBAQb90
SyjSnCNe3OpMWSOu9NWw3W0w7wbofEZXajAwV7v2bjTr2BjNCn09g3/yNZu4qq1i
Dd0wvDdJGrNcSZCMMP1Imhg3aWQt/QcXpxmT1oGYoBET78hO9K31VzQG2hi8/i/d
zN0x07Bdi+ueFViQFDf7YtpH4rFRvXzxwCz1elG6TyV785e1XHK5i8DKFKG9+Uq6
zDVh6U2W7OxCUYCIcqHC/LD8fPDva1+om2Q21E8RwVVBYeuQxdsUMlouPgpaA0op
q/jhRTlQr6cTCNW5uKfA
=NLON
-----END PGP SIGNATURE-----

[Chris Laprise]

On 11/22/2016 08:41 AM, Andrew David Wong wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 11/22/16 05:37, Chris Laprise wrote:
>> On 11/22/2016 07:44 AM, Marek Marczykowski-Górecki wrote:
>>> 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
>>>
>>> - --
>> Updates not visible yet...
>>
>> I'm assuming if I have Xen 4.6.3-21 from testing, the update from standard repo should go OK.
>>
>> Chris
>>
> Did you make sure to enable the qubes-dom0-security-testing repo? I was able
> to download the updates just a few minutes ago.
>
> - --

No, I didn't. Although the QSB mentions the upload to security-testing
it also says:
"The packages are to be installed in Dom0 via qubes-dom0-update command
or via the Qubes graphical manager."

...which somehow didn't suggest I use --enablerepo on the command line.

Anyway, its downloading now.

Chris

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11/22/16 06:13, Chris Laprise wrote:
> On 11/22/2016 08:41 AM, Andrew David Wong wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> On 11/22/16 05:37, Chris Laprise wrote:
>>> On 11/22/2016 07:44 AM, Marek Marczykowski-Górecki wrote:
>>>> 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
>>>>

>>> Updates not visible yet...
>>>
>>> I'm assuming if I have Xen 4.6.3-21 from testing, the update from standard repo should go OK.
>>>
>>>

>> Did you make sure to enable the qubes-dom0-security-testing repo? I was able
>> to download the updates just a few minutes ago.
>>
>

> No, I didn't. Although the QSB mentions the upload to security-testing it also says:
> "The packages are to be installed in Dom0 via qubes-dom0-update command or via the Qubes graphical manager."
>
> ...which somehow didn't suggest I use --enablerepo on the command line.
>
> Anyway, its downloading now.
>

I'm not quite sure what you're getting at, but I think it's worded that way intentionally. You're not required to download the updates as soon as they become available. There's a reason the standard procedure is for them to sit in security-testing for a while before they move to the stable repo. Only users who are willing to test the packages should download and install them at this point. Once they move to the stable repo, no one will have to use --enablerepo to get them.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYNFigAAoJENtN07w5UDAwC2MQAKTyLMecuWuQ/wUqi6wGzX62
n6jvV8sUzBrObDhpm9pSslHW83A/tTtMA+MT7K10J8R6rrL+nRC0I74z0n8Kkw7w
70wdw6Fe9YYwOx0CqhRY+TIt1RGiYldg0YCSn+pKp7uCX5jese16xP5i3ORf3U41
XqNjG15BbZK0LqAYiznAk5JSyEL7Et3TUbeEFXTar/FjpsYXxFcUk3OL23/4cCvY
naveHT6HpdAODDu6T+qTwI4M6RIFh1CLZhlaW+tAXSZgQ4gWk2NvIX7k213hN/GL
1vrrleFAtFpRjR/yXTUeYRcAKQ/v8yDMDSaZnJWyjMMgrpt1HyhwzgtoEsveFPiK
w7DJO86HihuhvvXg4YVFxmgCMZCJkBhma98hW/rVfYIx6qvlGRKq4lZLjpiXplgq
hhgag32GqNrEA+cSHB3fURrIgTEw+5e90BULZcSDzc+BWg02QQBNcnIYjF00gcGd
z88r5MjqdqqTfeYZgANfdhehZCZrEVhoxYiO45QkUiYJoh4hVO3cKNmjJsMty23s
Uqbh0sIrPmV9v3awT6cSjFL3mMEknazEqZgBdPbeD8PTuZHLDp3hKd4XpewhHGsx
kvXiB+4q1svh4/HwTYMPy//84ldoodFmA+NVR/GyMAVp4UjQGhC+jrSMO+erNac3
cIfyDm9VCmG4XcJc61Pc
=WJm4
-----END PGP SIGNATURE-----

[Steve Coleman]

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:

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Nov 22, 2016 at 01:30:31PM -0500, Steve Coleman wrote:
> 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?

The later case. Additionally I don't think XSM is plugged in x86_emulate
anywhere. If domain is given permission to access some resource (and
the policy allow it at this stage), it isn't re-checked later. At least
this is my understanding of quick grep results.


Generally XSM/FLASK policy can be used only to limit what operations can
be triggered by a VM. If implementation of particular operation is
buggy, and the operation itself is allowed by XSM, that's over. None of
last Xen critical bugs affecting Qubes OS could be stopped by proper
XSM/FLASK policy. Exactly for the same reason. On the other hand, our
architecture (for example having qemu sandboxed in stub domain, not
using pygrub, etc) make most of Xen vulnerabilities harmless for Qubes
OS.

XSM could help if the buggy operation would not be needed at all - in
this case it could be blocked by the policy, so would be out of reach
for the attacker. But if the operation isn't needed, maybe it shouldn't
be in the hypervisor at all? This is why we're advocating for having as
much as (reasonably) possible code disabled compile time using Kconfig.

Not supporting non-SLAT/EPT hardware in Qubes 4.0 is one of those things
- - we do not include shadow page table code at all there. It isn't
possible to compile-time disable all the PV handling code, at least
not yet. But work towards PVHv2 might make it possible (in Xen 4.9
perhaps...). But still - instruction emulation in some cases still would
be needed...

- --
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

iQEcBAEBCAAGBQJYNM1zAAoJENuP0xzK19csOIEH/jE05gE1u7BaqZLoQ7RX0iWt
KSHKoyWV4xR0pWSMxob4bhGBj2Ktyh5m9CARg36XiwDLaDNgrD1NmH8ouIak6yqW
1MFL2FM4MaNDukYdUbPdR5I1jSFynAS+dD4wD6WH5IzKSiWWh3avreMEXn173pyr
lKPu5VevjoXkIYAhW2Q8QVKePKHYiXO25HaaeQ4urOqk3e9VgV4mqcW/c/rgZJfs
mkIfn1O3hXo5aZmFYVMnCJcIYggh6bGqZy6GO/Btlg8VTacB5eoriAXKi8zghFBy
lGRdswSXCaSPnR8QFdxj2HYH1mOfoZdntOTT6X3CKM4Gntvil7at/XwDU3dUrYE=
=hTm6
-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

On Tue, Nov 22, 2016 at 1:30 PM, Steve Coleman <Steve....@jhuapl.edu> wrote:
> ... 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.

There are two points here:

1) Make inspection event-triggered such that an exploit which cleans
up after itself is observable (avoid ABA problem inherent to e.g.
periodic scanning).

2) Make logged events immutable.


#1 Is a challenging problem of what to hook and how to find signal in
the noise. I do not have any answers here and would be happy to be
pointed at relevant material.

#2 (assuming we are interested in events within a VM and that the
isolation properties of our hypervisor holds) can be solved by storing
append-only logs in a separate VM, with data sent over existing qubes
rpc system. There has already been discussion and PoCs of this in
context of build logs, but it is applicable to much more as well. This
is on my (and undoubtedly others') personal Qubes to-do list.

[Fred]

Will qubes-dom0-update work for Qubes users not using the testing
repositories?

[Franz]

On Wed, Nov 23, 2016 at 7:05 AM, Fred <curious...@gmsl.co.uk> wrote:

Will qubes-dom0-update work for Qubes users not using the testing
repositories?

Yes, but just wait a few days after testing is passed.

Best

Fran

--
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 qubes-users+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b6e7a8d9-f40f-46ac-7d34-d274574c1eca%40gmsl.co.uk.

For more options, visit https://groups.google.com/d/optout.

[quat...@tutanota.com]

Hi,
When, this update, will be released in the main repositories?

Do you suggest us to enable testing?

Thanks you


--
Securely sent with Tutanota. Claim your encrypted mailbox today!
https://tutanota.com

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Nov 28, 2016 at 04:01:26PM +0100, quat...@tutanota.com wrote:
> Hi,
> When, this update, will be released in the main repositories?

A week after initial release, so - tomorrow.

- --
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

iQEcBAEBCAAGBQJYPEedAAoJENuP0xzK19cs9jYH/33eaH2sahfAJJS5cXGpFndL
jcD9+iN9jsKt91J/LCQY0GmF7dD3zVVX0T5SSO0A/vp8tMD2A/RX/gibEoQRSwPr
pHRm+WePtNR03l9k98zgAs383sPKGKKU7TIn7tPZUr4Dz80YC/Q2B/khOoLB/cyU
QJkA7bxFeZIMREDfjrPJoq1Ne91/5CXGO1CuNQAfhVfEcy4hDtEKeQt947XTdCub
RUuvEi9wiBOHa2TdgWQn5hdvuK6MnvacBCc01H8VbMghutJbjobQ4r8yC+YpEx16
RLOEr++0aff1uxntPtM3IJFt+aBBkC1AnFBSZ8t8dK1weGxqt9PutbjTXnHfhUM=
=e2b7
-----END PGP SIGNATURE-----