Slashdot Mirror

UEFI: the only thing imaginable that could be worse than BIOS. Now, every computer has a shitty DOS-class OS burned into the firmware, which is permanently resident, and the perfect platform for back doors and spyware. That is on top of the IME, which reduces trust even further. Intel x86 considered harmful paints a vivid and damning picture of the modern x86 platform.

Any bootstrap mechanism should be simple and transparent, and leave the owner with full control of the machine. CoreBoot is a good starting point. Replacing x86 is a good next step, since Intel refuses to document the platform, and requires binary blobs to boot the platform.

There are worrying efforts which may also infect RISC-V platforms with UEFI and "secure" enclaves. It is ironic that open hardware efforts could help accelerate locked-down computing, if vendors widely adopt these user-hostile technologies.

CoreBoot has its place but it does not natively provide the security of the UEFI specification and also does not handle all of the potential use cases that the UEFI specification does as well. And how many exploits have you seen recently that revolve around issues in the firmware and not issues in the secure processor? I can tell you right now that most computers that have shipped in the last year or two, while potentially containing exploitable flaws, have generally not had any issue that allows an attacker to compromise the flash part unless they exploited a security issue in a BMC or through a secure processor such as ME or PSP.

UEFI: the only thing imaginable that could be worse than BIOS. Now, every computer has a shitty DOS-class OS burned into the firmware, which is permanently resident, and the perfect platform for back doors and spyware. That is on top of the IME, which reduces trust even further. Intel x86 considered harmful paints a vivid and damning picture of the modern x86 platform.

Any bootstrap mechanism should be simple and transparent, and leave the owner with full control of the machine. CoreBoot is a good starting point. Replacing x86 is a good next step, since Intel refuses to document the platform, and requires binary blobs to boot the platform.

There are worrying efforts which may also infect RISC-V platforms with UEFI and "secure" enclaves. It is ironic that open hardware efforts could help accelerate locked-down computing, if vendors widely adopt these user-hostile technologies.

Ideas are welcome as to how to get it there. It is cruel to condemn yet another generation to x86, and the inherent insecurity of software built for such a flawed architecture. Attempting to create a secure system on x86 is like building on sand, and the instruction set itself is also a nightmare for system and language developers.

Looks to be a regurgitation of Joanna's paper http://blog.invisiblethings.or...

While I commend the guys at BitDefender for finding this vulnerability its severity as a tad overstated.

Most if not all virtual machines are not encrypted, so your hosting provider has full access to your encryption keys which means there are easier ways to decrypt/intercept traffic.

Presumably you can solve this problem by using full disk encryption but then you need to find a way to pass your encryption password to your virtual host and you will surely do that through the means provided by your hosting provider, which means your password will be intercepted en route and again your hosting provider will have full access to the disk image.

In short you cannot trust anything you're not running from your own physically secured environment.

And even in your own fully secured physical environment you're still f*cked.

Investing in the development of sane architectures would radically reduce the scope of the problem. Securing x86 is a near hopeless cause; it is like trying to seal a volcano with band-aids. A better architecture can eliminate the vast bulk of exploits possible on x86 by design, while enabling more efficient and secure operating systems. On the other hand, our current government probably appreciates how Intel has effectively back-doored all current x86 systems.

The progress of Tails is welcome, but there is a lack of trustworthy hardware to run it on. All current Intel processors are hopelessly and fundamentally flawed. The state of x86 security was never good, but Intel has taken it to a whole new level, and now provides the perfect platform for invisible backdoors, rootkits, and other malware.

True, so use a computer that can't be traced to you.

Buy a second hand laptop for cash in a private sale, somewhere away from the cameras, and use it only for that purpose. Transfer files using USB keys or disposable data CDs, to or from your working computer which is air-gaped, or at least not used for anything the watchers may be interested in.

