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.
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
