* lockdown bypass on mainline kernel for loading unsigned modules @ 2020-06-15 10:26 Jason A. Donenfeld 2020-06-15 10:43 ` [PATCH] acpi: disallow loading configfs acpi tables when locked down Jason A. Donenfeld 2020-06-15 16:22 ` [oss-security] lockdown bypass on mainline kernel for loading unsigned modules John Haxby 0 siblings, 2 replies; 10+ messages in thread From: Jason A. Donenfeld @ 2020-06-15 10:26 UTC (permalink / raw) To: oss-security Cc: linux-security-module, linux-acpi, Matthew Garrett, kernel-hardening, Ubuntu Kernel Team Hi everyone, Yesterday, I found a lockdown bypass in Ubuntu 18.04's kernel using ACPI table tricks via the efi ssdt variable [1]. Today I found another one that's a bit easier to exploit and appears to be unpatched on mainline, using acpi_configfs to inject an ACPI table. The tricks are basically the same as the first one, but this one appears to be unpatched, at least on my test machine. Explanation is in the header of the PoC: https://git.zx2c4.com/american-unsigned-language/tree/american-unsigned-language-2.sh I need to get some sleep, but if nobody posts a patch in the meanwhile, I'll try to post a fix tomorrow. Jason [1] https://www.openwall.com/lists/oss-security/2020/06/14/1 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH] acpi: disallow loading configfs acpi tables when locked down 2020-06-15 10:26 lockdown bypass on mainline kernel for loading unsigned modules Jason A. Donenfeld @ 2020-06-15 10:43 ` Jason A. Donenfeld 2020-06-16 22:20 ` Jason A. Donenfeld 2020-06-15 16:22 ` [oss-security] lockdown bypass on mainline kernel for loading unsigned modules John Haxby 1 sibling, 1 reply; 10+ messages in thread From: Jason A. Donenfeld @ 2020-06-15 10:43 UTC (permalink / raw) To: linux-kernel, linux-acpi, mjg59, kernel-hardening Cc: Jason A. Donenfeld, stable Like other vectors already patched, this one here allows the root user to load ACPI tables, which enables arbitrary physical address writes, which in turn makes it possible to disable lockdown. This patch prevents this by checking the lockdown status before allowing a new ACPI table to be installed. The link in the trailer shows a PoC of how this might be used. Link: https://git.zx2c4.com/american-unsigned-language/tree/american-unsigned-language-2.sh Cc: stable@vger.kernel.org Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> --- drivers/acpi/acpi_configfs.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/acpi_configfs.c b/drivers/acpi/acpi_configfs.c index ece8c1a921cc..88c8af455ea3 100644 --- a/drivers/acpi/acpi_configfs.c +++ b/drivers/acpi/acpi_configfs.c @@ -11,6 +11,7 @@ #include <linux/module.h> #include <linux/configfs.h> #include <linux/acpi.h> +#include <linux/security.h> #include "acpica/accommon.h" #include "acpica/actables.h" @@ -28,7 +29,10 @@ static ssize_t acpi_table_aml_write(struct config_item *cfg, { const struct acpi_table_header *header = data; struct acpi_table *table; - int ret; + int ret = security_locked_down(LOCKDOWN_ACPI_TABLES); + + if (ret) + return ret; table = container_of(cfg, struct acpi_table, cfg); -- 2.27.0 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] acpi: disallow loading configfs acpi tables when locked down 2020-06-15 10:43 ` [PATCH] acpi: disallow loading configfs acpi tables when locked down Jason A. Donenfeld @ 2020-06-16 22:20 ` Jason A. Donenfeld 2020-06-17 8:37 ` Ard Biesheuvel 2020-06-22 14:45 ` Rafael J. Wysocki 0 siblings, 2 replies; 10+ messages in thread From: Jason A. Donenfeld @ 2020-06-16 22:20 UTC (permalink / raw) To: Len Brown, rjw; +Cc: LKML, linux-acpi, Kernel Hardening Hi Rafael, Len, Looks like I should have CC'd you on this patch. This is probably something we should get into 5.8-rc2, so that it can then get put into stable kernels, as some people think this is security sensitive. Bigger picture is this: https://data.zx2c4.com/american-unsigned-language-2.gif https://data.zx2c4.com/american-unsigned-language-2-fedora-5.8.png Also, somebody mentioned to me that Microsoft's ACPI implementation disallows writes to system memory as a security mitigation. I haven't looked at what that actually entails, but I wonder if entirely disabling support for ACPI_ADR_SPACE_SYSTEM_MEMORY would be sensible. I haven't looked at too many DSDTs. Would that break real hardware, or does nobody do that? Alternatively, the range of acceptable addresses for SystemMemory could exclude kernel memory. Would that break anything? Have you heard about Microsoft's mitigation to know more details on what they figured out they could safely restrict without breaking hardware? Either way, food for thought I suppose. Jason ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] acpi: disallow loading configfs acpi tables when locked down 2020-06-16 22:20 ` Jason A. Donenfeld @ 2020-06-17 8:37 ` Ard Biesheuvel 2020-06-17 8:42 ` Jason A. Donenfeld 2020-06-17 16:52 ` Kaneda, Erik 2020-06-22 14:45 ` Rafael J. Wysocki 1 sibling, 2 replies; 10+ messages in thread From: Ard Biesheuvel @ 2020-06-17 8:37 UTC (permalink / raw) To: Jason A. Donenfeld Cc: Len Brown, Rafael J. Wysocki, LKML, ACPI Devel Maling List, Kernel Hardening On Wed, 17 Jun 2020 at 00:21, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > Hi Rafael, Len, > > Looks like I should have CC'd you on this patch. This is probably > something we should get into 5.8-rc2, so that it can then get put into > stable kernels, as some people think this is security sensitive. > Bigger picture is this: > > https://data.zx2c4.com/american-unsigned-language-2.gif > https://data.zx2c4.com/american-unsigned-language-2-fedora-5.8.png > > Also, somebody mentioned to me that Microsoft's ACPI implementation > disallows writes to system memory as a security mitigation. I haven't > looked at what that actually entails, but I wonder if entirely > disabling support for ACPI_ADR_SPACE_SYSTEM_MEMORY would be sensible. > I haven't looked at too many DSDTs. Would that break real hardware, or > does nobody do that? Alternatively, the range of acceptable addresses > for SystemMemory could exclude kernel memory. Would that break > anything? Have you heard about Microsoft's mitigation to know more > details on what they figured out they could safely restrict without > breaking hardware? Either way, food for thought I suppose. > ACPI_ADR_SPACE_SYSTEM_MEMORY may be used for everything that is memory mapped, i.e., PCIe ECAM space, GPIO control registers etc. I agree that using ACPI_ADR_SPACE_SYSTEM_MEMORY for any memory that is under the kernel's control is a bad idea, and this should be easy to filter out: the SystemMemory address space handler needs the ACPI support routines to map the physical addresses used by AML into virtual kernel addresses, so all these accesses go through acpi_os_ioremap(). So as a first step, it should be reasonable to put a lockdown check there, and fail any access to OS owned memory if lockdown is enabled, and print a warning if it is not. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] acpi: disallow loading configfs acpi tables when locked down 2020-06-17 8:37 ` Ard Biesheuvel @ 2020-06-17 8:42 ` Jason A. Donenfeld 2020-06-17 16:52 ` Kaneda, Erik 1 sibling, 0 replies; 10+ messages in thread From: Jason A. Donenfeld @ 2020-06-17 8:42 UTC (permalink / raw) To: Ard Biesheuvel Cc: Len Brown, Rafael J. Wysocki, LKML, ACPI Devel Maling List, Kernel Hardening On Wed, Jun 17, 2020 at 2:38 AM Ard Biesheuvel <ardb@kernel.org> wrote: > > On Wed, 17 Jun 2020 at 00:21, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > > > Hi Rafael, Len, > > > > Looks like I should have CC'd you on this patch. This is probably > > something we should get into 5.8-rc2, so that it can then get put into > > stable kernels, as some people think this is security sensitive. > > Bigger picture is this: > > > > https://data.zx2c4.com/american-unsigned-language-2.gif > > https://data.zx2c4.com/american-unsigned-language-2-fedora-5.8.png > > > > Also, somebody mentioned to me that Microsoft's ACPI implementation > > disallows writes to system memory as a security mitigation. I haven't > > looked at what that actually entails, but I wonder if entirely > > disabling support for ACPI_ADR_SPACE_SYSTEM_MEMORY would be sensible. > > I haven't looked at too many DSDTs. Would that break real hardware, or > > does nobody do that? Alternatively, the range of acceptable addresses > > for SystemMemory could exclude kernel memory. Would that break > > anything? Have you heard about Microsoft's mitigation to know more > > details on what they figured out they could safely restrict without > > breaking hardware? Either way, food for thought I suppose. > > > > ACPI_ADR_SPACE_SYSTEM_MEMORY may be used for everything that is memory > mapped, i.e., PCIe ECAM space, GPIO control registers etc. > > I agree that using ACPI_ADR_SPACE_SYSTEM_MEMORY for any memory that is > under the kernel's control is a bad idea, and this should be easy to > filter out: the SystemMemory address space handler needs the ACPI > support routines to map the physical addresses used by AML into > virtual kernel addresses, so all these accesses go through > acpi_os_ioremap(). So as a first step, it should be reasonable to put > a lockdown check there, and fail any access to OS owned memory if > lockdown is enabled, and print a warning if it is not. Makes sense. Though I was thinking of doing this unconditionally, not just for lockdown, as a "realer" security mitigation (hence CCing kernel-hardening), against bugs that manage to mess with acpi things. A second mitigation might be marking inmemory acpi bytecode pages as read only. ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [PATCH] acpi: disallow loading configfs acpi tables when locked down 2020-06-17 8:37 ` Ard Biesheuvel 2020-06-17 8:42 ` Jason A. Donenfeld @ 2020-06-17 16:52 ` Kaneda, Erik 1 sibling, 0 replies; 10+ messages in thread From: Kaneda, Erik @ 2020-06-17 16:52 UTC (permalink / raw) To: Ard Biesheuvel, Jason A. Donenfeld Cc: Len Brown, Rafael J. Wysocki, LKML, ACPI Devel Maling List, Kernel Hardening > -----Original Message----- > From: linux-acpi-owner@vger.kernel.org <linux-acpi- > owner@vger.kernel.org> On Behalf Of Ard Biesheuvel > Sent: Wednesday, June 17, 2020 1:38 AM > To: Jason A. Donenfeld <Jason@zx2c4.com> > Cc: Len Brown <lenb@kernel.org>; Rafael J. Wysocki <rjw@rjwysocki.net>; > LKML <linux-kernel@vger.kernel.org>; ACPI Devel Maling List <linux- > acpi@vger.kernel.org>; Kernel Hardening <kernel- > hardening@lists.openwall.com> > Subject: Re: [PATCH] acpi: disallow loading configfs acpi tables when locked > down > > On Wed, 17 Jun 2020 at 00:21, Jason A. Donenfeld <Jason@zx2c4.com> > wrote: > > > > Hi Rafael, Len, > > > > Looks like I should have CC'd you on this patch. This is probably > > something we should get into 5.8-rc2, so that it can then get put into > > stable kernels, as some people think this is security sensitive. > > Bigger picture is this: > > > > https://data.zx2c4.com/american-unsigned-language-2.gif > > https://data.zx2c4.com/american-unsigned-language-2-fedora-5.8.png > > Hi, > > Also, somebody mentioned to me that Microsoft's ACPI implementation > > disallows writes to system memory as a security mitigation. I haven't > > looked at what that actually entails, but I wonder if entirely > > disabling support for ACPI_ADR_SPACE_SYSTEM_MEMORY would be > sensible. No, Windows uses these as well. They might have some restriction on which areas are allowed though. With that said, there are plenty of use cases (SMI handlers, power management, etc) where this is needed. Disabling SystemMemory would definitely break existing systems. Erik > > I haven't looked at too many DSDTs. Would that break real hardware, or > > does nobody do that? Alternatively, the range of acceptable addresses > > for SystemMemory could exclude kernel memory. Would that break > > anything? Have you heard about Microsoft's mitigation to know more > > details on what they figured out they could safely restrict without > > breaking hardware? Either way, food for thought I suppose. > > > > ACPI_ADR_SPACE_SYSTEM_MEMORY may be used for everything that is > memory > mapped, i.e., PCIe ECAM space, GPIO control registers etc. > > I agree that using ACPI_ADR_SPACE_SYSTEM_MEMORY for any memory that > is > under the kernel's control is a bad idea, and this should be easy to > filter out: the SystemMemory address space handler needs the ACPI > support routines to map the physical addresses used by AML into > virtual kernel addresses, so all these accesses go through > acpi_os_ioremap(). So as a first step, it should be reasonable to put > a lockdown check there, and fail any access to OS owned memory if > lockdown is enabled, and print a warning if it is not. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] acpi: disallow loading configfs acpi tables when locked down 2020-06-16 22:20 ` Jason A. Donenfeld 2020-06-17 8:37 ` Ard Biesheuvel @ 2020-06-22 14:45 ` Rafael J. Wysocki 1 sibling, 0 replies; 10+ messages in thread From: Rafael J. Wysocki @ 2020-06-22 14:45 UTC (permalink / raw) To: Jason A. Donenfeld Cc: Len Brown, Rafael J. Wysocki, LKML, ACPI Devel Maling List, Kernel Hardening Hi, On Wed, Jun 17, 2020 at 12:20 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > Hi Rafael, Len, > > Looks like I should have CC'd you on this patch. This is probably > something we should get into 5.8-rc2, so that it can then get put into > stable kernels, as some people think this is security sensitive. > Bigger picture is this: > > https://data.zx2c4.com/american-unsigned-language-2.gif > https://data.zx2c4.com/american-unsigned-language-2-fedora-5.8.png I was offline during the last week, sorry. Applied as 5.8-rc material with some subject/changelog edits, thanks! ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [oss-security] lockdown bypass on mainline kernel for loading unsigned modules 2020-06-15 10:26 lockdown bypass on mainline kernel for loading unsigned modules Jason A. Donenfeld 2020-06-15 10:43 ` [PATCH] acpi: disallow loading configfs acpi tables when locked down Jason A. Donenfeld @ 2020-06-15 16:22 ` John Haxby 2020-06-15 17:02 ` Jann Horn 1 sibling, 1 reply; 10+ messages in thread From: John Haxby @ 2020-06-15 16:22 UTC (permalink / raw) To: oss-security, Jason A. Donenfeld Cc: linux-security-module, linux-acpi, Matthew Garrett, kernel-hardening, Ubuntu Kernel Team [-- Attachment #1: Type: text/plain, Size: 918 bytes --] Hi Jason, > On 15 Jun 2020, at 11:26, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > Hi everyone, > > Yesterday, I found a lockdown bypass in Ubuntu 18.04's kernel using > ACPI table tricks via the efi ssdt variable [1]. Today I found another > one that's a bit easier to exploit and appears to be unpatched on > mainline, using acpi_configfs to inject an ACPI table. The tricks are > basically the same as the first one, but this one appears to be > unpatched, at least on my test machine. Explanation is in the header > of the PoC: > > https://git.zx2c4.com/american-unsigned-language/tree/american-unsigned-language-2.sh > > I need to get some sleep, but if nobody posts a patch in the > meanwhile, I'll try to post a fix tomorrow. > > Jason > > [1] https://www.openwall.com/lists/oss-security/2020/06/14/1 This looks CVE-worthy. Are you going to ask for a CVE for it? jch [-- Attachment #2: Message signed with OpenPGP --] [-- Type: application/pgp-signature, Size: 268 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [oss-security] lockdown bypass on mainline kernel for loading unsigned modules 2020-06-15 16:22 ` [oss-security] lockdown bypass on mainline kernel for loading unsigned modules John Haxby @ 2020-06-15 17:02 ` Jann Horn 2020-06-15 17:28 ` Jason A. Donenfeld 0 siblings, 1 reply; 10+ messages in thread From: Jann Horn @ 2020-06-15 17:02 UTC (permalink / raw) To: John Haxby Cc: oss-security, Jason A. Donenfeld, linux-security-module, linux-acpi, Matthew Garrett, Kernel Hardening, Ubuntu Kernel Team On Mon, Jun 15, 2020 at 6:24 PM John Haxby <john.haxby@oracle.com> wrote: > > On 15 Jun 2020, at 11:26, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > Yesterday, I found a lockdown bypass in Ubuntu 18.04's kernel using > > ACPI table tricks via the efi ssdt variable [1]. Today I found another > > one that's a bit easier to exploit and appears to be unpatched on > > mainline, using acpi_configfs to inject an ACPI table. The tricks are > > basically the same as the first one, but this one appears to be > > unpatched, at least on my test machine. Explanation is in the header > > of the PoC: > > > > https://git.zx2c4.com/american-unsigned-language/tree/american-unsigned-language-2.sh > > > > I need to get some sleep, but if nobody posts a patch in the > > meanwhile, I'll try to post a fix tomorrow. > > > > Jason > > > > [1] https://www.openwall.com/lists/oss-security/2020/06/14/1 > > > This looks CVE-worthy. Are you going to ask for a CVE for it? Does it really make sense to dole out CVEs for individual lockdown bypasses when various areas of the kernel (such as filesystems and BPF) don't see root->kernel privilege escalation issues as a problem? It's not like applying the fix for this one issue is going to make systems meaningfully safer. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [oss-security] lockdown bypass on mainline kernel for loading unsigned modules 2020-06-15 17:02 ` Jann Horn @ 2020-06-15 17:28 ` Jason A. Donenfeld 0 siblings, 0 replies; 10+ messages in thread From: Jason A. Donenfeld @ 2020-06-15 17:28 UTC (permalink / raw) To: Jann Horn Cc: John Haxby, oss-security, linux-security-module, linux-acpi, Matthew Garrett, Kernel Hardening, Ubuntu Kernel Team On 6/15/20, Jann Horn <jannh@google.com> wrote: > On Mon, Jun 15, 2020 at 6:24 PM John Haxby <john.haxby@oracle.com> wrote: >> > On 15 Jun 2020, at 11:26, Jason A. Donenfeld <Jason@zx2c4.com> wrote: >> > Yesterday, I found a lockdown bypass in Ubuntu 18.04's kernel using >> > ACPI table tricks via the efi ssdt variable [1]. Today I found another >> > one that's a bit easier to exploit and appears to be unpatched on >> > mainline, using acpi_configfs to inject an ACPI table. The tricks are >> > basically the same as the first one, but this one appears to be >> > unpatched, at least on my test machine. Explanation is in the header >> > of the PoC: >> > >> > https://git.zx2c4.com/american-unsigned-language/tree/american-unsigned-language-2.sh >> > >> > I need to get some sleep, but if nobody posts a patch in the >> > meanwhile, I'll try to post a fix tomorrow. >> > >> > Jason >> > >> > [1] https://www.openwall.com/lists/oss-security/2020/06/14/1 >> >> >> This looks CVE-worthy. Are you going to ask for a CVE for it? > > Does it really make sense to dole out CVEs for individual lockdown > bypasses when various areas of the kernel (such as filesystems and > BPF) don't see root->kernel privilege escalation issues as a problem? > It's not like applying the fix for this one issue is going to make > systems meaningfully safer. > Indeed, I'm more or less of the same mind: lockdown is kind of a best-effort thing at the moment, and it'd be crazy to rely on it, considering various bypasses and differing attitudes on the security model from different subsystems. This acpi bypass is a bug, maybe, but it doesn't feel like a "real" security bug, because I'm not sure why this would be a feature somebody would want to lean on at this point in time. I wrote a PoC for this one rather than others because it seemed fun and technically interesting to poke around with acpi in this way, not because it's particularly rare or something. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-06-22 14:45 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-06-15 10:26 lockdown bypass on mainline kernel for loading unsigned modules Jason A. Donenfeld 2020-06-15 10:43 ` [PATCH] acpi: disallow loading configfs acpi tables when locked down Jason A. Donenfeld 2020-06-16 22:20 ` Jason A. Donenfeld 2020-06-17 8:37 ` Ard Biesheuvel 2020-06-17 8:42 ` Jason A. Donenfeld 2020-06-17 16:52 ` Kaneda, Erik 2020-06-22 14:45 ` Rafael J. Wysocki 2020-06-15 16:22 ` [oss-security] lockdown bypass on mainline kernel for loading unsigned modules John Haxby 2020-06-15 17:02 ` Jann Horn 2020-06-15 17:28 ` Jason A. Donenfeld
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).