The progress of Tails is welcome, but there is a lack of trustworthy hardware to run it on. All current Intel processors are hopelessly and fundamentally flawed. The state of x86 security was never good, but Intel has taken it to a whole new level, and now provides the perfect platform for invisible backdoors, rootkits, and other malware.

This is exactly what I have been waiting for: a reasonable NAS board with decent CPU, ECC, and ample SATA, which isn't outrageously overpriced. Perfect for ZFS. ARM is a bonus for those looking to get away from x86 and its various "features". Assuming the 8x PCIe slot is open ended, it could make an inexpensive (ECC enabled) desktop too.

The Intel C2750 could have been that, but the $450 boards were not appealing; at that point, one may as well get a Xeon. Strangely enough, this wasn't entirely Intel's fault, but it doesn't change the fact that it was rip off either way. With a more integrated ARM SoC, there is at least the possibility of an inexpensive NAS board. Even if not, I expect that many will pay a premium to escape from Intel's crappy architecture and monopoly abuses.

As I strongly implied, type 1 hypervisors are more secure, not less, than type 2. Try at least reading the parent post before lapsing into your "no, no, no..." mantra. Implying that type 2 is more secure is absurd.

If you haven't already stopped reading (again), you might want to read this: http://blog.invisiblethings.or...

In short, a jailed process on a host system still has a very complex, privileged kernel to try and exploit. But in a Xen guest VM, its only the complexity of the hypervisor interfaces that matter since the kernel is unprivileged and must go through the same interfaces to attempt an attack on anything else in the system.

Here's another way to think about it: BSD security literature relies heavily on jails. But what proportion of BSD-based applications are running in BSDs that are merely virtualized guests?

Finally, how do jails deal with attacks on firmware or misbehaving hardware? That I'm aware of, using an IOMMU to assign a (real) NIC on a PCI bus to a jail is not possible, and would be pointless if it were. But with hypervisors like Xen on hardware that supports IOMMU, assigning hardware devices to guest VMs is a feasible way to increase security that is growing in popularity.

Qubes OS uses a Type 1 hypervisor to simplify and harden system security against such vulnerabilities. The privileged parts of the system are kept relatively small and aren't used for any user applications. All apps and even some drivers (like NICs) are assigned to VMs, which the user can give different trust/risk designations and color codes.

Because isolating hardware is considered part of the solution, Qubes systems need IOMMU hardware to operate securely. But this high degree of isolation is what eliminates holes.

Formal proofs of the system would be nice, but they are hard to do and pointless without hardware isolation. So one could view Qubes as a way to take the smallest functional hypervisor with hardware isolation capabilities (Xen) and use it like a microkernel. One difference with a traditional microkernel is you have the rich feature sets of Linux and Windows kernels/drivers at your disposal within the unprivileged domains.

The best way to deal with the situation is to run browsers under a hardened type-1 hypervisor that has a tiny attack surface itself. Create an 'untrusted' domain and tool around the Internet to your heart's content, or use disposable VMs that appear for risky temporary tasks and then self-delete.

This exists and is called Qubes OS. Also, I believe OneLaptopPerChild's OS was isolating key processes in VMs. This is the future, but the NSA won't like it, so instead we'll probably get more insecure browsers, a huge buggy attack surface across all of Linux called systemd that replaces hardened and tested ye olde Unix startup scripts, and a BIOS-replacement called UEFI which is full of wonderful opportunities to rootkit your firmware.

We just keep on adding more attack vaginas and rectums to allow penetration of our systems.

The best way to deal with the situation is to run browsers under a hardened type-1 hypervisor that has a tiny attack surface itself. Create an 'untrusted' domain and tool around the Internet to your heart's content, or use disposable VMs that appear for risky temporary tasks and then self-delete.

If we want this rich content in our lives we have to accept the complexity and the risk to some degree. Using an OS built on security by isolation allows us all that complexity, but behind very strong, simple security structures that are built on the best hardware virtualization features. This is probably the only good way to keep private data and core systems from being exploited.

