Posted by todsacerdoti 1 day ago
And also set up a Russian keyboard: https://krebsonsecurity.com/2021/05/try-this-one-weird-trick...
# 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)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.
If you've got a little Node-RED box reading serial data from your bar code reader, doing lookups in your SAP database, and then sending Modbus commands to your PLC to redirect a box down a different conveyor line, it's probably an industrial PC.
There are far better ways to do this, but they require software engineering, not €3 and 15 minutes.
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?
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.
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.
Or perhaps the other way around?
That is making VMs totally unaware they've been virtualised, as I believe IBM's lpars work…
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.
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.
But if these assumptions are true then I'd presume malware authors would do timing checks rather than the trivially "emulable" SMBIOS.
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 :).
Triple-points if the vendor includes a sticker telling you to complete Windows OOBE without connecting it to the Internet to avoid this.
# Manufacturer: Micro-Star International Co., Ltd.
# Product Name: PRO Z790-A WIFI (MS-7E07)
$ sudo cat /sys/firmware/dmi/tables/DMI | strings | grep -i filled | wc -l
10
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.
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.
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).
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.
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.
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.
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.
> 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...
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?
SR-IOV: https://cdrdv2-public.intel.com/321211/pci-sig-sr-iov-primer...
S-IOV: https://cdrdv2-public.intel.com/671403/intel-scalable-io-vir...
What they are doing is "technically" giving direct bus access, however the bus access they are giving is restricted such that the VM's accesses are all tagged and if they access anything outside the bounds they are permitted (as defined by access controls on the hardware during configuration), then you get a fault instead of the VM successfully touching anything.
This is similar to how VT-d and other CPU virt extensions allow direct access to RAM but with permissioning and access control through the IOMMU.
And then the other major component of SR-IOV and S-IOV is that they virtualise the interface on the PCI-E hardware itself (called virtual functions) and all of the context associated, the registers, the BAR, etc. This is akin to how VT-x and similar instructions virtualise the CPU (and registers, etc). And notably these virtual functions can be restricted via access controls, quotas, etc in hardware.
So your existing VT-x extension virtualises the CPU, your existing VT-d extension virtualises the IOMMU and RAM, your existing VT-c virtualises network interfaces (but not PCI-E in general). Now SR-IOV and S-IOV virtualise the PCI-E bus w/ access control over the lanes. And now SR-IOV and S-IOV virtualise the PCI-E device hardware and their functions/interface on the bus (akin to VT-x and VT-d).
Now notably S-IOV should be seen as a "SR-IOV 2.0" rather than an accompanying feature. It essentially moves the virtual function to physical function translation from the CPU or hardware in the chipset directly into the PCI-E device itself.
> What they are doing is "technically" giving direct bus access, however the bus access they are giving is restricted such that the VM's accesses are all tagged
This is exactly what I know and what I said in my original post: a way to identify which VM is accessing what. For... giving that VM access to the hardware.
> and if they access anything outside the bounds they are permitted (as defined by access controls on the hardware during configuration), then you get a fault instead of the VM successfully touching anything.
Again, this is exactly what I said: you are now at the mercy of the hardware manufacturer whether there is any partitioning whatsoever. To think otherwise is wishful thinking that I do not know where it comes from.
This is entirely the definition of giving the VM direct access to the hardware. There is no software-controlled emulation whatsoever going on, so you explicitly lose containment and increase your attack surface.
For everything except the simplest of ethernet cards, your hardware is likely implementing this multiplexing in closed source firmware done by hardware engineers. Very likely the worst type of code ever written security-wise.
> This is similar to how VT-d and other CPU virt extensions allow direct access to RAM but with permissioning and access control through the IOMMU.
Not at all. Usually IOMMU is for constraining hardware that already has direct access to the RAM in the first place.
> And then the other major component of SR-IOV and S-IOV is that they virtualise the interface on the PCI-E hardware itself (called virtual functions)
Is this the source of the confusion? That because it is called virtual you think this virtualized somehow? It is the reason I call it partition because it is much closer to what it is (from a hw point of view).
> your existing VT-x extension virtualises the CPU, your existing VT-d extension virtualises the IOMMU and RAM, your existing VT-c virtualises network interfaces (but not PCI-E in general
This is meaningless because it mixes and matches everything. What does it mean to "virtualize the RAM"? RAM is already virtualized by the normal MMU, no VT-d needed at all. Hardware is the one who may require to also have its RAM access virtualized so its idea of memory matches that of the VM directly accessing hardware (instead of through a software emulation layer), and that is what benefits from an IOMMU (but does not generally require it, see GART and VT-c).
But the entire point of this is again to give the VM direct access to hardware! What is it exactly that you want to refute from this?
Yes but the whole point is that it's moving the isolation of the VM's access from software to hardware. Yes you are giving direct access to a subset of hardware but that subset of hardware is configured from outside the VM's access to restrict the VM's access.
> Again, this is exactly what I said: you are now at the mercy of the hardware manufacturer whether there is any partitioning whatsoever. To think otherwise is wishful thinking that I do not know where it comes from.
That's not actually true to my knowledge. S-IOV and SR-IOV require hardware support. Sure the manufacturer can do a shit job at implementing it but both S-IOV and SR-IOV require partitioning. But if you are granting your VMs S-IOV or SR-IOV access to hardware, you are at minimum implicitly trusting that the hardware manufacturer implemented the spec correctly.
> There is no software-controlled emulation whatsoever going on, so you explicitly lose containment and increase your attack surface.
This is true but the same is true of VT-x, VT-d, etc (i.e. the commonplace virtualisation extensions). It is no less true with S-IOV or SR-IOV other than by them being newer and less "battletested". If you use virtualisation extensions you are no longer doing pure software virtualisation anyways.
> For everything except the simplest of ethernet cards, your hardware is likely implementing this multiplexing in closed source firmware done by hardware engineers. Very likely the worst type of code ever written security-wise.
The exact same applies to the microcode and internal firmware on modern CPUs and the associated chipset.
> Not at all. Usually IOMMU is for constraining hardware that already had direct access to the RAM in the first place.
Yes. And VT-d extends this for VMs by introducing hardware level IO, interrupt, and DMA remapping so that the host doesn't need to do software level remapping instead.
> Is this the source of the confusion? That because it is called virtual you think this virtualized somehow? It is the reason I call it partition because it is much closer to what it is (from a hw point of view).
I call it virtualisation because it is virtualisation. In SR-IOV it is still virtualisation but yes it is architecturally similar to partitioning with access controls however that is still virtualisation, it just prevents nesting. With S-IOV however it is full on-hardware virtualisation and supports nesting virtual devices.
> What does it mean to "virtualize the RAM"? RAM is already virtualized by the normal MMU, no VT-d needed at all. Hardware is the one who may require to also have its RAM access virtualized so its idea of memory matches that of the VM directly accessing hardware (instead of through a software emulation layer), and that is what benefits from an IOMMU (but does not generally require it, see GART and VT-c).
Yes I was playing loose with the terminology. Yes RAM is already virtualised (to a certain degree) but VT-d extends that completely and allows arbitrary nesting. And yes VT-d is not required for virtualisation but it is important in accelerating virtualisation by moving it from software virt to hardware virt.
> But the entire point of this is again to give the VM direct access to hardware! What is exactly that you want to refute from this?
I think the disconnect here is that I (and I assume others) are operating under the assumption that giving the VM access to an access controlled and permissioned subset of the hardware through hardware virtualisation extensions/frameworks wouldn't fall under "giving the VM direct access to the hardware" any more than CPU virtualisation extensions do (which are essentially always enabled).
----------
Edit: Oh I should also add in that another commenter was in our comment chain. I just realised they were the one arguing that SR-IOV/S-IOV wouldn't make you at the mercy of the HW manufacturer to implement the isolation and virtualisation functionality correctly. That may help clear up some misunderstanding because I 100% get that you are reliant on the HW manufacturer implementing the feature correctly for it to be secure.
But who is actually gating access to this "subset" (which normally isn't a subset of functionality anyway) ? Answer: the hardware.
Before, it was software who was emulating hardware and implementing whatever checks you wanted. Now, the VM OS is directly accessing the hardware, banging its registers, and you literally depend on the hardware to enforce any kind of isolation between accesses from the VMs.
> This is true but the same is true of VT-x, VT-d, etc (i.e. the commonplace virtualisation extensions). It is no less true with S-IOV or SR-IOV other than by them being newer and less "battletested". ". If you use virtualisation extensions you are no longer doing pure software virtualisation anyways.
No, this is not the correct analogy. Even without VT-x, CPUs since the 386 era are already designed to execute untrusted code. Adding VT-x on it changes a bit the picture but it is almost an irrelevant change in global architecture overall, since the CPU is in any case is directly executing VM guest code (see early virtualizers which did plenty well without VT-x).
Here, you are allowing untrusted code direct access to hardware that has never even imagined the idea of being ever accessed by untrusted software, or even user level code to being with for most it (very few exceptions such as GPUs).
The difference in the size of the security boundary is gigantic, even hard to visualize.
The correct analogy would be to if you were switching from say a JavaScript VM generting native cpu code into directly executing native CPU code directly downloaded from the internet. On a 8086 level CPU with a haphazardly added MMU on top of it. Sure, works on theory. In practice, it will make everyone shiver (and with reason). That is the proper analogy.
The discussion about SRIOV is a red herring because these technologies are about allowing this direct hardware access. It is not that SRIOV is a firewall between the hardware and the VM (or whatever it is that you envision). They are technologies entirely designed to facilitate this direct hardware access, not prevent or constrain it in any way.
I've been gaming through a VM for the last few years now, and hw acceleration is not an issue.
You would passthrough a GPU and then enjoy near native performance.
I use iGPU for my Linux desktop and a dGPU passed through to my gaming vm.
I also passthrough the whole bluetooth device to the VM as I don't use bluetooth on my host anyway. That way I can use gamepads and headset in the vm, too.
> That said [...]
Now you're just riffing.
It happened on mobile because Android (dunno iOS's permission model well enough) is more on the developers' side than the user's side, or at least they're more concerned with everything just working (for some values of "just work") than with giving users a chance to make sure that things don't work that the users don't want to work. A fine-grained capacity system where users were given the option to lie to the software about what capacities it has wouldn't be perfect either, but it would remove a lot of the user-focused pain points of Android's permission model.
Well, after we send a copy of the program to Microsoft, of course
Just push untested code/releases on production machines across all of your customers. Then watch the world burn, flights get delayed, critical infrastructure gets hammered, _real_ people get impacted.
_Legitimate_ companies have done more damage to American companies than black hat hackers or state actors can ever dream of.
The folks behind xz util within libzma aspire to cause the amount of damage companies like ClownStrike and SolarWinds have caused.
In comparison, a lutron switch is $70 and the hub is $50.
You could certainly bodge together a similar system for less money, but the controls won't be as nice and it'll be nowhere near as hassle free long term. HomeAssistant and competitors have really been catching up in the past few years though, i'm excited to see competition in the market. I wish they could all play nice together with reasonable APIs :/
A next step to making the VM look real is having simulated temperature sensors that actually change in response to CPU load.
Or maybe just increments to absurd numbers or negative values. Or locks up when probed. Either way could be fun.
unironically that would mimick a bunch of existing hardware out there. I owned a PC motherboard that always reported a -65535c in a non existing sensor.
my guess is some sensor described but non existing, probably reporting an infinite value of resistance of some unused pin...
i did one little expirement on faking VM's powersupply. done it with 'HotReplaceable=Yes' and 'Status=OK', and you suddenly look like a $5k baremetal server.
cmd used
pip install dmigen dmigen -o smbios.bin \
--type0 vendor="American Megatrends",version="F.1" \
--type1 manufacturer="Dell Inc.",product="PowerEdge T630" \
--type39 name="PSU1",location="Bay 1",status=3,hotreplaceable=1
Can we remove casual body shaming from our language please?
The large majority of humans adapt our language to the context and the audience every time we open our mouths or put our hands on the keyboard. I’d like the author to do a little more of that.
Men are routinely shamed for their bodies, especially penis size, and I think it makes their lives worse. So I’d like people to stop doing it.
Let’s assume those studies are off by an order of magnitude and it’s only 1% of men who feel insecure about their penis. In the US, that’s still 1.7 million men.
If I had to choose between vulgar jokes and two million people having a better relationship with their bodies, I know where my priorities lie.
[1]: https://www.issm.info/sexual-health-qa/what-percentage-of-me...
-I don't know Jenny, I kinda wish you didn't have one at all
You're going to burn out very quickly if this is the level of attention and engagement you desire in the world of the internet.
And it's clear that the people, as they really are, are all despicable and horrible inside.
thanks for the pep talk, coach, but you're not my coach and i didn't ask for any coaching. i know what i'm dealing with. i've probably been on the internet longer than you've been alive, so i've watched the internet go from a fairly healthy place to just pile after pile of shit everywhere people interact with each other online. i've watched more and more people show up solely so they can be themselves, and more and more places appear solely for people to be unreastrainable asses to each other.
There is no humor allowed on this platform; real life is much more colorful and fun.
if you think making fun of people is colorful and fun you are again making my point for me better than i ever could. please continue.