linux-kernel - Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHjaAcT7OoTDEweCBwL=BuC-RL6DjKo0AMGS-8HearCdy4_7QQ@mail.gmail.com>
Date:   Fri, 24 Feb 2017 21:56:21 +0900
From:   Seunghun Han <kkamagui@...il.com>
To:     "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:     "Zheng, Lv" <lv.zheng@...el.com>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "devel@...ica.org" <devel@...ica.org>,
        Robert Moore <robert.moore@...el.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

Hi, Rafeal.

I added my opinion below.

2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki <rjw@...ysocki.net>:
> On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
>> Hi, Rafael.
>>
>> I added my opinion below.
>>
>> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki <rjw@...ysocki.net>:
>> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>> >> Hi, Lv Zheng.
>> >>
>> >> I added my handcrafted ACPI table under your request, because
>> >> "acpidump -c on" and "acpidump -c off" doesn't work.
>> >>
>> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han <kkamagui@...il.com>:
>> >> > Hello,
>> >> >
>> >> > I attached the test results below,
>> >> >
>> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <rjw@...ysocki.net>:
>> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>> >> >>> Hi,
>> >> >>>
>> >> >>> > From: linux-acpi-owner@...r.kernel.org [mailto:linux-acpi-owner@...r.kernel.org] On Behalf Of Seunghun
>> >> >>> > Han
>> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>> >> >>> >
>> >> >>> > I'm Seunghun Han, and I work for National Security Research Institute of
>> >> >>> > South Korea.
>> >> >>> >
>> >> >>> > I have been doing a research on ACPI and making a handcrafted ACPI table
>> >> >>> > for my research.
>> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel while boot
>> >> >>> > process, and Linux kernel goes well without critical problems.
>> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort cases.
>> >> >>> >
>> >> >>> > Boot log of ACPI operand cache leak is as follows:
>> >> >>> > >[    0.174332] ACPI: Added _OSI(Module Device)
>> >> >>> > >[    0.175504] ACPI: Added _OSI(Processor Device)
>> >> >>> > >[    0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>> >> >>> > >[    0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>> >> >>> > >[    0.178284] ACPI: SCI (IRQ16705) allocation failed
>> >> >>> > >[    0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install System Control Interrupt handler
>> >> >>> > (20160930/evevent-131)
>> >> >>> > >[    0.180008] ACPI: Unable to start the ACPI Interpreter
>> >> >>> > >[    0.181125] ACPI Error: Could not remove SCI handler (20160930/evmisc-281)
>> >> >>> > >[    0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
>> >> >>> > >[    0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2
>> >> >>> > >[    0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
>> >> >>> > >[    0.188000] Call Trace:
>> >> >>> > >[    0.188000]  ? dump_stack+0x5c/0x7d
>> >> >>> > >[    0.188000]  ? kmem_cache_destroy+0x224/0x230
>> >> >>> > >[    0.188000]  ? acpi_sleep_proc_init+0x22/0x22
>> >> >>> > >[    0.188000]  ? acpi_os_delete_cache+0xa/0xd
>> >> >>> > >[    0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
>> >> >>> > >[    0.188000]  ? acpi_terminate+0x5/0xf
>> >> >>> > >[    0.188000]  ? acpi_init+0x288/0x32e
>> >> >>> > >[    0.188000]  ? __class_create+0x4c/0x80
>> >> >>> > >[    0.188000]  ? video_setup+0x7a/0x7a
>> >> >>> > >[    0.188000]  ? do_one_initcall+0x4e/0x1b0
>> >> >>> > >[    0.188000]  ? kernel_init_freeable+0x194/0x21a
>> >> >>> > >[    0.188000]  ? rest_init+0x80/0x80
>> >> >>> > >[    0.188000]  ? kernel_init+0xa/0x100
>> >> >>> > >[    0.188000]  ? ret_from_fork+0x25/0x30
>> >> >>>
>> >> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
>> >> >>> So could you send us the handcrafted ACPI table or both the "acpidump -c on" and "acpidump -c off" output?
>> >>
>> >> I modified FACP, FACS, APIC table in VirtualBox for Linux.
>> >> Here are raw dumps of table.
>> >
>> > So, excuse me, but what's the security issue here?
>> >
>> > You hacked your ACPI tables into pieces which requires root privileges anyway.
>> >
>> > Thanks,
>> > Rafael
>> >
>>
>> As you mentioned earlier, I hacked my ACPI table for research, so it seems that
>> it is not a security issue.
>>
>> But, if new mainboard are released and they have a vendor-specific ACPI table
>> which has invalid data, the old version of kernel (<=4.9) will possibly expose
>> kernel address and KASLR will be neutralized unintentionally.
>
> But that would mean a basically non-functional system, so I'm not sure how
> anyone can actually take advantage of the "KASLR neutralization".

I think an attacker can take advantage of the "KASLR neutralization". As you
know, KASLR is good technology to protect kernel from kernel exploits.

If the kernel has vulnerabilities, the attacker can make exploit using them.
But, the exploit usually needs gadgets (small code), therefore the attacker
should know where the gadgets are in kernel. If the KASLR is working in kernel,
the attacker should find the actual kernel address, and he can get kernel
address information from kernel warning.

>
>> I know the vendors collaborate with Linux kernel developers, but the problem
>> can still occur.
>>
>> Hardware vendors release so many kinds of mainboard in a year, and the major
>> Linux distros (Ubuntu, Fedora, etc.) will have 4.8 kernel for a long time.
>>
>> For this reason, I think this issue has a security aspect.
>
> Well, not quite IMO.
>
> If the system needs ACPI tables and the kernel cannot use them, it just won't
> work no matter what.
>
> Thanks,
> Rafael
>
Yes, you are right. But, Linux kernel has well-defined exception handlers, so
some systems may work fine like my test machine. Moreover the users may not
recognize what the problem is, and I think that they will use the system in
insecure status for a long time.

Thank you.
Best regards.