I even have reservations about air-gapping as a 'good' security solution: As the practice stands with PCs now, its too free-form and there are too many complex code layers to think about and work around while sneaker-netting info and code between systems. A USB device that got infected could pretend to be any of hundreds of devices that use dodgy, vulnerable drivers; and that doesn't even touch on the risk from complex file formats or desktop features.

Christ ...we meet again. Are you like a Qubes developer or something because it's either that or you're REALLY a fanboy.

Is this what you're talking about: http://blog.invisiblethings.or...

It's an impressive idea, although it depends on the TPM which is not designed to be safe against physical attacks. There's no reason the implementation of that should only work with QubesOS, either, although the developers appear to be the same.

Qubes OS will detect this type of attack, and in most cases prevent it. It can also protect you against badUSB if you create a USBVM to handle the USB controllers.

Detection comes via the Anti-Evil Maid package, which uses a TPM to measure the system firmware, bootloader, kernel and hypervisor. It optionally can create a USB thumbdrive for booting Qubes in AEM mode. (AEM should *always* detect a compromised base system, but using a thumbdrive can help prevent an attack from succeeding in an 'Evil Maid' scenario.)

Qubes uses Xen, a type 1 bare-metal hypervisor with a miniscule attack surface, and uses that as a chokepoint to regulate ALL system activity (including network and graphics) in a way other OSes do not. Graphics is one of the weaknesses in VM host security that enables 'VM Breakout' escalation attacks. In using VMs for all sensitive functions, remote attacks are highly unlikely to escalate and take over the core system or firmware.

What, you mean a woman is actually doing something useful involving computers? She must be fat, old, ugly, or all three.

None of the above: http://invisiblethings.org/about.html - she is young and rather attractive.

Subject: Every computer hackable by Radio Freq?
- a global conspiracy?

This lady claims to have found some strange things on her Windows PCs and Linux!

Subversionhack Archive
https://tagmeme.com/subhack/

So, with modern blackboxed hardware components, are all of our PCs hackable via radio frequency / ham packet radio type of blackbox voodoo?

Dig deep, I've found no other site like this. Are Linux/BSD varieties vulnerable?

http://www.invisiblethings.org/code.html
http://www.invisiblethings.org/papers.html

AND

This talk explores three possible methods that a hardware Trojan can use to leak secret information to the outside world: thermal, optical and radio.

In the thermal Trojan demo, we use an infrared camera to show how electronic components or exposed connector pins can be used to transmit illicit information thermally. In the optical Trojan demo, we use an optical-to-audio converter to show how a power-on LED can be used to transmit illicit information using signal frequencies undetectable by human eyes. Finally, in the radio Trojan demo, we use a radio receiver to show how an external connector can be used to transmit illicit information using AM radio transmission.

http://www.cvorg.ece.udel.edu/defcon-16/
https://www.defcon.org/html/defcon-16/dc-16-speakers.html#Kiamilev

fools laugh and cry tinfoil, others read and learn and decide for themselves

http://bluepillproject.org/

http://subversionhack.livejournal.com/1815.html

"I sincerely believe that Blue Pill technology will (very soon) allow for creating 100% undetectable malware, which is not based on obscurity of the concept. And I already stressed this in the description of my talk here (http://syscan.org/program.html) and here (http://blackhat.com/html/bh-usa-06/bh-usa-06-speakers.html#Rutkowska). The working prototype I have (and which I will be demonstrating at SyScan and Black Hat) implements the most important step towards creating such malware, namely it allows to move the underlying operating system, on the fly, into a secure virtual machine."
  - http://theinvisiblethings.blogspot.com/2006/07/blue-pill-hype.html

http://rayer.ic.cz/romos/romose.htm

