Re: [qubes-users] Qubes Security Bulletin #27
On Wed, Nov 23, 2016 at 7:05 AM, Fred 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+unsubscr...@googlegroups.com. > To post to this group, send email to qubes-users@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ms > gid/qubes-users/b6e7a8d9-f40f-46ac-7d34-d274574c1eca%40gmsl.co.uk. > For more options, visit https://groups.google.com/d/optout. > -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAPzH-qBek_nxrj3Z9PO%3D-ofLRpy8KOa400-kPXZxz0X3_qc1yw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes Security Bulletin #27
Will qubes-dom0-update work for Qubes users not using the testing repositories? -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@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.
Re: [qubes-users] Qubes Security Bulletin #27
On Tue, Nov 22, 2016 at 1:30 PM, Steve Coleman 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. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CABQWM_AwhFQ621fjhEzfNnb9GmF8wup4pNbPJYdUY1n0sppbRw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes Security Bulletin #27
-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- -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2016115754.GH1145%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes Security Bulletin #27
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
Re: [qubes-users] Qubes Security Bulletin #27
-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- -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/93528179-44b7-92e3-66d9-9d9b720cef16%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes Security Bulletin #27
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 -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8baeb0f8-8559-fbc2-bfc6-c545f9eaf01b%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes Security Bulletin #27
-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. - -- 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- -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3ac9f367-0e2e-e5d1-b857-716dd990fa79%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes Security Bulletin #27
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 -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/74ebd3e1-7171-df87-0e11-5933d9c5913b%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes Security Bulletin #27
-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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20161122124415.GA8194%40mail-itl. For more options, visit https://groups.google.com/d/optout.
