> -----Original Message----- > From: acpi-request@xxxxxxxxxxxxxxxxx [mailto:acpi- > request@xxxxxxxxxxxxxxxxx] On Behalf Of David Renz > Sent: Saturday, August 19, 2017 7:29 PM > To: linux-acpi@xxxxxxxxxxxxxxx > Cc: acpi@xxxxxxxxxxxxxxx; Intel Product Security Incident Response Team > <Intel.Product.Security.Incident.Response.Team@xxxxxxxxx>; > david.renz@xxxxxx > Subject: [acpi] Corrupt ACPI code (HP Pavilion Desktop PC 570-p0xx) > [~170 ACPI-related failures found by FWTS] > > Hello, > > I reported this issue a while ago to some people from redhat.com, who > forwarded my mail to <secure@xxxxxxxxx>, but I didn't receive any reply > for about 2 weeks, and unfortunately I lost my access to this mail > account. Therefore I'm sending/posting this once more using my > university's mail address, since I would be able to recover the access > if I should lose it again. [Please send your mail to this address in > case somebody should have tried to contact me using that old mail > address in the meantime.] > > > This is the report generated by FirmwareTestSuite (FWTS, > https://wiki.ubuntu.com/FirmwareTestSuite/Reference): > https://pastebin.com/TapPuPMg > > > > To provide an example of the numerous ACPI-related error messages found > by FWTS: > > FAILED [LOW] AMLAsmASL_MSG_NOT_REFERENCED: Test 1, Assembler remark in > line 1141 > Line | AML source > ------------------------------------------------------------------------ > -------- > 01138| Store (Buffer (0x18) {}, Local7) > 01139| CreateDWordField (Local7, 0x00, A119) > 01140| CreateDWordField (Local7, 0x04, A120) > 01141| CreateDWordField (Local7, 0x08, A121) > | ^ > | Remark 2089: Object is not referenced (Name [A121] is within > a > method [A037]) > 01142| CreateDWordField (Local7, 0x0C, A122) > 01143| CreateDWordField (Local7, 0x10, A123) > 01144| CreateDWordField (Local7, 0x14, A124) > > > > One of my friends also owns a similar HP Pavilion Desktop PC, and having > performed a test run using FWTS didn't show any ACPI-related > error/failure messages in his case, so I assume that this behavior and > all these errors can definitely not be considered as being normal. > > > > ACPI-related error messages can also be seen in the kernel output when > booting any Linux distro, e. g. in case of openSUSE Leap 42.2 it > reports: > [...] > [ 12.291867] ACPI Error: Field [D128] at 1152 exceeds Buffer [NULL] > size 160 (bits) (20150930/dsopcode-236) > [ 12.291875] ACPI Error: Method parse/execution failed [\HWMC] (Node > ffff880197cb5b30), AE_AML_BUFFER_LIMIT (20150930/psparse-542) > [ 12.291891] ACPI Error: Method parse/execution failed > [\_SB.WMID.WMAA] (Node ffff880197cb7d60), AE_AML_BUFFER_LIMIT > (20150930/psparse-542) > [ 12.291939] ACPI Error: Field [D128] at 1152 exceeds Buffer [NULL] > size 160 (bits) (20150930/dsopcode-236) > [ 12.291943] ACPI Error: Method parse/execution failed [\HWMC] (Node > ffff880197cb5b30), AE_AML_BUFFER_LIMIT (20150930/psparse-542) > [ 12.291947] ACPI Error: Method parse/execution failed > [\_SB.WMID.WMAA] (Node ffff880197cb7d60), AE_AML_BUFFER_LIMIT > (20150930/psparse-542) > [ 12.291988] ACPI Error: Field [D128] at 1152 exceeds Buffer [NULL] > size 160 (bits) (20150930/dsopcode-236) > [ 12.291990] ACPI Error: Method parse/execution failed [\HWMC] (Node > ffff880197cb5b30), AE_AML_BUFFER_LIMIT (20150930/psparse-542) > [ 12.291997] ACPI Error: Method parse/execution failed > [\_SB.WMID.WMAA] (Node ffff880197cb7d60), AE_AML_BUFFER_LIMIT > (20150930/psparse-542) > [ 12.292066] input: HP WMI hotkeys as /devices/virtual/input/input4 > [ 12.292243] ACPI Error: Field [D128] at 1152 exceeds Buffer [NULL] > size 160 (bits) (20150930/dsopcode-236) > [ 12.292247] ACPI Error: Method parse/execution failed [\HWMC] (Node > ffff880197cb5b30), AE_AML_BUFFER_LIMIT (20150930/psparse-542) > [ 12.292262] ACPI Error: Method parse/execution failed > [\_SB.WMID.WMAA] (Node ffff880197cb7d60), AE_AML_BUFFER_LIMIT > (20150930/psparse-542) > [ 12.292308] ACPI Error: Field [D128] at 1152 exceeds Buffer [NULL] > size 160 (bits) (20150930/dsopcode-236) > [ 12.292316] ACPI Error: Method parse/execution failed [\HWMC] (Node > ffff880197cb5b30), AE_AML_BUFFER_LIMIT (20150930/psparse-542) > [ 12.292325] ACPI Error: Method parse/execution failed > [\_SB.WMID.WMAA] (Node ffff880197cb7d60), AE_AML_BUFFER_LIMIT > (20150930/psparse-542) > [...] > > > > By just analyzing the kernel boot output it seems that this ACPI code / > its execution results in a memory remapping and that it has an effect on > the interrupt routing: > [...] > [ 0.438260] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 > [ 0.438355] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem > 0xf8000000-0xfbffffff] (base 0xf8000000) > [ 0.438358] PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in > E820 > [ 0.438363] PCI: Using configuration type 1 for base access > [ 0.462685] ACPI: Added _OSI(Module Device) > [ 0.462689] ACPI: Added _OSI(Processor Device) > [ 0.462691] ACPI: Added _OSI(3.0 _SCP Extensions) > [ 0.462692] ACPI: Added _OSI(Processor Aggregator Device) > [ 0.465615] ACPI: Executed 1 blocks of module-level executable AML > code > [ 0.477070] ACPI: Interpreter enabled > [ 0.477102] ACPI: (supports S0 S3 S4 S5) > [ 0.477104] ACPI: Using IOAPIC for interrupt routing > [ 0.477143] PCI: Using host bridge windows from ACPI; if necessary, > use "pci=nocrs" and report a bug > [ 0.477704] [Firmware Bug]: ACPI: No _BQC method, cannot determine > initial brightness > [ 0.479303] [Firmware Bug]: ACPI: No _BQC method, cannot determine > initial brightness > [...] > [ 0.481669] [Firmware Bug]: ACPI: No _BQC method, cannot determine > initial brightness > [ 0.484553] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) > [ 0.484562] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM > ClockPM Segments MSI] > [ 0.484816] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME > AER PCIeCapability] > [ 0.484830] acpi PNP0A08:00: [Firmware Info]: MMCONFIG for domain > 0000 [bus 00-3f] only partially covers this bridge > [...] > > > Finally it seems that this memory remapping makes it possible to inject > hidden kernel modules (which I was able to detect using the Volatility > Framework previously, apart from kernel hooks): > > [ 11.536189] resource sanity check: requesting [mem > 0xddf78000-0xddf7bfff], which spans more than MSFT0101:00 [mem > 0xddf78000-0xddf78fff] > [ 11.536192] ------------[ cut here ]------------ > [ 11.536198] WARNING: CPU: 3 PID: 587 at ../arch/x86/mm/ioremap.c:198 > __ioremap_caller+0x293/0x350() > [ 11.536199] Info: mapping multiple BARs. Your kernel is fine. > [ 11.536199] Modules linked in: tpm_crb(+) ablk_helper cryptd fjes > 8250_dw processor soundcore gpio_amdpt button video thermal > i2c_designware_platform i2c_designware_core xfs libcrc32c sd_mod uas > usb_storage crc32c_intel amdkfd amd_iommu_v2 ehci_pci ehci_hcd xhci_pci > nvme nvme_core amdgpu ahci libahci i2c_algo_bit xhci_hcd drm_kms_helper > libata syscopyarea sysfillrect sysimgblt fb_sys_fops ttm usbcore > usb_common drm sg scsi_mod efivarfs autofs4 > [ 11.536273] CPU: 3 PID: 587 Comm: systemd-udevd Tainted: G W > 4.4.79-18.26-default #1 > [ 11.536275] Hardware name: HP HP Pavilion Desktop PC 570-p0xx/82FE, > BIOS F.12 05/19/2017 > [ 11.536277] 0000000000000000 ffffffff8132a157 ffff8801f5bd3ad0 > ffffffff81a50b3a > [ 11.536286] ffffffff8107ef11 > [ 11.536287] ffffc90000cb8000 ffff8801f5bd3b20 ffffc90000cb8000 > [ 11.536294] 0000000000004000 > [ 11.536296] ffff8800daa41600 ffffffff8107ef8c ffffffff81a48a78 > [ 11.536302] Call Trace: > [ 11.536315] [<ffffffff81019ea9>] dump_trace+0x59/0x320 > [ 11.536321] [<ffffffff8101a26a>] show_stack_log_lvl+0xfa/0x180 > [ 11.536324] [<ffffffff8101b011>] show_stack+0x21/0x40 > [ 11.536330] [<ffffffff8132a157>] dump_stack+0x5c/0x85 > [ 11.536334] [<ffffffff8107ef11>] warn_slowpath_common+0x81/0xb0 > [ 11.536337] [<ffffffff8107ef8c>] warn_slowpath_fmt+0x4c/0x50 > [ 11.536341] [<ffffffff81066f93>] __ioremap_caller+0x293/0x350 > [ 11.536347] [<ffffffff8134316d>] devm_ioremap_nocache+0x3d/0x80 > [ 11.536351] [<ffffffffa026d3ac>] crb_acpi_add+0x13c/0x290 [tpm_crb] > [ 11.536366] [<ffffffff813afada>] acpi_device_probe+0x4a/0x1c0 > [ 11.536373] [<ffffffff81471ca7>] driver_probe_device+0x1f7/0x420 > [ 11.536377] [<ffffffff81471f4b>] __driver_attach+0x7b/0x80 > [ 11.536382] [<ffffffff8146fb98>] bus_for_each_dev+0x58/0x90 > [ 11.536386] [<ffffffff814710e9>] bus_add_driver+0x1c9/0x280 > [ 11.536389] [<ffffffff8147290b>] driver_register+0x5b/0xd0 > [ 11.536394] [<ffffffff81002138>] do_one_initcall+0xc8/0x1f0 > [ 11.536399] [<ffffffff8118b9bc>] do_init_module+0x5a/0x1d7 > [ 11.536408] [<ffffffff8110af87>] load_module+0x1e97/0x2800 > [ 11.536411] [<ffffffff8110bac0>] SYSC_finit_module+0x70/0xa0 > [ 11.536419] [<ffffffff81610772>] entry_SYSCALL_64_fastpath+0x16/0x71 > [ 11.537802] DWARF2 unwinder stuck at > entry_SYSCALL_64_fastpath+0x16/0x71 > > [ 11.537803] Leftover inexact backtrace: > > [ 11.537806] ---[ end trace 31411d409269e2e9 ]--- > > > Full dmesg output on pastebin.com: > https://pastebin.com/164qUxnW > > > > This is not directly ACPI-related, but since it makes the impression > that the ACPI code's execution leads to the system getting compromised, > I hope it's alright if I quote only a few findings which were reported > when performing a Lynis system audit: > > - Comparing sysctl key pairs with scan profile > - kernel.core_uses_pid (exp: 1) [ > DIFFERENT ] > - kernel.ctrl-alt-del (exp: 0) [ OK ] > - kernel.kptr_restrict (exp: 2) [ > DIFFERENT ] > - kernel.randomize_va_space (exp: 2) [ OK ] > - kernel.sysrq (exp: 0) [ > DIFFERENT ] > - net.ipv4.conf.all.accept_redirects (exp: 0) [ > DIFFERENT ] > - net.ipv4.conf.all.accept_source_route (exp: 0) [ OK ] > - net.ipv4.conf.all.bootp_relay (exp: 0) [ OK ] > - net.ipv4.conf.all.forwarding (exp: 0) [ OK ] > - net.ipv4.conf.all.log_martians (exp: 1) [ > DIFFERENT ] > - net.ipv4.conf.all.mc_forwarding (exp: 0) [ OK ] > - net.ipv4.conf.all.proxy_arp (exp: 0) [ OK ] > - net.ipv4.conf.all.rp_filter (exp: 1) [ > DIFFERENT ] > - net.ipv4.conf.all.send_redirects (exp: 0) [ > DIFFERENT ] > - net.ipv4.conf.default.accept_redirects (exp: 0) [ > DIFFERENT ] > - net.ipv4.conf.default.accept_source_route (exp: 0) [ > DIFFERENT ] > - net.ipv4.conf.default.log_martians (exp: 1) [ > DIFFERENT ] > - net.ipv4.icmp_echo_ignore_broadcasts (exp: 1) [ OK ] > - net.ipv4.icmp_ignore_bogus_error_responses (exp: 1) [ OK ] > - net.ipv4.tcp_syncookies (exp: 1) [ OK ] > - net.ipv4.tcp_timestamps (exp: 0) [ > DIFFERENT ] > - net.ipv6.conf.all.accept_redirects (exp: 0) [ > DIFFERENT ] > - net.ipv6.conf.all.accept_source_route (exp: 0) [ OK ] > - net.ipv6.conf.default.accept_redirects (exp: 0) [ > DIFFERENT ] > - net.ipv6.conf.default.accept_source_route (exp: 0) [ OK ] > > > Also "chkrootkit" classified three network related binaries as "packet > sniffers": > wlan0: PACKET SNIFFER(/sbin/wpa_supplicant[798], > /sbin/wpa_supplicant[798], /sbin/dhclient[21562] > > Having disassembled these files it wasn't difficult for me to understand > why they were classified this way, e. g. by looking at the strings > contained in the disassembled "wpa_supplicant" file: > vaddr=0x00164118 paddr=0x00164118 ordinal=906 sz=85 len=84 > section=.rodata type=ascii string=TDLS: Channel switching is prohibited > in this BSS - reject request to switch channel > [...] > vaddr=0x00166ce0 paddr=0x00166ce0 ordinal=1154 sz=100 len=99 > section=.rodata type=ascii string=RSN: Replace PMKSA entry for the > current AP and any PMKSA cache entry that was based on the old PMK > [...] > > By the way, a Google search returned only three hits when searching for > each of these strings, and the source code which these hits refer to > doesn't look very trustworthy actually, e. g.: > https://gitlab.gwdg.de/eap- > saml/hostapd/blob/hostap_2_5/src/rsn_supp/tdls.c > https://w1.fi/cgit/hostap/plain/src/rsn_supp/pmksa_cache.c > > > [Sorry if this should be considered as being off-topic, but since it can > probably be assumed that this ACPI code on my computer is compromised, I > think it's very reasonable to assume that the system gets compromised by > its execution and not for any other reason - I didn't download or > install anything before having made these observations, so mentioning > this could not really be regarded as being 'off-topic' in this context.] > > > The full disassembly of "wpa_supplicant" and "dhclient", plus the > extracted and disassembled ACPI code from my system can be downloaded > from the GoogleDrive folder I gave shared access to: > https://drive.google.com/open?id=0B62Y5Qk_rdbWdzBsWmt1eEl3YlU > > > > If anyone would like to send me a reply, please send your mail also to > my other address <sheer.itsec@xxxxxxxxxxxxxx> to ensure that it will > reach me. I would really appreciate it, if this issue would receive some > attention and gets investigated / further analyzed by people being able > to do so, since having one's computer infected by a highly-sophisticated > firmware-based rootkit while not knowing anything about the reason / > background of this is not very pleasant. > > [Moore, Robert] Please send or post the acpidump for this machine; I didn't see it above. > > Kind regards and thanks in advance > > David Renz -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