"The ROMOS is a stand-alone x86 code allows you to load and run your own binary code or 3rd-party code. ROMOS rely on BIOS functions only so it can be executed directly without any operating system. The main purpose of ROMOS is to be placed in a ROM, from where it can load/run other software (e.g. bootmanager, HW diagnostics, special controlling software...) during POST (Power-On Self Test) while your PC is booting up. It can also load DOS-based operating systems (may be other OSes) such as FreeDOS stored in ROM together with ROMOS. This mean that any floppy/harddisk/CD-ROM drive is not needed. It may be very useful in various embedded diskless systems. Or simply as reserve OS for rescue use. Other applications are on you."

mark this offtopic while you browse for porn to satisfy one more rub-one-off session, despite it containing more than the OP.

Subject: Every computer hackable by Radio Freq?
- a global conspiracy?

This lady claims to have found some strange things on her Windows PCs and Linux!

Subversionhack Archive
https://tagmeme.com/subhack/

So, with modern blackboxed hardware components, are all of our PCs hackable via radio frequency / ham packet radio type of blackbox voodoo?

Dig deep, I've found no other site like this. Are Linux/BSD varieties vulnerable?

http://www.invisiblethings.org/code.html
http://www.invisiblethings.org/papers.html

AND

This talk explores three possible methods that a hardware Trojan can use to leak secret information to the outside world: thermal, optical and radio.

In the thermal Trojan demo, we use an infrared camera to show how electronic components or exposed connector pins can be used to transmit illicit information thermally. In the optical Trojan demo, we use an optical-to-audio converter to show how a power-on LED can be used to transmit illicit information using signal frequencies undetectable by human eyes. Finally, in the radio Trojan demo, we use a radio receiver to show how an external connector can be used to transmit illicit information using AM radio transmission.

http://www.cvorg.ece.udel.edu/defcon-16/
https://www.defcon.org/html/defcon-16/dc-16-speakers.html#Kiamilev

fools laugh and cry tinfoil, others read and learn and decide for themselves

http://bluepillproject.org/

http://subversionhack.livejournal.com/1815.html

"I sincerely believe that Blue Pill technology will (very soon) allow for creating 100% undetectable malware, which is not based on obscurity of the concept. And I already stressed this in the description of my talk here (http://syscan.org/program.html) and here (http://blackhat.com/html/bh-usa-06/bh-usa-06-speakers.html#Rutkowska). The working prototype I have (and which I will be demonstrating at SyScan and Black Hat) implements the most important step towards creating such malware, namely it allows to move the underlying operating system, on the fly, into a secure virtual machine."
  - http://theinvisiblethings.blogspot.com/2006/07/blue-pill-hype.html

http://rayer.ic.cz/romos/romose.htm

"The ROMOS is a stand-alone x86 code allows you to load and run your own binary code or 3rd-party code. ROMOS rely on BIOS functions only so it can be executed directly without any operating system. The main purpose of ROMOS is to be placed in a ROM, from where it can load/run other software (e.g. bootmanager, HW diagnostics, special controlling software...) during POST (Power-On Self Test) while your PC is booting up. It can also load DOS-based operating systems (may be other OSes) such as FreeDOS stored in ROM together with ROMOS. This mean that any floppy/harddisk/CD-ROM drive is not needed. It may be very useful in various embedded diskless systems. Or simply as reserve OS for rescue use. Other applications are on you."

mark this offtopic while you browse for porn to satisfy one more rub-one-off session, despite it containing more than the OP.

Read this

http://invisiblethings.org/papers/redpill.html

and they take a hefty chunk of change for the privilege.

Or if, say, the driver's authors somehow competes with MS.

Do VMMs really trap to the host OS? The reason I ask is that I recently discovered Red Pill which raised the following question: Since programs inside VMM indicate that the IDT is located at the address 0xFF......, doesn't that mean that it is VMM's own IDT, completely separate from host OS's IDT? (This implies that VMM has a driver that runs at Ring-0 privilege, among other things.) If my assumption is correct, then virtual machines are actually faster than suspected, and only the switch from VMM back to host OS is somewhat slow, requiring a change of IDT, GDT, and LDT.

