Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Sunday August 20 2017, @12:07PM   Printer-friendly
from the TLA-Approved? dept.

Submitted via IRC for TheMightyBuzzard

Since the launch of AMD Ryzen, a small piece of hardware that handles basic memory initialization as well as many security functions has been the center of some controversy. Called the Platform Security Processor (the "PSP" for short) it is essentially an arm core with complete access to the entire system. Its actions can be considered "above root" level and are for the most part invisible to the OS. It is similar in this regard to Intel's Management Engine, but is in some ways even more powerful.

Why is this a bad thing? Well, let's play a theoretical. What happens if a bug is discovered in the PSP, and malware takes control of it? How would you remove it (Answer: you couldn't). How would you know you needed to remove it? (answer, unless it made itself obvious, you also wouldn't). This scenario is obviously not a good one, and is a concern for many who asked AMD to open-source the PSPs code for general community auditing.

Bit late to the reporting but we haven't covered it yet, so here it is. And I was so looking forward to a new desktop too. Guess this one will have to stay alive until ARM becomes a viable replacement.

Source: https://www.techpowerup.com/235313/amd-confirms-its-platform-security-processor-code-will-remain-closed-source

Previous:
The Intel Management Engine, and How it Stops Screenshots
Intel x86 Considered Harmful
Of Intel's Hardware Rootkit
Intel Management Engine Partially Defeated
EFF: Intel's Management Engine is a Security Hazard
Malware uses Intel AMT feature to steal data, avoid firewalls


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: 1, Interesting) by Anonymous Coward on Sunday August 20 2017, @02:07PM (9 children)

    by Anonymous Coward on Sunday August 20 2017, @02:07PM (#556679)

    The code in question must include a driver of sorts for the onboard ethernet. So disable that and get an ethernet card that uses a different chip. This has not been tested but "should work". Can anyone show how this wouldn't work? Thanks.

    Starting Score:    0  points
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  

    Total Score:   1  
  • (Score: 3, Interesting) by jasassin on Sunday August 20 2017, @02:30PM (1 child)

    by jasassin (3566) <jasassin@gmail.com> on Sunday August 20 2017, @02:30PM (#556688) Homepage Journal

    It's hard to disable code that is built into hardware that cannot be disassembled without destroying the hardware itself. Disabling the ethernet section of the code (if that were possible) would make no difference because the chip has access to all memory and underlying hardware. The only way to be sure is to setup a firewall between the hardware and the internet and watch every packet that goes in and out. If the device starts sending packets to some address... then you know. Without something in the middle to tell you will be completely oblivious.

    Now, I am not a network programmer. I know there are layers below TCP/IP. Perhaps these clandestine transmissions could bypass detection from say a FreeBSD router with two ethernet cards. I do not know. If it does. I'd sure love to know how to send information across the internet at a level that low.

    --
    jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
    • (Score: 1, Informative) by Anonymous Coward on Monday August 21 2017, @03:25AM

      by Anonymous Coward on Monday August 21 2017, @03:25AM (#556862)

      TCP/UDP (inet routable) → IP (inet routable) → MAC (link local) → Ethernet (link local)

      OSI model [wikipedia.org]

      I'd sure love to know how to send information across the internet at a level that low.

      I don't believe this is possible, unless..,

      What's really going to bake your noodle later on is whether or not this code detects packets with the evil bit set, intercepts them, and prevents the OS network driver from even seeing them.

      Of course there's also things like hiding a payload in ICMP packets or whatnot. Perhaps sufficiently advanced stenography could hijack DNS queries without hiding them from the OS network driver and without alerting security researchers to the presence of stenography. I'm certain the NSA has thought about all of this before.

      It's too bad the NSA's mission cannot be changed from weakening information system security to building the most hardened information system security possible. (Something a bit easier to approach than selinux plz.)

  • (Score: 2) by Runaway1956 on Sunday August 20 2017, @02:33PM (6 children)

    by Runaway1956 (2926) Subscriber Badge on Sunday August 20 2017, @02:33PM (#556690) Journal

    Uhhhh - if the ARM has super-root, and you can't control the ARM, then how do you know that the network is disabled? For a wired network, just unplug it, right? But, how 'bout wireless? I suppose you could snip a wire to ensure the network is disabled . . .

    (yes, I took the liberty of replacing your "ethernet" with "network" for the purpose of pointing out that you don't know what's enabled or disabled if you can't see what the chip is doing)

    • (Score: 2) by jasassin on Sunday August 20 2017, @02:46PM (5 children)

      by jasassin (3566) <jasassin@gmail.com> on Sunday August 20 2017, @02:46PM (#556693) Homepage Journal

      From the article: Bit late to the reporting but we haven't covered it yet, so here it is. And I was so looking forward to a new desktop too. Guess this one will have to stay alive until ARM becomes a viable replacement.

      The fucking chip controlling the spy bullshit is ARM so he wants to wait for an ARM based CPU to solve his problems. I am confused. Help me out here Runaway1956. Please.

      --
      jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
      • (Score: 2) by Runaway1956 on Sunday August 20 2017, @03:57PM (4 children)

        by Runaway1956 (2926) Subscriber Badge on Sunday August 20 2017, @03:57PM (#556707) Journal

        I'm not quite certain, but it seems that ARM CPU's are open source, whereas this specific chip is not. Whether that be so or not, if he has an ARM CPU, then apparently he has access to the CPU's full functionality. Here, we have an ARM which is not accessible by the operating system. The OS only seens the x86 chip, and can't see the ARM. What would we even call this - a parallel installation of the hardware? Customer accessible CPU can do almost anything, the non-customer accessible CPU can do anything at all, in secret.

        All of that leads me to wonder why any other CPU can't be wired into a system to snoop on the system. Just build a dual CPU mainboard, let the customer have access to one side, and keep the other side for your own nefarious purposes. Isn't that exactly what is described here, except the second CPU is considerably less powerful than the customer-accessible chip?

        • (Score: 1, Insightful) by Anonymous Coward on Sunday August 20 2017, @04:06PM (3 children)

          by Anonymous Coward on Sunday August 20 2017, @04:06PM (#556710)

          All modern arm cpu's have a similar negative ring trustzone cpu. This is the only reason why you can buy hollywood movies and music on your android and iphone.

          • (Score: 2) by Runaway1956 on Sunday August 20 2017, @04:23PM (1 child)

            by Runaway1956 (2926) Subscriber Badge on Sunday August 20 2017, @04:23PM (#556712) Journal

            I wasn't aware of that. That makes the GP's quote even more interesting. Why is the author waiting for an ARM CPU then?

            • (Score: 1, Interesting) by Anonymous Coward on Sunday August 20 2017, @04:38PM

              by Anonymous Coward on Sunday August 20 2017, @04:38PM (#556714)

              Also *SOME* very few ARM SoCs are programmed with stage0 bootloaders (mostly for development boards) that allows you to program the trustzone ring/core yourself (TrustZone can be implemented either as time sharing inside of a shared ARM core, or using a dedicated ARM core with memory maps separating 'trusted' and 'untrusted' regions of memory and i/o devices.)

              A few may also allow a toggle switch which can enable/disable the firmware signing check, but in practice no manufacturer producing a non-dev board actually does that, since it might negatively affect DRM certification, the same I assume was the original reason for the Intel ME and then AMD PSP crap (but given the push for decryption capabilities by Congress, Intelligence Agencies, and Law Enforcement, I assume it has become a major cornerstone of their new encryption breakage strategies, since either pulling the keys out via the management cores or reducing the entropy of the RNG is a lot easier than trying to brute force the keys/'truly random' keys later on.

          • (Score: 0) by Anonymous Coward on Sunday August 20 2017, @10:38PM

            by Anonymous Coward on Sunday August 20 2017, @10:38PM (#556804)

            I would never buy hollywood videos or music on my phone