Stories
Slash Boxes
Comments

SoylentNews is people

posted by n1 on Monday May 15 2017, @07:04AM   Printer-friendly
from the phme dept.

Submitted via IRC for TheMightyBuzzard

Since 2008, most of Intel's chipsets have contained a tiny homunculus computer called the "Management Engine" (ME). The ME is a largely undocumented master controller for your CPU: it works with system firmware during boot and has direct access to system memory, the screen, keyboard, and network. All of the code inside the ME is secret, signed, and tightly controlled by Intel. Last week, vulnerabilities in the Active Management (AMT) module in some Management Engines have caused lots of machines with Intel CPUs to be disastrously vulnerable to remote and local attackers. While AMT can be disabled, there is presently no way to disable or limit the Management Engine in general. Intel urgently needs to provide one.

[...] EFF believes that Intel needs to provide a minimum level of transparency and user control of the Management Engines inside our computers, in order to prevent this cybersecurity disaster from recurring. Unless that happens, we are concerned that it may not be appropriate to use Intel CPUs in many kinds of critical infrastructure systems.

It's a crying shame the what the EFF says doesn't hold a whole lot of weight.

Source: The Electronic Frontier Foundation


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Monday May 15 2017, @03:12PM (1 child)

    by Anonymous Coward on Monday May 15 2017, @03:12PM (#510048)

    i believe the alternative is to be non standard, non x86 and to have several layers of defense running on separate hardware platform cross-verifying everything... Perfection would be to have custom everything, built by trustworthy entities. But perfection is unattainable and i'm a poor scrub.

    My next box will be 20-200 single board ARM computers and a few beefy x86 nodes with GPU's, most likely nvidia cos CUDA. Im thinking of using some of the boards to access other boards through some kind of DMA, and monitor memory for unusual patterns of activity and modifications, checksum the fuck out of it, compare to last known good state, if not revert etc. Do same thing through Thundebolt to x86 nodes? Some other boards will monitor ethernet for same kind of anomalies, maybe i can use ML to train a model or something... Maybe do weird stuff, like tunnel tcp/ip over HDMI or I2C to the x86 boxes, and place them in faraday cage, nobody expects that...? Maybe setup a SDR to detect, remix and broadcast em noise from the computer? It's a long term DIY project.

    Criticism/suggestions would be appreciated.

  • (Score: 2) by kaszz on Monday May 15 2017, @04:48PM

    by kaszz (4211) on Monday May 15 2017, @04:48PM (#510103) Journal

    Non standard, non x86 is good but also requires a lot of replication work (compiling and setup).

    PCI, Firewire, PCMCIA, PC Card, ExpressCard and Thunderbolt all support direct DMA without CPU initiation, just a tip. Which would enable you to verify contents. But don't trust the computer to present you with the correct data through DMA either. Another hint is "lost clock cycles" or SMI# pin activation.

    As for network. You can probably fool the management engine by rewriting the PCI registers into that the NIC really.. is a joystick device. Then just modify the network driver to interpretate that code as a NIC. The result is hopefully that whenever these backdoors wants to phone-home. There is no network. Another level is to leave the OS without network and have your application rewritten to communicate using other means. It could be as simple as running the mailer SMTP chat directly over asynchronous RS-232.

    Even better yet is to ditch all chips that you can't certify is alright.