Joanna Rutkowska's research is catching up to a truth few realized until just recently, This is just the tip of a whole can of worms that has been wiggling right under our noses for years.

If you check the comments below, (to a very good article) some commenters are rather hysterical, (in a bad way) and for good reason, but reflect the truth.

Rootkits headed for BIOS
Comments:

http://www.securityfocus.com/cgi-bin/index.cgi?c=a rticlecomments&op=display_comments&ArticleID=11372 &expand_all=true&mode=threaded

After reading this, if you don't have experience in these matters please refrain from commenting.
Rather, go read more of what Ms. Rutkowska has so expertly revealed:

http://invisiblethings.org/papers.html

"There are more things in heaven and earth , Haratio, than are dreamt of in your philosophies."

Not sure if you consider he as a security expert but Joanna Rutkowska uses Windows Vista. She was running Windows XP 64 bit before Vista was released IIRC.

There is also a purely software-based solution that doesn't lose quality: QEMU. Install this emulator, instal Windows inside there...

Vista, doesn't permit access to DRM'd content if you run it virtualized. At least, thats the license requirement, and there is a a suggestion that they use red pill techniques to detect virtualization for runtime checks. (I don't use vista, and I don't own any DRM'd content, so I'm not commenting from personal experience)

http://invisiblethings.org/papers/redpill.html

Basically, it tests the location of a particular piece of data.
If the machine is non-virtualised, it is stored in what is called the IDTR register (this location is constant).

However, as there is only one IDTR register, when virtualised, it is stored somewhere else.

There are other techniques available too; however this looks to be the simplest.

IMO, this new license is rubbish. I expect to go through 3 or 4 computers in vistas lifespan, which would need me to buy at least 2 licenses.

Whilst Linux would seem to be the perfect option, whenever I'm booted into linux, there is always something that comes up that I just can't do without lots of haxing.

My Mac on the other hand...

I can't believe no one has commented on the fact that she's female yet.

I'd hit it, assuming she's as cute as she looks in that picture.

Red pill

Used to detect if it's being run in a virtual machine.

Even better, use Joanna Rutkowksa's Red Pill technique, which effectively identifies a VM in a single instruction based on the address of the IDTR.

The fact of the matter is, everything described in the article is implementable right now with existing hardware. Any x86 machine can emulate an x86 machine. If you don't believe me, take a look at qemu, which can do so entirely in user-mode.

Rutkowska's approach to detecting whether code is run in a virtual machine is based on checking the address of the IDT. This approach fails to detect qemu. Below, furthermost is a qemu machine; evanescence is a "bare-metal" AMD K6-2:

piranha@furthermost$ ./redpill
idt base: 0xc02bd000
Not in Matrix.

piranha@evanescence$ ./redpill
idt base: 0xc03b8000
Not in Matrix.

The IDT address that qemu reports doesn't match the signature of a VM. I should imagine this address could be modified to return the same result as my K6-2 does.

The emulator has complete control over the guest environment. Complete. Control. Including completely spoofing the hardware of the real host system.

This shouldn't be shocking.

I'd also like you to qualify or expound on your allegations. It's not exactly clear; what does Intel or AMD stand to gain from undetectable rootkits?

I haven't read about it in detail yet, but from what I've gathered the virtualized OS does not have permission to call the virtualization operations. Thus you should be able to detect if the OS is virtualized by trying to call one of those functions.

There might also be some flags you can read, dunno.

There are a handful of processor instructions which behave differently under virtualization without causing a privilege fault. Not causing a privilege fault is crucial, because that would allow a malicious hypervisor to "step in" and hide itself. Even if the malicious hypervisor patches the host OS kernel and standard apps so that the OS cannot itself detect virtualization, it should be possible to load a "detector" application which uses these instructions to detect the problem. Of course, an effective implementation of such a "detector" utility would depend on the sophistication of the malicious hypervisor's countermeasures. The basic idea is presented in a paper from Rutkowska herself, aptly named "Red Pill".

- T