remote code execution via UDP packets (CVE-2016-10229) in the context of Qubes // and kernel update recommendations
429 views
Skip to first unread message
Joonas Lehtonen
Apr 13, 2017, 8:18:20 PM4/13/17
to qubes-users
https://nvd.nist.gov/vuln/detail/CVE-2016-10229
> udp.c in the Linux kernel before 4.5 allows remote attackers to
> execute arbitrary code via UDP traffic [...]
fixed in [1] (2015-12-30)
It never affected Fedora according to:
https://bugzilla.redhat.com/show_bug.cgi?id=1439740#c2
> This fix was committed upstream in the 4.5 kernel merge window (Dec
> 2015). It has never impacted any of the currently supported versions of
> Fedora.
In Debian it got fixed on 2016-01-5
https://www.debian.org/security/2016/dsa-3434
3.16.7-ckt20-1+deb8u2
https://security-tracker.debian.org/tracker/CVE-2016-10229
Since Qubes VMs depend on dom0 for kernel updates, Qubes user do not get
kernel updates from upstream distros.
- Qubes currently ships kernel 4.4.38 for VMs
Kernel 4.4.38 has been released on 2016-12-10 so I assume it contains
the fix?
- Have Qubes VM kernels (provided by dom0) ever been affected (in the
past of R3.2)?
Since Qubes does not frequently release VM kernel updates*:
Do you recommend to switch to pvgrub and in-VM kernels to be able to
take advantage of regular distro kernel updates?
The upcoming/planed binary packages of coldkernel probably address this
topic as well.
thanks!
Joonas
*) I know, that in-VM security is/should not be relevant for the
isolation between VMs but if someone can compromise all networked VMs
via vulnerabilities in the UDP/TCP/IP stack it is probably as bad as
having no isolation.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=197c949e7798fbf28cfadc69d9ca0c2abbf93191
> udp.c in the Linux kernel before 4.5 allows remote attackers to
> execute arbitrary code via UDP traffic [...]
fixed in [1] (2015-12-30)
It never affected Fedora according to:
https://bugzilla.redhat.com/show_bug.cgi?id=1439740#c2
> This fix was committed upstream in the 4.5 kernel merge window (Dec
> 2015). It has never impacted any of the currently supported versions of
> Fedora.
In Debian it got fixed on 2016-01-5
https://www.debian.org/security/2016/dsa-3434
3.16.7-ckt20-1+deb8u2
https://security-tracker.debian.org/tracker/CVE-2016-10229
Since Qubes VMs depend on dom0 for kernel updates, Qubes user do not get
kernel updates from upstream distros.
- Qubes currently ships kernel 4.4.38 for VMs
Kernel 4.4.38 has been released on 2016-12-10 so I assume it contains
the fix?
- Have Qubes VM kernels (provided by dom0) ever been affected (in the
past of R3.2)?
Since Qubes does not frequently release VM kernel updates*:
Do you recommend to switch to pvgrub and in-VM kernels to be able to
take advantage of regular distro kernel updates?
The upcoming/planed binary packages of coldkernel probably address this
topic as well.
thanks!
Joonas
*) I know, that in-VM security is/should not be relevant for the
isolation between VMs but if someone can compromise all networked VMs
via vulnerabilities in the UDP/TCP/IP stack it is probably as bad as
having no isolation.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=197c949e7798fbf28cfadc69d9ca0c2abbf93191
cooloutac
Apr 13, 2017, 11:20:37 PM4/13/17
to qubes-users, joonas....@openmailbox.org
read this discussion, kernel verison might not mean much here. https://news.ycombinator.com/item?id=14105718
cooloutac
Apr 13, 2017, 11:26:07 PM4/13/17
to qubes-users, joonas....@openmailbox.org
So probably the kernels are not actually vulnerable, They fixed it a year ago with patches, and with Qubes you assume this sort of priv escl thing regardless which is why they don't even bother with sudo.
cooloutac
Apr 13, 2017, 11:33:21 PM4/13/17
to qubes-users, joonas....@openmailbox.org
On Thursday, April 13, 2017 at 11:26:07 PM UTC-4, cooloutac wrote:
> So probably the kernels are not actually vulnerable, They fixed it a year ago with patches, and with Qubes you assume this sort of priv escl thing regardless which is why they don't even bother with sudo.
> So probably the kernels are not actually vulnerable, They fixed it a year ago with patches, and with Qubes you assume this sort of priv escl thing regardless which is why they don't even bother with sudo.
Actually when it comes to redhat they claim the code was never there to exploit. But redhat might not apply to fedora kernel so I'm kind of curious myself now.
Reg Tiangha
Apr 14, 2017, 12:00:22 AM4/14/17
to qubes...@googlegroups.com
repository for dom0:
current: kernel-4.4.38, kernel-qubes-vm-4.4.38
current-testing: kernel-4.4.55, kernel-qubes-vm-4.4.55
From what I can tell, the Qubes Kernel is built from the stock kernel
source, so if this bug was fixed months ago, you could probably install
either and be fine (assuming you're running R3.2).
If you're really paranoid, you can build the latest 4.4 kernel (as of
now, it's 4.4.61) yourself and install via rpm with very little
modification using the existing Qubes build scripts.
Assuming you have a Fedora 23 VM with git, gcc and make installed (maybe
a few other things; I'm not sure), run:
git clone https://github.com/QubesOS/qubes-linux-kernel.git
- Switch to the 4.4 branch:
git checkout stable-4.4
- Edit the 'version' file and replace 4.4.55 with 4.4.61
- Then compile:
make rpms
And then copy the kernel and kernel-qubes-vm rpms to dom0 and install
them there using rpm or dnf.
I just did it myself with the 4.4 branch and it builds fine. I haven't
installed it though since I run 4.10 (which is a bit more involved since
some of the patches need to be migrated; I've been applying them by hand
using diff -Nuar so I just need to figure out how to create a patch file
*properly* that doesn't require manual intervention, and then I'll
probably throw up my work on GitHub so others can use it for both 4.9
and 4.10; this GitHub stuff and figuring out how to patch things isn't
my forte yet).
Reg Tiangha
Apr 14, 2017, 12:56:56 AM4/14/17
to qubes...@googlegroups.com
qubes-kernel-vm-support. I believe that package will pull in everything
you need to compile a kernel for Qubes. If you're going to attempt to
build a 4.9 kernel or higher, grab version 3.2.4 (install both in your
build vm and dom0) out of current-testing since it hasn't been pushed
into stable yet and 3.2.3 only works with kernels up to 4.8.
Leo Gaspard
Apr 14, 2017, 2:38:44 AM4/14/17
to qubes...@googlegroups.com
On 04/14/2017 06:00 AM, Reg Tiangha wrote:
> On 04/13/2017 09:33 PM, cooloutac wrote:
>> On Thursday, April 13, 2017 at 11:26:07 PM UTC-4, cooloutac wrote:
>>> So probably the kernels are not actually vulnerable, They fixed it a year ago with patches, and with Qubes you assume this sort of priv escl thing regardless which is why they don't even bother with sudo.
>> Actually when it comes to redhat they claim the code was never there to exploit. But redhat might not apply to fedora kernel so I'm kind of curious myself now.
>>
> For those who are concerned, this is what is currently in the Qubes
> repository for dom0:
>
> current: kernel-4.4.38, kernel-qubes-vm-4.4.38
>
> current-testing: kernel-4.4.55, kernel-qubes-vm-4.4.55
>
>
> From what I can tell, the Qubes Kernel is built from the stock kernel
> source, so if this bug was fixed months ago, you could probably install
> either and be fine (assuming you're running R3.2).
> [...]
> On 04/13/2017 09:33 PM, cooloutac wrote:
>> On Thursday, April 13, 2017 at 11:26:07 PM UTC-4, cooloutac wrote:
>>> So probably the kernels are not actually vulnerable, They fixed it a year ago with patches, and with Qubes you assume this sort of priv escl thing regardless which is why they don't even bother with sudo.
>> Actually when it comes to redhat they claim the code was never there to exploit. But redhat might not apply to fedora kernel so I'm kind of curious myself now.
>>
> For those who are concerned, this is what is currently in the Qubes
> repository for dom0:
>
> current: kernel-4.4.38, kernel-qubes-vm-4.4.38
>
> current-testing: kernel-4.4.55, kernel-qubes-vm-4.4.55
>
>
> From what I can tell, the Qubes Kernel is built from the stock kernel
> source, so if this bug was fixed months ago, you could probably install
> either and be fine (assuming you're running R3.2).
According to [1], linux <= 4.4.60 is affected. The patch was but on
4.5-rc1 branch on Dec. 15, but this doesn't mean it got backported to
older kernels as it was not tagged as a security issue before (eg.
debian's DSA mentioned "A regression in the UDP implementation prevented
freeradius and some other applications from receiving data." as the
reason for their backporting the patch, if I read correctly)
Which, unless fedora's (or qubes') kernel has been using a patch for
this despite it not being tagged as a security issue until now, would
mean qubes' current kernels are all vulnerable.
HTH,
Leo
[1] https://nvd.nist.gov/vuln/detail/CVE-2016-10229
Reg Tiangha
Apr 14, 2017, 3:21:45 AM4/14/17
to qubes...@googlegroups.com
On 04/14/2017 12:38 AM, Leo Gaspard wrote:
According to [1], linux <= 4.4.60 is affected. The patch was but on
4.5-rc1 branch on Dec. 15, but this doesn't mean it got backported to
older kernels as it was not tagged as a security issue before (eg.
debian's DSA mentioned "A regression in the UDP implementation prevented
freeradius and some other applications from receiving data." as the
reason for their backporting the patch, if I read correctly)
Which, unless fedora's (or qubes') kernel has been using a patch for
this despite it not being tagged as a security issue until now, would
mean qubes' current kernels are all vulnerable.
HTH,
Leo
----
According to [1], linux <= 4.4.60 is affected. The patch was but on
4.5-rc1 branch on Dec. 15, but this doesn't mean it got backported to
older kernels as it was not tagged as a security issue before (eg.
debian's DSA mentioned "A regression in the UDP implementation prevented
freeradius and some other applications from receiving data." as the
reason for their backporting the patch, if I read correctly)
Which, unless fedora's (or qubes') kernel has been using a patch for
this despite it not being tagged as a security issue until now, would
mean qubes' current kernels are all vulnerable.
HTH,
Leo
Ugh. If that's the case, then people should compile a 4.4.61 kernel for
themselves (that was released on Apr 12 so it's the most recent in that
branch) since Qubes builds its kernel off the vanilla kernel (it's
pretty easy do and like I said before, it should build with no problems,
but make sure you have 4GB of free space in /home before you do since
the compilation needs that much to complete); not sure if/when that'll
appear in the official Qubes repositories so until then, we're all on
our own.
Vít Šesták
Apr 14, 2017, 8:54:03 AM4/14/17
to qubes-users
I am not sure about the details, but IIUC, the attack works this way:
1. The kernel recieves a malformed UDP packet.
2. There is some application that reads the packet in peek mode. (This is reportedly rarely used.)
If one of those conditions is not met, the attack is not triggered.
I hope that VMs like sys-net and sys-firewall will not forward the malformed packet unless they are compromised. If this is true, then exploitation in Qubes would require compromising its NetVM first. In typical scenario, this requires compromising sys-firewall, but the attack surface is rather small. In some other scenario, just compromising a ProxyVM (e.g., TorVM) might be enough.
This is not to say Qubes can never be affected, just my brief research suggests it is not so severe in QubesOS and chained exploitation (probably to TemplateVM) sounds unlikely.
Regards,
Vít Šesták 'v6ak'
1. The kernel recieves a malformed UDP packet.
2. There is some application that reads the packet in peek mode. (This is reportedly rarely used.)
If one of those conditions is not met, the attack is not triggered.
I hope that VMs like sys-net and sys-firewall will not forward the malformed packet unless they are compromised. If this is true, then exploitation in Qubes would require compromising its NetVM first. In typical scenario, this requires compromising sys-firewall, but the attack surface is rather small. In some other scenario, just compromising a ProxyVM (e.g., TorVM) might be enough.
This is not to say Qubes can never be affected, just my brief research suggests it is not so severe in QubesOS and chained exploitation (probably to TemplateVM) sounds unlikely.
Regards,
Vít Šesták 'v6ak'
Unman
Apr 14, 2017, 9:54:37 AM4/14/17
to Reg Tiangha, qubes...@googlegroups.com
On Fri, Apr 14, 2017 at 01:21:33AM -0600, Reg Tiangha wr,te:
I think everyone should calm down. :-)
If you look at the source for 4.4.38 used to build the kernel used in
Qubes, you will see that it already contains the patch.
That's linux-4.4.38 from 10-Dec-2016
Qubes kernel version 4.4.38-11 was built 12-Dec-2016, and incorporates
that patch, so if you keep your system updated you are already covered.
Did the vulnerability exist in the past? Of course.
Have you been affected? That seems unlikely to me, since as Vit points
out, it requires a specific mode which you aren't likely to have been
running, particularly not in sys-net.
If you are worried about compromise - good. That's what Qubes aims to
address. Your use patterns should protect you against compromise of
individual qubes.
Has your Qubes been compromised, in the sense that everything is now
open to a remote attacker? Not, I think, because of this issue.
As always, I'm open to other arguments, but it's a huge step from this
old vulnerability to worrying about my Qubes infrastructure being
compromised, and I haven't seen anything that makes me think that's
likely or even possible.
unman
If you look at the source for 4.4.38 used to build the kernel used in
Qubes, you will see that it already contains the patch.
That's linux-4.4.38 from 10-Dec-2016
Qubes kernel version 4.4.38-11 was built 12-Dec-2016, and incorporates
that patch, so if you keep your system updated you are already covered.
Did the vulnerability exist in the past? Of course.
Have you been affected? That seems unlikely to me, since as Vit points
out, it requires a specific mode which you aren't likely to have been
running, particularly not in sys-net.
If you are worried about compromise - good. That's what Qubes aims to
address. Your use patterns should protect you against compromise of
individual qubes.
Has your Qubes been compromised, in the sense that everything is now
open to a remote attacker? Not, I think, because of this issue.
As always, I'm open to other arguments, but it's a huge step from this
old vulnerability to worrying about my Qubes infrastructure being
compromised, and I haven't seen anything that makes me think that's
likely or even possible.
unman
Andrew David Wong
Apr 16, 2017, 9:18:44 PM4/16/17
to Unman, Reg Tiangha, qubes...@googlegroups.com, Marek Marczykowski-Górecki
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2017-04-14 06:54, Unman wrote:
> I think everyone should calm down. :-)
>
> If you look at the source for 4.4.38 used to build the kernel used
> in Qubes, you will see that it already contains the patch. That's
> linux-4.4.38 from 10-Dec-2016
>
> Qubes kernel version 4.4.38-11 was built 12-Dec-2016, and
> incorporates that patch, so if you keep your system updated you
> are already covered.
>
Marek has also confirmed that 4.4.38 contains the fix.
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJY9BfqAAoJENtN07w5UDAwKfgQAKppdoaL7U1Cggjxl6ZkOMkk
DlG5Rb6BCnjzwSXJ8Iad0Y2rxoVa6JVvlCcEN9Ml44FLCKkN5F+ROxomOUuPHkoT
TaY71yC6SO8T+xwM+SExynfpV3maTDXDFmPaZB/ydVRgIlLDk70vU2L1W9WnPT9d
FOWti4RCM7eFaUMORGnClzKtU3d0ayKL6HiQMiT63CDXMteqR2ZJx1kHPooZ+ZLs
zndcu345S2iM6q0UMJGo74NIkwreFmjswHATF2MiBsdzyxr62sOevtdJSmK1hHGn
K/A+/VsrW0GS7/Nnc5gFy3uZcbv3HaygAJUxxhCG9Ad8fFkwY9CUkcOj8W5RnT4v
eM8m/dqEsP+a7zfUPcbZnZAC57zqn+SIq6I1wN90d76WwEMbKxIJMiSwX1TsQ3NE
HCFZj3060zQuW+rHxS4CUNbJQ5mZxp0cYcjsb6YB8/TASWNUJ2y8vIpCp9s72lk0
eV+n30FJK7yRMiXhUpdX+Kl/IJp+pi3RSIvkYqN1TFM61k9H/IoatBk08Ejcd+Gh
ge+ccIhEDM6VytZ6NswAjjUfrQ6jPk1lNEFRhsBx1BmsWgSdNf8o2kZ8E5jCtYUY
8xZRuPj3+Y3vAMqmtsRurPUVuVS4r153/m9V+APB8h+Zmn1K88G4tRpFDxGI5Flk
RFGRENsnulmB8mC6ipCd
=aOPi
-----END PGP SIGNATURE-----
Hash: SHA512
On 2017-04-14 06:54, Unman wrote:
> I think everyone should calm down. :-)
>
> If you look at the source for 4.4.38 used to build the kernel used
> in Qubes, you will see that it already contains the patch. That's
> linux-4.4.38 from 10-Dec-2016
>
> Qubes kernel version 4.4.38-11 was built 12-Dec-2016, and
> incorporates that patch, so if you keep your system updated you
> are already covered.
>
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJY9BfqAAoJENtN07w5UDAwKfgQAKppdoaL7U1Cggjxl6ZkOMkk
DlG5Rb6BCnjzwSXJ8Iad0Y2rxoVa6JVvlCcEN9Ml44FLCKkN5F+ROxomOUuPHkoT
TaY71yC6SO8T+xwM+SExynfpV3maTDXDFmPaZB/ydVRgIlLDk70vU2L1W9WnPT9d
FOWti4RCM7eFaUMORGnClzKtU3d0ayKL6HiQMiT63CDXMteqR2ZJx1kHPooZ+ZLs
zndcu345S2iM6q0UMJGo74NIkwreFmjswHATF2MiBsdzyxr62sOevtdJSmK1hHGn
K/A+/VsrW0GS7/Nnc5gFy3uZcbv3HaygAJUxxhCG9Ad8fFkwY9CUkcOj8W5RnT4v
eM8m/dqEsP+a7zfUPcbZnZAC57zqn+SIq6I1wN90d76WwEMbKxIJMiSwX1TsQ3NE
HCFZj3060zQuW+rHxS4CUNbJQ5mZxp0cYcjsb6YB8/TASWNUJ2y8vIpCp9s72lk0
eV+n30FJK7yRMiXhUpdX+Kl/IJp+pi3RSIvkYqN1TFM61k9H/IoatBk08Ejcd+Gh
ge+ccIhEDM6VytZ6NswAjjUfrQ6jPk1lNEFRhsBx1BmsWgSdNf8o2kZ8E5jCtYUY
8xZRuPj3+Y3vAMqmtsRurPUVuVS4r153/m9V+APB8h+Zmn1K88G4tRpFDxGI5Flk
RFGRENsnulmB8mC6ipCd
=aOPi
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages