I made my VM think it has a CPU fan
wbenny.github.io642 points by todsacerdoti a day ago
642 points by todsacerdoti a day ago
Huh so new antimalware tactic: Buy passively cooled PC :)
And also set up a Russian keyboard: https://krebsonsecurity.com/2021/05/try-this-one-weird-trick...
Writing this from a passively cooled (Streacom FC8 Evo) Linux PC with a Russian keyboard.
# dmidecode 3.6
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x002C, DMI type 27, 15 bytes
Cooling Device
Temperature Probe Handle: 0x0029
Type: <OUT OF SPEC>
Status: <OUT OF SPEC>
Cooling Unit Group: 1
OEM-specific Information: 0x00000000
Nominal Speed: Unknown Or Non-rotating
Description: Cooling Dev 1
Handle 0x002F, DMI type 27, 15 bytes
Cooling Device
Temperature Probe Handle: 0x0029
Type: <OUT OF SPEC>
Status: <OUT OF SPEC>
Cooling Unit Group: 1
OEM-specific Information: 0x00000000
Nominal Speed: Unknown Or Non-rotating
Description: Not Specified
Handle 0x0037, DMI type 27, 15 bytes
Cooling Device
Temperature Probe Handle: 0x0036
Type: Power Supply Fan
Status: OK
Cooling Unit Group: 1
OEM-specific Information: 0x00000000
Nominal Speed: Unknown Or Non-rotating
Description: Cooling Dev 1
Sensor data:
iwlwifi_1-virtual-0
Adapter: Virtual device
temp1: +59.0°C
acpitz-acpi-0 # Fake, always reports these temperatures
Adapter: ACPI interface
temp1: +27.8°C
temp2: +29.8°C
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +51.0°C (high = +86.0°C, crit = +92.0°C)
Core 0: +51.0°C (high = +86.0°C, crit = +92.0°C)
Core 1: +47.0°C (high = +86.0°C, crit = +92.0°C)
Core 2: +49.0°C (high = +86.0°C, crit = +92.0°C)
Core 3: +49.0°C (high = +86.0°C, crit = +92.0°C)> Streacom FC8 Evo
I normally think PC cases are gaudy and boring even when trying to evoke some style. That stuff in Streacom website however makes me want to build something with it.
Isn’t it just a smoother-looking typical industrial PC case? Always liked them though, too.
Passively cooled PC probably won't work because the board will still have fan headers even if nothing is connected to them.
So we just need to implement the opposite of what OP has on our PCs, i.e. make OS think there are no fans.
Yes and another method of controlling them.
External cooling device?
The computer knows there's a fan because it sees tacho output. If it doesn't see tacho, shrug. You can get an external temperature-controlled PWM controller for a few units of your local currency on AliExpress, steal 12V from somewhere (Molex header or whatever) and run the fans off that. Figure out where to put the temp sensor to get the desired effect.
There are far better ways to do this, but they require software engineering, not €3 and 15 minutes.
The computer knows there is a fan because it knows when there isn't a fan. By subtracting where there is a fan from where there isn't a fan, or where there isn't from where there is (whichever is greater) it obtains a difference, or deviation...
"because it knows when there isn't a fan"
How does the computer knows that? You mean the parts that can meassure temperature will meassure where it gets warmer, or where it doesn't get warmer, altough it should?
How does the system knows, it is not a local heat pipe, transferring heat away?
(the comment you're replying to is a meme - https://knowyourmeme.com/memes/the-missile-knows-where-it-is)
Ugh, and unfortunately, this meme makes perfect sense in this context.
This meme makes perfect sense in almost all contexts - at least continuous ranges are involved. I salute GP for fitting it for use with a discrete case.
The problem is not the fan, it’s the fan controller on the motherboard. I doubt a nonfancy fan controller will bother to drop off the bus/whatever if it doesn’t have fans connected, and the comment by 'patrakov upthread seems to confirm this.
I feel like we could make our operating system more secure and make things easier for researchers by simply making a normal OS look like a virtual machine. Any program that needs to access resources in a non-virtualized way would have to ask for permission first. If granted, it could then see the relevant information or access the necessary APIs.
This way, malware authors would have to choose between making things easier for researchers or targeting far fewer people.
Either way, everyone except the malware creators wins.
Genode / SculptOS[0] go this direction. Before starting any process, you craft a view of the hardware resources it will see. Applications come with resource request definitions which you can satisfy by attaching real, virtual, or null resource.
It's a pretty neat system; runs Doom, so we know it's production ready; and the source is meticulously organized.
The docs try to be overly general, IMHO, clouding the core ideas. If you're interested, I recommend just spinning up a VM and mucking about, along with the user guide.
Anti-cheat software vendors would lose as well. I prefer the software I run to know its place, but there are enough people who enjoy multiplayer games that hate cheaters more than they hate what amounts to spyware.
I wonder if gaming cyber cafes that have no input ports that only play against another PCs of the same cyber franchise would be a sustainable business venture "no cheaters, no need to install spyware in your own device, warm coffee brought to your table just by clicking a desktop shortcut"
This is basically the value proposition for game consoles, for both players and game developers. For the player, secure gaming-specialized device that they don't have to set up and manage in the way a general-purpose computer requires. For the developer, a standardized trustable platform where they can avoid much of the anti-cheat complexity by letting the platform maintain security instead.
Definitely not enough people caring about anti-cheat spyware.
The other important incentive would be games that cannot be cheated, I saw a few games on steam that have reviews informing potential buyers that the games have been ruined because the devs didn't implement a successful anti-cheat system.
> simply making a normal OS look like a virtual machine
Or perhaps the other way around?
That is making VMs totally unaware they've been virtualised, as I believe IBM's lpars work…
That doesn't seem like it would be possible, if you want all the convenient hooks in VM's for them to be able to integrate with and be usable from the host system.
The solution really does seem like implementing those same hooks in non-VM environments, but preventing their actual usage behind permissions. In a VM, the permissions could genuinely be granted or denied. In a non-VM they would always be denied. But malware could never be able to tell why it was denied permission.
"Simply"
This is a huge, huge, huge amount of work. Even the most obvious things -- like "can you run a VM?" -- can require huge support, in that case even from the hardware, when you want to do them within a VM.
Oh please no. That would make using PC and writing apps a chore. There is a reason why nobody really works with mobile OS or Chrome OS.
I am yet to see _any_ consumer-oriented motherboard where SMBIOS descriptions have even a passing relationship to the actual hardware. I would not be surprised if this malware would also fail in 50% of real hardware out there. But I also guess malware can afford this failure rate; as long as it guarantees it also fails on 100% of VMs/debuggers, it is worth it.
But if these assumptions are true then I'd presume malware authors would do timing checks rather than the trivially "emulable" SMBIOS.
> I am yet to see _any_ consumer-oriented motherboard where SMBIOS descriptions have even a passing relationship to the actual hardware.
This seems to be especially true for cheap chineese boxes. If I had a dollar for every time I saw "to be filled in by OEM" strings in "live/production" BIOS images ... i'd be retired :).
Bonus points for a non-unique UEFI UUID that is already enrolled in some random company's Microsoft Intune / Windows Autopilot instance so when you fire it up off a fresh Windows install it begs you to sign into $RANDOM_COMPANY_WITH_BAD_IT_CONTROLS.
Triple-points if the vendor includes a sticker telling you to complete Windows OOBE without connecting it to the Internet to avoid this.
I still can't believe that microsoft allows companies to essentially brick machines they don't even own like that. Seems criminal to me.
More criminal than hard coding UUID for some other device?
You can do whatever you want with your device. Microsoft is also doing whatever they want with your device.
If the OEM hadn't messed up and reused UUIDs, it would be "Microsoft letting companies do whatever they want with their device", which is not unreasonable. OEMs reusing UUIDs for some ridiculous reason is breaking down the chain of "whose device is it".
Forget about the OEM. If you find out someone else's UUID you can spin up a VM with your UUID set to theirs and then add it to your system and brick their machine?
I’m fairly sure my expensive ASUS ROG motherboard (ergo: not even their budget line) also had a “to be filled in by OEM” string that I couldn’t even override. (ASUS have a utility but it’s not publicly available, probably just for computer shops)
Need I remind you of the ASUS Zenbook UX21 from 2011, almost the first machine to be branded an “Ultrabook”, that experienced sudden shutdowns under Linux (but not Windows) because its ACPI firmware scribbled over random places of I/O space in an attempt to initialize a SATA controller the SSD-based machine did not physically have? (Can’t find the link now, sorry.)
But that's exactly the point. Computer shops that sell complete systems are supposed to put their name in the "system manufacturer" field. If you bought the mainboard yourself and built your own system, then who do you think should have replaced that string?
I get that, but I'd expect it to be a setting I can change in BIOS, or at least default to the motherboard's model number. Instead, if I build my own, I just can't change it ever because ASUS refuse to release it publicly. Hell, even the shop I used for the previous PC didn't have such a tool. (And if you change it in Windows, it's rewritten from SMBIOS every boot)
I worked in PC stores for a long time and never had any such access to such a tool. Sounds like something only the big OEM's would get honestly.
It's mentioned in some ASUS docs, but it's not available on their support anywhere. Probably reserved for big OEMs, yeah.
I stumbled upon that feature in the (MS-DOS based) bios flashing utility for some mainboard, via some command line option. Just don't remember which one it was, it was ages ago.
Okay but we're talking about consumer-grade boards sold at retail here. It's not like these are boards that fell off a truck. ASUS sells them this way, but then doesn't give consumers a way to alter that field.
How about set it to default "Asus", and computer shop has tool to override it
Then you can't tell it apart from systems that were actually built by Asus. But given that most smaller shops don't seem to have access to the tool anyways, we'd then just have the opposite situation.
If you buy a motherboard to build your own (or any, even if it is for someone else) PC, you are the OEM.
That's basically my experience for 2 other "gaming" motherboard brands that aren't ASUS as well. My guess is that people who build their own PCs probably don't care about SMBIOS serial numbers being properly populated, so why bother?
I would care if I could change it, but you need a proprietary tool that you can't obtain. (Every other way I found involved patching the UEFI and turning off Secure Boot)
But this is correct, if the Mainboard was bought as is and was not part of a complete system, the system manufacturer is obviously not filled out as there is none.
Malware has bugs. In fact some viruses have done far more damage than the author intended due to bugs.
There was a substantially effective virus years ago that made it around the world in 90 minutes, and it turns out a bug in its networking code caused it to spread half as fast as it should have. Meaning it should have been everywhere in 45 minutes. You can still do a lot of damage without hitting every machine in existence.
How does Linux find the fans these days? Is it an ACPI/EFI thing now? Nearly all my machines seem to have correct fans/sensors.
Is it the actual malware checking this or some researcher-created malware samples?
Using such tricks might seem like a cute way for malware to make analysis difficult, but often times calling these obscure system APIs can be detected statically, and you bet that it will flagged as suspicious by AV software. If the malware binary is not obfuscated to hide such calls, I'd even call them "counterproductive" for the malware authors!
The legit programs interested in these APIs are almost always binaries signed by well known (and trusted) CAs - making it sensible for the analysis to report sus behavior.
I worked as a junior in this field, and one of my tasks was to implement regex pattern matching to detect usages of similar APIs. Surprisingly effective at catching low hanging fruit distributed en masse.
Malware is signed surprisingly often these days, you can't rely on malware companies not to sign their binaries anymore. Hacked code signing certificates seem to be all over the place and Microsoft seems very reluctant to revoke trust out of fear of actually breaking their original customers' software.
Same goes for the common vulnerable drivers that malware likes to load so they can get into the kernel. A weird tiny binary making WMI calls may stand out, but a five year old overclocking utility full of vulnerabilities doing the same queries wouldn't.
From the research I've read, this doesn't seem to be about avoiding detection as much as it's about not detonating the real payload on a malware analyst's machine. If the AV flags the binary or the detection trips, the second stage isn't downloaded and the malware that does stuff that makes the news doesn't execute (yet).
>Hacked code signing certificates seem to be all over the place and Microsoft seems very reluctant to revoke trust out of fear of actually breaking their original customers' software.
AFAIK most (all?) code signing CAs are cracking down on this (or maybe Microsoft is pushing them) by mandating that signing keys be on physical or cloud hosted HSMs. For instance if you try to buy a digicert code signing certificate, all the delivery options are either cloud or physical HSMs.
It's a change to the CA rules that was passed in https://cabforum.org/2022/04/06/ballot-csc-13-update-to-subs... to align OV certificate requirements with the EV ones (that enforces the use of HSMs/hardware tokens/etc) that was meant to go into effect for new certificates issued after November 2022, but was delayed and eventually implemented on June 1 2023.
So, from a security perspective, maybe we should run all software inside a VM then?
You'd lose things like hardware acceleration.
That said, plenty of malware will stop downloading additional modules or even erase itself when it detects things that could indicate it's being analysed, like VirtualBox drivers, VMWare hardware IDs, and in the case of some Russian malware relying on the "as long as we don't hack Russians the government won't care" tactic, a Russian keyboard layout.
It won't stop less sophisticated malware, but running stuff inside of a VM can definitely have viruses kill themselves out of fear of being analysed.
> You'd lose things like hardware acceleration.
This is increasingly less true. SR-IOV and S-IOV are becoming increasingly common even in consumer hardware and OS manufacturers are increasingly leaning on virtualisation as a means to protect users or provide conveniences.
WSL has helped with virtualisation support quite a bit as a means of getting hardware manufacturers to finally play nice with consumer virtualisation.
And Microsoft is even now provides full ephemeral Windows VM "sandboxes". The feature that came with them that surprised me was that they support enabling proper GPU virtualisation as well.
But then you have your "VMs" accessing the real hardware, so the benefits of the VM reduce if not disappear. You literally can't have the cake and eat it too.
Not entirely? The virtualised PCIE frameworks (SIOV, SRIOV, etc) don't actually give direct access to the hardware but rather create a virtualised device inside the PCIE device akin to how modern PCs virtualise CPUs and memory.
Well, that's precisely the point of these frameworks. They give direct access to the hardware in order to gain the speed advantages of ... directly accessing the hardware. The PCIe aspect of this is just (very high level description) a way to let the hardware know what VM is making the request.
You're now at the mercy of the hardware manufacturer on whether there's isolation between the different "partitions" or ... nothing at all. Your attack surface expands in a way that's difficult to imagine.
> They give direct access to the hardware
> You're now at the mercy of the hardware manufacturer
No!
Read up on SR-IOV before you continue posting more misleading nonsense.
https://en.wikipedia.org/wiki/Single-root_input/output_virtu...
And why don't you explain what exactly you think the nonsense is rather than violating the HN guidelines with a contentless RTFM message?
Your one link literally says the same thing I have said (a way to multiplex access to the bus). This is ALL about giving VMs direct access to hardware. It makes no sense to even discuss features like this otherwise. What do you think this is for if not real hardware acess? Giving VM hosts an easier time emulating Intel PRO1000 ethernet cards?