Slashdot Mirror


Thunderbolt Rootkit Vector

New submitter Holi sends this news from PC World: Attackers can infect MacBook computers with highly persistent boot rootkits by connecting malicious devices to them over the Thunderbolt interface. The attack, dubbed Thunderstrike, installs malicious code in a MacBook's boot ROM (read-only memory), which is stored in a chip on the motherboard. It was devised by a security researcher named Trammell Hudson based on a two-year old vulnerability and will be demonstrated next week at the 31st Chaos Communication Congress in Hamburg.

163 comments

  1. In other news... by Anonymous Coward · · Score: 1, Insightful

    An attacker with physical access to the target is usually a bad thing (tm),

    1. Re:In other news... by mandark1967 · · Score: 1

      Definitely. At that point you probably shouldn't call him "hacker". You should refer to him using his proper moniker, "Agent"

      --
      Sig Follows: "Suppose you were an idiot. And suppose you were a member of Congress. But I repeat myself." -- Mark Twain
    2. Re:In other news... by __aaclcg7560 · · Score: 1

      A "bad actor" would have an agent.

    3. Re:In other news... by Fwipp · · Score: 3, Interesting

      But when all it requires is connecting an arbitrary malicious Thunderbolt device - a root-kit could be installed when you dock your computer, or connect to a monitor or ethernet/firewire adapter, or even a mouse.

      Yes, "mission-critical" security systems should already be physically isolated. But not everything is physically isolated (work laptops, for instance), and this class of attack makes it easier to covertly compromise devices, even while in plain view. Would all of your coworkers object to someone plugging in a mouse on their laptop?

    4. Re:In other news... by Anonymous Coward · · Score: 0

      Except a reload of the OS usually solves the problem, not so much now.

    5. Re:In other news... by Bengie · · Score: 1

      IOMMU can already control DMA access. Secure boot can restrict what images can boot, the images can restrict what devices have DMA access, and after granting DMA access, what memory ranges they have access to. We already have the tech to handle this situation, it's just a lack of implementation or a poor implementation.

    6. Re:In other news... by danceswithtrees · · Score: 2

      ... isn't, but I hear his agent is.

      Tell your friend Veronica
      It's time to celebrate Chanukah.

    7. Re:In other news... by fuzzyfuzzyfungus · · Score: 3, Interesting

      Plus, thunderbolt daisy-chains, so (if you are handy with rework tools or Intel ever gets the stick out of their ass about selling the chips) the malicious device could either be a (subverted) normal looking peripheral or a surprisingly small lump lurking within a thunderbolt cable or somewhere within the chain.

      The proof of concept is probably a big hairy bundle of prototype that would get you arrested if you brought it to an airport; but a slightly more polished variant could be squirreled away in quite a few places. The volume and power required to implement an entire single-purpose attacker device is already fairly small, getting into "eh, probably just one of those EMI ferrite things" territory, and not going to get any larger; plus the options available in either embedding the attacker device in the case of a legitimate device or modifying a legitimate device's firmware.

      The truly paranoid user might not be vulnerable; but few users are paranoid enough to qualify.

    8. Re:In other news... by fuzzyfuzzyfungus · · Score: 4, Insightful

      I'm frankly surprised to hear that Apple still manufactures a device that will boot after you tinker with its boot ROM. The notion that a device that is, for most purposes, right on the PCIe bus can scribble all over the place isn't exactly a shock; but it doesn't seem much like Apple to build hardware that would still boot if the cryptographic signatures didn't check out.

    9. Re:In other news... by Anonymous Coward · · Score: 0

      Google "software bug".

    10. Re:In other news... by Anonymous Coward · · Score: 0

      When has reloading the OS ever helped for boot rom rootkits? Yeah, NEVER.

    11. Re:In other news... by spire3661 · · Score: 2

      Chernobyl virus victim checking in. $450 in hardware to fix that one.....

      --
      Good-bye
    12. Re:In other news... by Anonymous Coward · · Score: 0

      Except a reload of the OS usually solves the problem, not so much now.

      Instead all you'll need is a malicious device infected with the original boot ROM code.

    13. Re:In other news... by Anonymous Coward · · Score: 0

      I'm sure a rogue PCI card could do the same thing, and maybe even ExpressCard. Because that's basically what Thunderbolt is, a PCI-E slot, with DisplayPort support added in. And if I recall correctly, Firewire potentially had a similar potential problem with DMA.

    14. Re:In other news... by complete+loony · · Score: 1

      And what checks that signature? Code running from ROM perhaps?

      --
      09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
    15. Re:In other news... by sumdumass · · Score: 4, Interesting

      While this is true, the attacker does not need physical access for this. All they need is access to an innocent user who can be convinced to plug something in.

      The FBI and secret service demonstrated this type of attack back in the early 2000s. They dropped usb drives near banks night drop boxes and front doors that pinged a server with the local ip and machine name and wrote a file locally when plugged in with the autorun on. Something like 70% or so pinged. People where plugging them in to try to figure out who's they were to return them.

      Its pretty easy to convince someone to plug something in.

    16. Re:In other news... by sjames · · Score: 0

      Just leave a mouse out of the package laying around in a targeted office. Eventually, someone will need or want the mouse and plug it in for you.

      It's less sure and could take a while compared to plugging it in yourself, but it makes the person who gets infected want to keep quiet and even if they figure out where the mouse came from (unlikely), you have plausible deniability.

    17. Re:In other news... by Anonymous Coward · · Score: 0

      Well, yes, if it's truly ROM(*), then ROM code checking the signature isn't such a goofy idea. Now, if physical access to the platform is available, and the ROM is an external IC, then the signature check might not be too hard to subvert.

      (*) (flash isn't really ROM, it's non-volatile, but that's not the same as ROM)

    18. Re:In other news... by petermgreen · · Score: 1

      that's basically what Thunderbolt is, a PCI-E slot, with DisplayPort support added in.

      Exactly. Putting display output and external PCIe on the same port is convenient when hooking stuff up in your own home/office but it leads to a new exploit vector.

      People plug conference room/lecture theatre/etc projectors and associated adaptors into their laptops all the time and such rooms are generally low security. Build a malicious thunderbolt device that looks like a mini displayport to VGA adaptor and leave it next to the VGA cable from the projector and it's very likely to get plugged in.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    19. Re:In other news... by Dog-Cow · · Score: 2

      No one uses thunderbolt for mice.

    20. Re:In other news... by Anonymous Coward · · Score: 0

      People will plug the mouse in wherever it fits.

    21. Re:In other news... by Anonymous Coward · · Score: 0

      "Its pretty easy to convince someone to plug something in."
      In my ex-girlfriends case, a couple of mojitas is all it takes.

    22. Re:In other news... by rvw · · Score: 1

      No one uses thunderbolt for mice.

      People need a mouse, see it laying around, try to plug it in the USB port, it doesn't fit, they see another port, it fits, the mouse doesn't work. Will they throw it away? no probably not - they will put it back. Then: repeat scenario!

    23. Re:In other news... by benjymouse · · Score: 1

      And what checks that signature? Code running from ROM perhaps?

      In UEFI secure boot firmware can only be updated by a *signed* package. A thunderbolt attack would only be able to *request* a change to firmware, but it would have been rejected had Apple implemented secure boot.

      --
      Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
    24. Re:In other news... by 3.5+stripes · · Score: 1

      Won't work, because the hacker actually bother to sign his ROM, which is what apple SHOULD have done.

      --


      He tried to kill me with a forklift!
    25. Re:In other news... by Holi · · Score: 1

      Apple does sign their firmware updates.
      "Firmware updates are supposed to be signed, but the vulnerability exploited by this attack allows that mechanism to be bypassed."

      --
      Sorry, teleporters just kill you and then make a copy. A perfect, soul-less copy.
  2. uh - by design? by Nerrd · · Score: 4, Insightful

    It shouldn't surprise anybody that a malicious PCI-E card can access a system.

    1. Re:uh - by design? by _xeno_ · · Score: 3, Informative

      Well, yes, if you can rip open the computer case and install new hardware, you have complete control over the hardware and that's to be expected.

      Thunderbolt is more like USB to the user - it's a thing you use to connect untrusted devices to your system. You wouldn't expect that plugging in a USB thumbdrive would magically own your system (well, maybe you should, because it's happened in the past, but I think it's fair to say that it shouldn't). You'd think that plugging in a random Thunderbolt device would be designed to be safe. Apparently not: apparently Thunderbolt is unsafe by design.

      The one mitigating factor is that literally no one uses Thunderbolt for anything, so it's not like anyone's likely to be coming across random compromised Thunderbolt devices. Discovering a Thunderbolt device at all would be out of the ordinary.

      --
      You are in a maze of twisty little relative jumps, all alike.
    2. Re:uh - by design? by darkain · · Score: 4, Insightful

      DisplayPort monitor pre-infected with malware?

    3. Re:uh - by design? by Anonymous Coward · · Score: 0, Funny

      By your own admittance (and a touch of commonsense) PCIe is also unsafe by design as you're more likely to find an end user installing a new PCIe card than you are a thunderbolt device... USB as well.
       
      But I know, I know... this is Apple... let's beat on them even though you've proven yourself why hardware of any ilk should be untrusted.

    4. Re:uh - by design? by maccodemonkey · · Score: 3, Informative

      Thunderbolt is more like USB to the user - it's a thing you use to connect untrusted devices to your system. You wouldn't expect that plugging in a USB thumbdrive would magically own your system (well, maybe you should, because it's happened in the past, but I think it's fair to say that it shouldn't). You'd think that plugging in a random Thunderbolt device would be designed to be safe. Apparently not: apparently Thunderbolt is unsafe by design.

      USB 3.0 has this exact same feature (DMA), so yes, yes you should expect a USB thumb drive to be able to do this.

    5. Re:uh - by design? by Anonymous Coward · · Score: 0

      " You wouldn't expect that plugging in a USB thumbdrive would magically own your system " - Unless you know ANYTHING about security, that is.

    6. Re:uh - by design? by jeffb+(2.718) · · Score: 4, Insightful

      Thunderbolt is more like USB to the user - it's a thing you use to connect untrusted devices to your system.

      Thunderbolt is more like PCIe to the system -- it's a thing you use to connect trusted devices to your system. In fact, it is PCIe, along with DisplayPort.

      The one mitigating factor is that, while there are Thunderbolt devices out there, users are less likely to find one lying in the company parking lot and decide "durr, let me plug this into my work computer and see what's on it". That seems to be a pretty effective delivery method for hostile USB devices.

    7. Re:uh - by design? by Holi · · Score: 5, Informative

      It can. See BadUSB.

      --
      Sorry, teleporters just kill you and then make a copy. A perfect, soul-less copy.
    8. Re:uh - by design? by Anonymous Coward · · Score: 0

      There are adapters that provide external PCIe to workstations.

    9. Re:uh - by design? by Anonymous Coward · · Score: 0

      If you buy an USB flash drive by a trusted brand via a reputable supply chain, in practice there is no risk that it would own your system.

      It all boils down to trust really. In the same way we can expect that the local supermarket does not sell us poisonous food, for example.

    10. Re:uh - by design? by Anonymous Coward · · Score: 2, Insightful

      It doesn't even have to be a whole monitor. An innocent looking cable would suffice. Apple's own cables already contain microcontrollers.

    11. Re:uh - by design? by I4ko · · Score: 2

      Which is exactly what FireWire was vulnerable to like.. what.. 7 years ago. This is nothing novel.

    12. Re:uh - by design? by Anonymous Coward · · Score: 0

      Except (that assuming you're ignorant about USB) the more you know about security, the more you assume USB can't possibly be dangerous, since nobody would be so stupid as to build "must offer unrestricted DMA to unauthenticated strangers" into an external interface! It's sort of like how, if you know anything about security, you just assume that being compatible with the next-higher speed of ethernet, doesn't necessitate sending your root password out into the ether.

      Knowing about security isn't enough. People need to learn about systemic deliberate insecurity.

    13. Re:uh - by design? by Anonymous Coward · · Score: 0

      It shouldn't surprise anybody that a malicious PCI-E card can access a system.

      The IOMMU is supposed to prevent things like this but apparently only shields the RAM rather than the bus bridges.

      You would expect the Thunderbolt bridge to filter the signals so it can only communicate with the CPU rather than letting everything through but apparently that would require a competent design.

    14. Re:uh - by design? by aitikin · · Score: 3, Informative

      The one mitigating factor is that literally no one uses Thunderbolt for anything, so it's not like anyone's likely to be coming across random compromised Thunderbolt devices. Discovering a Thunderbolt device at all would be out of the ordinary.

      You're obviously not in the pro audio world.

      --
      "Don't meddle in the affairs of a patent dragon, for thou art tasty and good with ketchup." ~ohcrapitssteve
    15. Re: uh - by design? by Anonymous Coward · · Score: 0

      Travelers would be wise to never plug their devices into random USB ports in airports. You don't know if it's a charger or computer providing the ports.

    16. Re:uh - by design? by fuzzyfuzzyfungus · · Score: 2

      It has to be unsafe by design. How else can Thunderbolt be even more insanely great than Firewire's "Hey, sure, here's DMA access to the bottom 4GB of my memory space! Don't do anything naughty or nothing, ok?" security model?

    17. Re:uh - by design? by amorsen · · Score: 2

      USB 3.0 has this exact same feature (DMA), so yes, yes you should expect a USB thumb drive to be able to do this.

      Ethernet controllers work by DMA, yet they do not offer random access to anyone who plugs anything into the bus. There is no inherent reason why DMA means full access.

      Thunderbolt and Firewire are different, in that they are "controllerless". They are simply PCI bridges.

      --
      Finally! A year of moderation! Ready for 2019?
    18. Re:uh - by design? by Anonymous Coward · · Score: 0

      You wouldn't expect that plugging in a USB thumbdrive would magically own your system (well, maybe you should, because it's happened in the past, but I think it's fair to say that it shouldn't)

      How about an "infected" mouse?

      http://www.infoworld.com/article/2622699/insider-threats/yes--even-a-mouse-can-infect-your-network.html
      http://www.extremetech.com/extreme/191467-badusb-returns-hackers-publish-code-that-could-infect-millions-of-usb-devices

    19. Re:uh - by design? by Anonymous Coward · · Score: 0

      So in the pro audio world you find stuff hanging out in the parking lot?

    20. Re: uh - by design? by spire3661 · · Score: 1

      People will no matter how many times we tell them not to. WE have been telling people since the early 90s about physical computer security and only those that get bitten actually do anything to prevent it.

      --
      Good-bye
    21. Re:uh - by design? by AmiMoJo · · Score: 3, Insightful

      USB 3.0's DMA is not the same as Thunderbolt's. With USB the host controller configures itself with limited DMA access to a RAM buffer, and then the USB device can only access that buffer by setting up transfers within the USB spec. In fact it can't even specify the address within the buffer or anything like that, the controller handles it all. It's closer to a NIC that supports DMA - it doesn't mean that any device on your network has full access to your computer's RAM.

      Thunderbolt is rather different, because the devices are basically PCI-E cards with a Thunderbolt transceiver bolted on. As such they can do anything that a PCI-E card can do, including accessing all RAM. PC Card devices have the same issue, and so does Firewire. It's a serious issue and tools that exploit it have been available for a while, both open source and commercial. For example: http://www.breaknenter.org/pro...

      The BadUSB attack relies on either exploiting bugs in the USB driver or emulating something like a keyboard and typing commands into a terminal. It's bad, but not nearly as bad as having complete, unfettered access to RAM by design. For example, a locked computer or server that isn't logged in locally is unlikely to be affected by BadUSB because it can't know the login details, but with Thunderbolt you have total access.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    22. Re:uh - by design? by AmiMoJo · · Score: 1

      It's a concern to anyone who travels with a laptop. With Thunderbolt, PC Card or Firewire your laptop is vulnerable even if you lock it. With BadUSB there isn't much it can do if the machine is locked. If customs or some LEA decides they want in they can get everything, including your encryption keys (you did encrypt and use a VPN, right?)

      Hopefully you can somehow disable it to mitigate this attack. I don't know about Macs but most PC UEFI BIOSes allow it to be turned off, along with Firewire and PC Card.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    23. Re:uh - by design? by NJRoadfan · · Score: 1

      The one mitigating factor is that literally no one uses Thunderbolt for anything, so it's not like anyone's likely to be coming across random compromised Thunderbolt devices. Discovering a Thunderbolt device at all would be out of the ordinary.

      There was a brief moment that companies released laptops with Thunderbolt (mostly Ivy Bridge platforms). Now its a rare feature outside of Apple's laptops. Microsoft didn't put Thunderbolt into the Surface 3 because of the DMA security concerns and "InstantGo" devices (source: http://technet.microsoft.com/e... )

    24. Re:uh - by design? by Anonymous Coward · · Score: 0

      Except none of those bugs can rewrite a Boot ROM... It might inconvenience you until you unplug it (in the case of the network emulation) and maybe just a system restore / virus scan to restore a working system...

      If you fuck a Boot ROM, good luck getting it to work again.

    25. Re:uh - by design? by Anonymous Coward · · Score: 0

      People haven't used AutoPlay in some time now.

      Plugging a USB drive into a Windows machine does nothing without user intervention. (clicking to run something)

    26. Re:uh - by design? by Barny · · Score: 1

      The whole point of Thunderbolt (and Firewire before it) was that they didn't put any load on the CPU at all, they would communicate directly to ram, reading and writing data without any load on the very limited resource that is the processor. Of course, there really should have been a boot-time restriction of what memory the bridge has access to, but I guess that would have been too much for the programmers.

      --
      ...
      /me sighs
    27. Re:uh - by design? by _xeno_ · · Score: 1

      I don't think Mac OS X even has a user-accessible BIOS. I know there's a "special" key combo you can hit to reset whatever they call their equivalent of CMOS settings (it's either NVRAM or PRAM and I have no clue what the difference is or why it matters). (I know this because there's another cute Mac bug that frequently hits my work MacBook where it will forget it has a built-in display because I turned it off while connected to a monitor, so you have to reset it to factory defaults to get it to realize "maybe I should turn on the laptop display.")

      Ah, what the heck, I have the sucker sitting right next to me, let's see if you can disable it in ... "thu: no items." Oh.

      (And I checked, you cannot access the EFI shell at all on new Macs. So even if it were possible to turn Thunderbolt off there, you can't access it anyway.)

      --
      You are in a maze of twisty little relative jumps, all alike.
    28. Re:uh - by design? by aitikin · · Score: 1

      So in the pro audio world you find stuff hanging out in the parking lot?

      Depending on who you are. My old boss literally got a Fairchild compressor from someone's backyard. Another friend got a 2" tape machine from someone's parking lot (next to the dumpster).

      But, to the point, GP said nothing about a parking lot. "Discovering a Thunderbolt device at all..." does not mean finding it hanging out in the parking lot, it means that, the tech is oh so rare to begin with, that it's nearly impossible to find period.

      --
      "Don't meddle in the affairs of a patent dragon, for thou art tasty and good with ketchup." ~ohcrapitssteve
    29. Re:uh - by design? by Anonymous Coward · · Score: 1

      It doesn't even have to be a whole monitor. An innocent looking cable would suffice. Apple's own cables already contain microcontrollers.

      Indeed, it seems that the micro controller is only an infection vector, which begs the question if this infection vector would take the form of a device added to the malicious peripheral or a peripheral that had been flashed with a malicious firmware update.

      it is insidious, like the character Noonian Soong asserted in the Star Trek TNG Episode "Brothers" about the only difference between Data and Lore being "a bit of programming."

      It begs the question of a chain of custody between manufacturer and end user being inherently insecure.

      I for one will be checking my thunderbolt devices with a bus pirate now..

      http://store.hackaday.com/products/buspirate-v3-6-thm180c4m

    30. Re:uh - by design? by Anonymous Coward · · Score: 0

      ROM. Read Only Memory. Why on earth is their ROM rewritable in the first place?!

    31. Re:uh - by design? by Anonymous Coward · · Score: 1

      Except none of those bugs can rewrite a Boot ROM... It might inconvenience you until you unplug it (in the case of the network emulation) and maybe just a system restore / virus scan to restore a working system...

      If you fuck a Boot ROM, good luck getting it to work again.

      I have on several occasions recovered a working system from an infected boot rom, but it was not easy nor was it straightforward in any sense of the word. Agreed however that if a boot rom is infected most computer techs without a high degree of sophistication and skills will not know how to proceed.

      This is an example of what I refer to as "A nearly perfect hack" (analogous to the concept of the perfect murder, leaving little to no evidence allowing the individual committing it to get away Scott free.) In this case you have a low level hardware component as an infection vector and the infection could potentially compromise the information security of the entire system without giving itself away to a malware scanner or virus detection. Even if some of the behavior of the infected system matches a pattern similar to a known root kit or virus or malware on secondary storage, detection and cleaning is confounded by the fact that the infection can re-occur and detection can be confounded by one not being able to trust the data integrity of the machine at runtime in such an infected system. The main takeaway is that the root infection is not where one would normally look for it, on secondary storage or in RAM. Fixing such a thing, in a nutshell, requires being able to examine the system component by component at the hardware level on a non running system which is a somewhat complicated and more involved process than a malware or virus removal or giving up and just re-imaging the system. There are tools to carry out such diagnostics and repairs but it is more in the realm of a digital electronics hardware expert than in the skill set of the average IT Tech.

    32. Re:uh - by design? by dgatwood · · Score: 2

      Thunderbolt is rather different, because the devices are basically PCI-E cards with a Thunderbolt transceiver bolted on. As such they can do anything that a PCI-E card can do, including accessing all RAM. PC Card devices have the same issue, and so does Firewire. It's a serious issue and tools that exploit it have been available for a while, both open source and commercial.

      Here's what I don't get. Back when the G5 came out, Apple used a custom piece of hardware called DART to create a boundary between the I/O address space used by PCI devices and the physical address space used by RAM. It required device drivers to explicitly configure mappings before a PCI device could scribble on RAM, and limited those devices to scribbling over the ranges specified by the OS. That hardware went away with the Intel transition, of course, but most of the newer 64-bit Intel hardware has a feature called VT-d that does essentially the same thing. AFAIK, the 64-bit OS X kernel uses that functionality by default if the hardware supports it, so all of those tools should be completely non-functional on recent Macs running Mountain Lion and later. And I think I remember reading somewhere that Thunderbolt controllers contain an address translation table as well.

      With that in mind, how is this Thunderbolt device somehow gaining the ability to tickle hardware that probably doesn't live on the PCI bus, on the opposite side of the Thunderbolt controller, at a location that wasn't explicitly configured for DMA by a device driver? Does it involve rebooting the machine and exploiting a driver bug in EFI?

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    33. Re:uh - by design? by dgatwood · · Score: 1

      The whole point of requiring every driver to call the prepare method on an IOMemoryDescriptor object before telling a device to do DMA and calling the matching complete method when the I/O is done is so that the OS can create and tear down mappings in various IOMMU hardware to protect the system as a whole from buggy devices (and particularly those that don't understand 64-bit address spaces). If that isn't happening, I'd argue that it is a kernel bug, and given the security implications, a pretty serious one.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    34. Re:uh - by design? by dgatwood · · Score: 1

      I am, of course, assuming that Thunderbolt controllers contain an IOMMU, but given that it has to function as a nontransparent PCI bridge when attached between two computers, that should be a safe assumption.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    35. Re:uh - by design? by fustakrakich · · Score: 2, Insightful

      EPROM! Otherwise the story makes no sense... If you can write to ROM (more than once), clearly it's not ROM.

      --
      “He’s not deformed, he’s just drunk!”
    36. Re:uh - by design? by Anonymous Coward · · Score: 0

      Mid-range laptop CPUs are good enough for gaming, but laptops can't possibly have a decent GPU, because those start at 60W TDP. But if there was an external PCIe interface, it would be possible to buy a mid-range laptop, and a GPU, and connect to your GPU when you want to play.

      That means Intel doesn't sell the super high end laptop CPUs with halfway decent integrated GPUs, but instead has driven a purchase to AMD or nVidia. It also means Intel doesn't sell you a desktop CPU.

      So they dumped their external PCIe as quickly as possible.

    37. Re:uh - by design? by Khyber · · Score: 1

      "You're obviously not in the pro audio world."

      You obviously aren't either. Thunderbolt's way overkill for bandwidth requirements, and most onboard sound systems in a typical desktop handle proper mixer outputs and inputs just fine, with pretty much professional noise floors. I get more noise from my guitar amp and distortion pedal than I get recording the line-in with nothing attached/everything turned off.

      Pretty easy setup. Added bonus, you can't infect through a line-in signal that I'm aware of!

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    38. Re: uh - by design? by Anonymous Coward · · Score: 0

      NetBIOS
      Sorry if repeated. Http no reply...

    39. Re:uh - by design? by drkstr1 · · Score: 1

      I have on several occasions recovered a working system from an infected boot rom, but it was not easy nor was it straightforward in any sense of the word. Agreed however that if a boot rom is infected most computer techs without a high degree of sophistication and skills will not know how to proceed.

      This is an example of what I refer to as "A nearly perfect hack" (analogous to the concept of the perfect murder, leaving little to no evidence allowing the individual committing it to get away Scott free.) In this case you have a low level hardware component as an infection vector and the infection could potentially compromise the information security of the entire system without giving itself away to a malware scanner or virus detection. Even if some of the behavior of the infected system matches a pattern similar to a known root kit or virus or malware on secondary storage, detection and cleaning is confounded by the fact that the infection can re-occur and detection can be confounded by one not being able to trust the data integrity of the machine at runtime in such an infected system. The main takeaway is that the root infection is not where one would normally look for it, on secondary storage or in RAM. Fixing such a thing, in a nutshell, requires being able to examine the system component by component at the hardware level on a non running system which is a somewhat complicated and more involved process than a malware or virus removal or giving up and just re-imaging the system. There are tools to carry out such diagnostics and repairs but it is more in the realm of a digital electronics hardware expert than in the skill set of the average IT Tech.

      Your first paragraph had me interested. Your second made me realize you're full of hot air. Eg. Long, overly complex, and unnecessary vocabulary. I presume to hide the fact that you offer no real insight on solving the problem.

      I'm not a hardware guy, so I would I appreciate if a real expert would chime in here and ease my curiosity.

      --
      Fanboy Status: Apache Flex, C#, Eclipse, KDE, Pirate Party, Ron Paul, Slackware, Windows 7
    40. Re:uh - by design? by michelcolman · · Score: 1

      Yes, this is really only a problem for those who download and 3D-print USB devices from the Pirate Bay. Honest people who pay for their stuff will not be affected.

    41. Re:uh - by design? by michelcolman · · Score: 1

      That's not true, it's perfectly possible to access EFI and pretty much anything else. All you need is a rogue Thunderbolt device, and...

    42. Re:uh - by design? by AmiMoJo · · Score: 2

      VT-d is used for something else, basically allowing PCI-E devices to access RAM without needing to worry about a >32 bit address space. While it might be possible to prevent this attack with it, that isn't how it is currently used. If a fix can be implemented it might break a lot of drivers.

      The attack is so nasty because when you can overwrite random bits of memory you can modify executable code on the fly. Address randomization doesn't help, you can simply search the entire address space for some suitable entry point.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    43. Re:uh - by design? by HJED · · Score: 1

      PCIE cards are a tad more complicated to install then thunderbolt devices... (and more scary for the average user)

      --
      null
    44. Re: uh - by design? by HJED · · Score: 1

      Which is why most android phones require you to enable usb data access every time you connect.

      --
      null
    45. Re:uh - by design? by mysidia · · Score: 1

      Thunderbolt is more like USB to the user - it's a thing you use to connect untrusted devices to your system.

      No. USB is not safe either. Don't plug untrusted devices into your system's I/O ports, period.

      USB, Firewire, eSATA, SAS, and Thunderbolt do not have a security model.

      Thunderbolt just happens to have more capabilities since there is direct access to the PCI bus, and this is also where the greater performance comes in.

      With greater capabilities and access comes greater possibilities of abuse from untrusted components. Including the possibility of malicious option ROMs and malicious access to other hardware devices attached to the bus.

    46. Re:uh - by design? by kernel_user · · Score: 0

      No it has never happened. http://en.wikipedia.org/wiki/C...

    47. Re:uh - by design? by Anonymous Coward · · Score: 0

      Actually a ROM is not writable once either. ROMs are created using a photolithographic process for high volume production.
      PROMs are writable once, The 'P' stands for programable.

    48. Re:uh - by design? by meustrus · · Score: 1

      I see no reason to disbelieve an AC claiming to have fixed the problem. The second paragraph doesn't show he's wrong; by explaining in detail why it's so hard to fix (without explaining in any detail how to fix it), it shows that he likes being the only person he knows who can fix it.

      --
      I sometimes ask revealing, often ignorant-seeming questions. Maybe they're harder to answer than you think.
    49. Re:uh - by design? by Anonymous Coward · · Score: 0

      Still not sure how one can write to ROM...

    50. Re:uh - by design? by megabeck42 · · Score: 1

      I agree. I call bullshit.

      What he describes is plausible, especially if the flash is socketed. But, not bloody likely. Considering that this malware would have to add itself to the existing flash image as an option rom or by infecting and rewriting part of the bios code and then writing that back to the rom.. Unless this was a targeted attack, the malware author would have to work out logic for each one of the major base BIOSes in use - phoenix, award, dell, lenovo, etc to be able to infect them. This is ignoring lots of machines which prevent either prevent rewriting the flash without physical access or require the new system image to be signed. Also, keep in mind that testing this ahead of time is rather difficult given the wide range of different BIOSes on different motherboards, etc. any unexpected bug could render an infected machine unbootable. So, hell of a lot of work for the malware/virus author with quite a lot of risk for failure.. especially when there's a lot of lower hanging fruit.

      I don't doubt that it's happened to someone out there.

      Also, I do believe this is one of the scenarios Intel TXT is for.

      --
      fnord.
    51. Re:uh - by design? by iluvcapra · · Score: 1

      Avid's entry level Pro Tools HD system is thunderbolt-based. I know at least a dozen people that use it for professional work every day. This is the industry-standard equipment, particularly if you're not going to buy cards.

      USB can do bandwidth for a few audio channels but you need PCIe or Thunderbolt if you want to have a few hundred tracks and still have under 5 milliseconds latency, and you generally need that if you're tracking or comping.

      --
      Don't blame me, I voted for Baltar.
    52. Re:uh - by design? by Anonymous Coward · · Score: 0

      The one mitigating factor is that literally no one uses Thunderbolt for anything

      Ah, the same "security" that Macs and other niche platforms have been hiding behind for decades...

    53. Re:uh - by design? by drkstr1 · · Score: 1

      I didn't claim it was wrong, only that it was useless and full of hot air ...although I may be using that expression wrong... I usually use it for the occasional "know it all" techies I come across who like to use big words to confuse the shit out of non-techies, so they can hide the fact they are a know-nothing hack. Maybe this is not the case for AC, but all signs point to yes.

      --
      Fanboy Status: Apache Flex, C#, Eclipse, KDE, Pirate Party, Ron Paul, Slackware, Windows 7
    54. Re:uh - by design? by Khyber · · Score: 1

      "you need PCIe or Thunderbolt if you want to have a few hundred tracks and still have under 5 milliseconds latency"

      That's what a mixer board is for and even ASIO drivers don't provide sub 5ms latency. The only thing on this planet providing sub 5ms latency are direct connections from instrument to IEMs, and even then you have to deal with things like comb filtering.

      Yamaha has a good piece on this and I'd take their word well over Avid's, given Yamaha has been in this game FAR longer, starting with musical instruments back in 1887, versus Avid's 1984 starting date.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    55. Re:uh - by design? by iluvcapra · · Score: 1

      Yamaha's piece is marketing for their own software, Nuendo, which is meant to run on ASIO and they're trying to downplay its deficiencies for tracking.

      You seem to have heard of a mixing console, that's good, but a really common setup is to have 20 or 30 microphones coming into the analogue console, passing to Pro Tools, playing back with a few hundred channels of prerecords, getting down mixed in Pro Tools to 96 channels, and then those channels coming up on the console on the tape inputs. And the sound on the tape outputs still has to be tolerably in sync with the sound coming in on the microphones. This kind of situation happens all the time in music tracking.

      In any case, a lot of people don't even have mixing consoles anymore, all of the monitor mixes and mix down are done in the box, and mixing is done on a control surface like an Euphonics/Avid S6 or a Yamaha Rivage. The Yamaha article is state-of-the-art for 1996, we've moved on quite a bit since then -- unless you're Dave Grohl and you're making obnoxious documentaries apeing the Good Old Days (while strangely trying to have it both ways when Trent Reznor is on the screen). Consoles are history, because we have low-latency monitoring "in the box."

      Look, I'm a sound designer in Los Angeles, I've been doing it for 15 years, do you actually have any experience with digital audio? Or are you just a slashdotter who's working backwards from something you Googled about audio to first principles?

      --
      Don't blame me, I voted for Baltar.
    56. Re:uh - by design? by Khyber · · Score: 1

      Yea. I work in Riverside. Done audio and video work for groups such as The Neil Deal and other bands out in Studio City. I have plenty of experience with digital recording and multitracking/overdubbing, starting with Cool Edit back in the late 90s (and some MIDI/MOD/IT tracking.)

      Simple physics alone is going to dictate that sub 5ms latency is pretty much impossible without your cables being a foot long once you take all the signal pathways, processing overhead, etc. in a piece of hardware into account.

      Everything else is marketing.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    57. Re:uh - by design? by iluvcapra · · Score: 1

      I know your kind too well; luckily I know no one younger than 60 that actually goes around telling that you "need a console" for low-latency monitoring. Unless they're analogue purists or console fanboys -- you know, marketing.

      Simple physics alone is going to dictate that sub 5ms latency is pretty much impossible without your cables being a foot long once you take all the signal pathways, processing overhead, etc. in a piece of hardware into account.

      I am A BIT surprised that someone with so much experience would post a picture of a Mackie 1404 in a china hutch as an example of "pro audio," and would seem to be unaware of the fact that a foot is about 0.8 nanoseconds. Also you seem to be confused about the actual terms of the dispute: Thunderbolt can do low latency, USB cannot, while latency in the studio is an issue, the only question here is wether or not your DAWs inputs and outputs are in sync.

      --
      Don't blame me, I voted for Baltar.
    58. Re:uh - by design? by Khyber · · Score: 1

      Are you forgettingelectrical signals don't propagate at light speed? Bring that up a few more ns. Now toss in all your processing, etc in a digital solution.

      " Mackie 1404"

      Not eeeeeeven close, but at least you got the brand right. You're missing the digital /SPDIF and optical outputs on the back - I've timed this from the same equipment and different outputs. Digital adds latency like mad.

       

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    59. Re:uh - by design? by aitikin · · Score: 1

      I live in the pro audio world, almost at the bleeding edge of it I might add. What the other poster stated about sub 5ms latency is true. Get yourself an HDX system and test it out. Also, there's this, this, the entire Apollo line, and even an entry level interface that's Thunderbolt based.

      IMHO, nothing will compare to using a mixer, but that's for the functionality and quality. I would never pitch a Mackie as a decent recording system, live sound, sure, but, unless you've got an Onyx, it's crap for recording (and even then, just decent). A mixer to me is something like this. My interface is a Fireface 800 and I have 0 perceived latency (so long as I'm not sending anything into the DAW for processing on my cue mix, or merely playing back from the DAW and recording new tracks). To claim something as 0 latency would be incorrect for everything, there will be latency. To claim that the conversion process adds less than X ms of latency is what we're talking about, and the Thunderbolt stuff from MOTU (not even a stellar name in the industry) is leaps and bounds beyond my Fireface (it should be, my interface is 8 years old now), clocking in at sub 1ms at the hardware itself (seen in info note in the link above), with the Fireface being a respectable 5ms at the lowest.

      Long story short, if you're looking for the lowest latency and a professional setup, Thunderbolt or PCIe is king. If, as it seems from the photo you posted, you're working in a prosumer or entry level situation, than USB will suffice.

      (Other sources: I work in pro audio. A number of years of experience behind the board in both live and recording environments on everything from small projects to working with the likes of Bob Mintzer. Much of my knowledge comes from the real world.)

      --
      "Don't meddle in the affairs of a patent dragon, for thou art tasty and good with ketchup." ~ohcrapitssteve
    60. Re:uh - by design? by dgatwood · · Score: 1

      All drivers on OS X are already required to tell the operating system ahead of time that a device is about to DMA to memory. That's how that VT-d is able to configure the IOMMU hardware to allow those devices to access RAM without worrying about 64-bit address spaces. So the OS already knows precisely which pages of physical RAM should be accessible by PCIe devices using DMA. If other pages of RAM are accessible, that's a bug.

      Similarly, making the Thunderbolt controller's IOMMU mappings be driven by that part of the kernel should not break any drivers at all, by definition, because PCIe devices shouldn't be issuing DMA requests except at driver-preapproved locations. So AFAIK, the only way such a fix could break any device would be if that device was trying to do something really dangerous, like reprogramming one of the PCI bus bridges, or reflashing the computer's EFI firmware....

      I mean, I suppose that some drivers might be inadvertently configuring a mapping for a page of memory that also contains executable code or class instances (with function pointers), in which case fully fixing this would also require Apple to modify the IOMemoryDescriptor class to ensure that the DMA-enabled pages are whole pages owned by the descriptor, but that should still be pretty minor, and should result in only a modest amount of wired kernel memory bloat.

      In the worst case, such a change might require a CPU-driven copy-on-prepare and/or copy-on-complete to work around drivers that provide their own virtual addresses for a memory descriptor that aren't page-aligned, which would cause a big performance hit for those few drivers, but I'd expect most driver developers to quickly fix those design mistakes to eliminate the performance hit. (And that's assuming this isn't done already—for some reason, I thought those buffers had to be page aligned or you'd get a panic, but I'm not seeing anything about it in the docs, so I might be remembering wrong.)

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    61. Re:uh - by design? by Anonymous Coward · · Score: 0

      I refuse to touch USB, and in most cases refuse to touch digital unless I'm starting with a digital source (MIDI/MOD/IT/etc.) You lose tons of overtones and harmonics, which can stretch out into the 60+KHz range, depending upon instrument/noise being generated (glass breaking can generate into the 100+KHz range. Recorded glass breaking sounds like utter shit compared to real life.)

    62. Re:uh - by design? by CaptQuark · · Score: 1

      begs the question...

      "You keep using that word. I do not think it means what you think it means." ~Inigo Montoya

  3. Why didn't I think of that by Anonymous Coward · · Score: 1

    installs malicious code in a MacBook's boot ROM (read-only memory)

    Why didn't I think of that.

  4. Re:ROM by Nerrd · · Score: 1

    PROM or EPROM actually.

  5. Re:ROM by Fwipp · · Score: 4, Informative

    Well, you're pretty wrong: https://trmm.net/EFI

    This allows an attacker with physical access to the machine to write untrusted code to the SPI flash ROM on the motherboard and creates a new class of firmware bootkits for the MacBook systems.

    Our proof of concept bootkit also replaces Apple's public RSA key in the ROM and prevents software attempts to replace it that are not signed by the attacker's private key. Since the boot ROM is independent of the operating system, reinstallation of OS X will not remove it. Nor does it depend on anything stored on the disk, so replacing the harddrive has no effect. A hardware in-system-programming device is the only way to restore the stock firmware.

  6. Re:ROM by Nerrd · · Score: 2

    SPI Flash - is an eeprom.

  7. Obligatory by Anonymous Coward · · Score: 0
  8. Re:ROM by CajunArson · · Score: 2

    No, by definition he's right: It's tough to overwrite a READ ONLY MEMORY . Of course, the firmware in the Mac isn't actually stored in a true ROM but in an EEPROM or some other solid-state memory that can be overwritten. So the article is incorrect or misleading to call that chip a ROM.

    --
    AntiFA: An abbreviation for Anti First Amendment.
  9. Pretty cool vulnerability but.. by Severus+Snape · · Score: 3, Informative

    If I have physical access to your machine, I'm going to get you one way or another.

    1. Re:Pretty cool vulnerability but.. by Anonymous Coward · · Score: 1

      Maybe you don't even need physical access in the usual sense.

      There was a time when you could take your flash drive to Kinko's to print some documents or a friend's computer to share a couple files, then take it back home and plug it into to your Windows desktop, and get a virus because Windows would automatially execute the freshly placed autorun.inf or autorun.exe. It looks like USB devices might still have a similar problem: http://www.wired.com/2014/07/usb-security/.

      Thunderbolt also supports external storage devices (http://www.akitio.com/portable-storage/neutrino-thunderboltedition), so it wouldn't be to surprising to hear that one of these could be a vector of attack. You might not even have to plug it into an untrusted computer; it could arrive infected from the factory.

    2. Re:Pretty cool vulnerability but.. by QuietLagoon · · Score: 4, Interesting
      True. But where this attack is unique is that it installs itself in a boot-level device, not on the hard disk, and executed BEFORE the OS starts running. Even re-installing the OS or replacing the hard drive won't disinfect the system.

      .
      Then there's this gem:

      The bootkit can even replace Apple’s cryptographic key stored in the ROM with one generated by the attacker, preventing any future legitimate firmware updates from Apple, the researcher said in a blog post.

    3. Re:Pretty cool vulnerability but.. by Anonymous Coward · · Score: 0

      But you don't need physical access. You only need temporary access to a device that gets plugged in at least once. You could infect a company shipping Thunderbolt devices (has happened before with CDs, USB sticks, and HDDs), you could drop infected devices on the ground near targets, you could sell infected things as used on eBay or Amazon, you could infect a device then fix the box then return it as unopened. That *new* item will be resold and a random costumer will become infected.

    4. Re:Pretty cool vulnerability but.. by perpenso · · Score: 1

      If I have physical access to your machine, I'm going to get you one way or another.

      You don't need physical access. Thunderbolt cables have an integrated microcontroller, its one of the reasons the cables are expensive. In theory a hacker could add additional electronics and sell / give away cables.

    5. Re:Pretty cool vulnerability but.. by fuzzyfuzzyfungus · · Score: 1

      Sounds like somebody was cargo-culting it on that design decision: systems that are intent on using cryptographic lockdown to resist tampering usually don't store the blessed key in rewriteable memory, for reasons made obvious here. Depending on the hardware, it gets some sort of more aggressively write-once/locked/burned in at the factory and read only/whatever storage, with the data to be cryptographically verified going in the rewritable part. I suppose it still functions as a sort of checksum; but not really a security measure.

    6. Re:Pretty cool vulnerability but.. by AmiMoJo · · Score: 1

      Not really... Say you have a running but locked laptop in front of you. If it is turned off you are probably screwed since the contents will be encrypted, hopefully. So how do you unlock the machine without knowing the password? With Thunderbolt, Firewire or PC Card you can just hook up a special device that lets you rip the content's of RAM and even modify it, allowing you to bypass the lock screen or even just reset the password in memory.

      The only other viable attack is a cold boot attack, but that can be mitigated by using a laptop with RAM soldered to the motherboard (to prevent it being removed), and setting the BIOS (with password) to do a full RAM test which erases everything. Armed with a soldering iron the attacker might be able to do more, but it's not a simple or guaranteed process.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    7. Re:Pretty cool vulnerability but.. by Anonymous Coward · · Score: 0

      ... it gets some sort of more aggressively write-once/locked/burned in at the factory and read only/whatever storage,

      That would not be a good idea: if the key gets compromized* and subsequently blacklisted by the company you would have no other choice than to ditch the hardware.

      *"compromized" ment as in being abused by hackers and/or used by the end-user to run "non-allowed" software.

      Its a bit odd though: Several years ago the FLASH memory the BIOS resided in was protected by putting a physical swich in the write-signal line going to that memory. Now that, in my eyes perfect, solution seems to have fully gone ...

  10. Hasn't this been known? by maccodemonkey · · Score: 5, Insightful

    Firewire, USB 3.0, and Thunderbolt all have DMA, which means any device hooked to a host can pretty much do anything they want to the host, no matter what the host hardware or OS is. I didn't think this sort of thing was still news?

    1. Re:Hasn't this been known? by bored · · Score: 2

      I'm pretty sure in the case of USB 3 that DMA is a function of the host controller. A device by itself cannot inject into arbitrary memory. This thunderbolt "vulnerability" is the equivalent of the windows autorun on insertion function that was disabled years ago. Only this functions above the level of the current user (aka much worse).

    2. Re:Hasn't this been known? by Anonymous Coward · · Score: 0

      Funny how this was reason to slag firewire, too. Even though a relative simple change in approach would've blocked the whole thing. But no, we require that the interface has full reign of the entire available memory through the DMA interface. SMRT, that. When will we learn?

    3. Re:Hasn't this been known? by Joe_Dragon · · Score: 1

      same thing as a pci-e / pci / cardbus / express card with a boot ROM or flash. They load pre boot at least on non mac systems you can go to bios and trun off option roms / set it to EFI only mode.

    4. Re:Hasn't this been known? by maccodemonkey · · Score: 4, Interesting

      I'm pretty sure in the case of USB 3 that DMA is a function of the host controller. A device by itself cannot inject into arbitrary memory. This thunderbolt "vulnerability" is the equivalent of the windows autorun on insertion function that was disabled years ago. Only this functions above the level of the current user (aka much worse).

      I'm looking up DMA for USB3. Although there are some ways to secure DMA (like a white list of addresses/sizes that are safe to write to), all of the advertised functionality of USB3, such as the sustained data rates, would be very hard to achieve if you didn't have direct access to memory. That's why Firewire ruled for live streaming of data for so long: DMA made it's rates reliable, whereas USB's dependence on the controller and CPU for memory transfers made the throughput more flakey.

    5. Re:Hasn't this been known? by maccodemonkey · · Score: 1

      same thing as a pci-e / pci / cardbus / express card with a boot ROM or flash. They load pre boot at least on non mac systems you can go to bios and trun off option roms / set it to EFI only mode.

      Apple exposes a bunch of pre boot options for the firmware on the command line, but I'm not sure if you can disable pre-boot EFI drivers from there.

    6. Re:Hasn't this been known? by maccodemonkey · · Score: 4, Insightful

      Well, now I'm reading specs on USB 3.0 controllers. Ugh. There's a lot on mapping a bus address to a memory address for DMA, but nothing addressing the security implications of doing so, or what devices are allowed to do, just broad hints like the buffer has to exist in a DMA-able part of memory without saying if that's a security implication or a hardware implication.

      It would be nice to see a follow up article on if/how USB 3.0 protects against these things, because I'm not a kernel USB developer sort of guy, so while I know DMA is there, I'm not feeling like I'd be able to dissect these implementation specs.

    7. Re:Hasn't this been known? by Anonymous Coward · · Score: 1

      Using an IOMMU gives such devices direct virtual memory access which it fully safe (compared to physical memory access which is not safe and what apple did here). IOMMUs also do great things like let you pass through these devices to VMs, run your drivers outside of kernel space etc. You don't need to trust the external hardware (or its drivers): we have the technology to fix this, and have had it for several years. IOMMUs are supported by Intel, AMD and ARM (and others). This is just Apple (which has full control of the hardware and drivers here) not bothering to use the appropriate technology for security presumably because they don't care. Apple did the same stupid thing with firewire. This is not new. I always tell people their thunderbolt monitor could DMA main memory (or just any keys it finds in it) out their Ethernet NIC for inspection with no CPU interaction.

      My next CPU and motherboard will be specifically selected for IOMMU support. Then I can either run a secure OS (that uses the IOMMU properly), or a hyperviser to protect myself from this kind of attack.

    8. Re:Hasn't this been known? by amorsen · · Score: 1

      40Gbps ethernet cards use DMA securely and offer sustained data rates that USB can only dream of.

      --
      Finally! A year of moderation! Ready for 2019?
    9. Re:Hasn't this been known? by Nerrd · · Score: 1

      Thats just because no one has bothered to make a malicious 40Gb NIC. There's nothing inherently secure about a PCIe card using DMA.

    10. Re:Hasn't this been known? by AmiMoJo · · Score: 2

      USB 3.0 devices can't read or write arbitrary RAM like Thunderbolt devices can. The host controller (or rather the driver) has to allocate RAM buffers and then program its DMA controller to copy data in or out of it. In theory it might be vulnerable if there are flaws in the driver perhaps, but it would be reliant on specific drivers and host controllers. The vulnerability is designed in to Thunderbolt as a feature.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    11. Re:Hasn't this been known? by bored · · Score: 1

      Using an IOMMU gives such devices direct virtual memory access which it fully safe (compared to physical memory access which is not safe and what apple did here).

      I was going to mention IOMMUs, but I thought it would just confuse the issue (see the host controller confusion on my other comment).

      In this case IOMMUs will only help you a little, as the article mentions that the option roms are being executed. Executing in the early boot environment, without a hypervisor, or in the hypervisor context, means that the option rom code can simply set the IOMMU to map to any memory the device wishes to access.

    12. Re:Hasn't this been known? by Anonymous Coward · · Score: 0

      Yes, once infected, an IOMMU is no help. From what I can find out about this attack, I'm not sure (anymore) that its related to the DMA problem at all. Maybe thunderbolt is not just horribly insecure in the obvious way, but maybe this is a more subtle horrible security hole at init time in addition, and a neat trick to persist it. I really need to stop assuming security problems are what I think they are: there are so many holes I can never guess which one an article is talking about. Thanks for the correction.

    13. Re:Hasn't this been known? by amorsen · · Score: 1

      You misunderstand. The bus is ethernet. You can plug anything you want into the ethernet plug without giving it unlimited access to your system memory. Just like you can plug anything into a (mythical) properly implemented USB bus without any risk, but UNLIKE Firewire and Thunderbolt.

      --
      Finally! A year of moderation! Ready for 2019?
    14. Re:Hasn't this been known? by drinkypoo · · Score: 1

      Firewire, USB 3.0, and Thunderbolt all have DMA, which means any device hooked to a host can pretty much do anything they want to the host, no matter what the host hardware or OS is. I didn't think this sort of thing was still news?

      It's news to me that apple still isn't using an IOMMU, I thought that they were supposed to be fixing this problem. Most modern PCs have one.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    15. Re:Hasn't this been known? by drinkypoo · · Score: 1

      Although there are some ways to secure DMA (like a white list of addresses/sizes that are safe to write to), all of the advertised functionality of USB3, such as the sustained data rates, would be very hard to achieve if you didn't have direct access to memory

      Sigh. It's almost like slashdot is peopled by people who know fuck-all about computers, such as the existence of the IOMMU. Decent operating systems have support for these. They completely solve this problem with minimal overhead.

      That's why Firewire ruled for live streaming of data for so long: DMA made it's rates reliable

      Yes, firewire has the same problem, and the same solution.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  11. Putting unprotected flash in computers was stupid by Anonymous Coward · · Score: 2, Insightful

    Almost as stupid as making PCI-E part of an external bus. The BIOS write protect jumper of old was the right idea.

  12. Yeah, like that'll happen. by Anonymous Coward · · Score: 0

    For that to happen someone would have to make a thunderbolt device you wanted to buy.

    1. Re:Yeah, like that'll happen. by ShanghaiBill · · Score: 1

      For that to happen someone would have to make a thunderbolt device you wanted to buy.

      They already do. They just need to make one that I can afford.

  13. Re:ROM by Joe_Dragon · · Score: 1

    lot's of people can them rom's they have also been called flash roms. Rom update, flash update, etc

  14. Writable ROM by Anonymous Coward · · Score: 1

    A writable ROM are clearly not a ROM

    1. Re:Writable ROM by orgelspieler · · Score: 1

      Yeah either the article means BIOS or EEPROM, or Apple is clearly doing it wrong. From the article: "Malicious code installed in the MacBook boot ROM will be executed before the OS is loaded..."

    2. Re:Writable ROM by Anonymous Coward · · Score: 0

      A writable ROM are clearly not a ROM

      Well, an EEPROM really isn't, arguably. An old EPROM would require opening the machine and exposing the chip to UV through the glass cover - while arguably still not a "ROM" it is much harder to erase and reprogram (especially if, as most old BIOS EPROMs had, you have to physically remove the sticker over the window to erase it).

    3. Re:Writable ROM by Anonymous Coward · · Score: 0

      A writable ROM are clearly not a ROM

      Yeah! All ROM is, by definition, permanently blank because it is impossible to write to a ROM.

    4. Re:Writable ROM by Anonymous Coward · · Score: 0

      You don't write a ROM. You build it that way in the manufacturing facility. Google "mask ROM". The contents being read out are physically fixed--because they've been etched in by the manufacturer.

      You can try arguing that it's still "writing", but it is not writing in the sense of using a device-provided function to modify itself.

    5. Re:Writable ROM by Anonymous Coward · · Score: 0

      Yes, and so by your definition, PROM is not ROM.

      Fail.

  15. Well...Isn't that cute. by RavenLrD20k · · Score: 1

    The attack, dubbed Thunderstrike,

    Tell me. Does it get it's own little theme song performed by AC/DC too?? That would just complete the marketing circle!

    1. Re:Well...Isn't that cute. by fuzzyfuzzyfungus · · Score: 1

      Hey, at least it won't be a dirty deed done dirt cheap, since it requires a malicious thunderbolt device to carry out...

  16. Re:ROM by Anonymous Coward · · Score: 4, Interesting

    This is one area where good hardware design can fix the problem. Those SPI EEPROMs have a Write-Protect pin, which should be set disabled unless a physical switch is enabled (jumper anyone?).

    Yes, it requires opening your computer to update firmware, but firmware updates are a dangerous operation anyway and should not be permitted willy-nilly.

  17. Sun J-Bus systems did it right by calidoscope · · Score: 1

    The USB and Firewire interface on the 10 year old J-Bus (UltraSparc IIIi) had memory management for the I/O interfaces as well as the CPU. The DMA from external interfaces could only access memory granted to it by the OS.

    --
    A Shadeless room is a brighter room.
    1. Re:Sun J-Bus systems did it right by Anonymous Coward · · Score: 0

      That's the luxury of not being able to natively support the entire Intel based protocol.

  18. open firmware password by Anonymous Coward · · Score: 0

    Does the vulnerability work if an open firmware password has been set?

    1. Re:open firmware password by Anonymous Coward · · Score: 0

      Furthermore, what if FileVault is enabled and the whole disk is encrypted? I think that means you've bricked a mac.

  19. Re:ROM by Anonymous Coward · · Score: 0

    Yeah, but to people that don't really understand that "Flash ROM" is really "EEPROM" then they obviously can believe that "ROM" can be changed even though its "Read Only Memory". Flash/EEPROM technically is *not* ROM, it's simply "persistent RAM" if one wanted to think of it that way - an SSD is the pretty much the same thing really, as is a USB memory stick.

  20. Re:ROM by orgelspieler · · Score: 2

    Best response I've seen all day. But good luck convincing Apple that anybody but a "Genius" should be cracking open an apple device. Aren't they still using those patented fuck-you^W pentalobe screws?

  21. Re:ROM by Anonymous Coward · · Score: 0

    No, he's right - you just don't understand that ROM != EEPROM. Dumbass.

  22. So if you get hit by this attack, have you been... by exabrial · · Score: 3, Funny

    So if you get hit by this attack, have you been... Thunderstruck?? /me shows self to door

  23. Writing to ROM? Wrong. by pubwvj · · Score: 1, Redundant

    "installs malicious code in a MacBook's boot ROM (read-only memory)"

    Nope. It may write to EPROM or something like that but by definition it can not write to ROM. ROM means Read Only Memory and as such there is no writing to it. EPROM or some other flavor of Erasable Programmable Read Only Memory is what it would have to be working with. Too bad writers can't read. Not even their own sentences. Or perhaps they can't comprehend. IM (Incomprehensible Memory) in the case of the OP.

  24. Attacker does *not* need physical access ... by perpenso · · Score: 5, Insightful

    An attacker with physical access to the target is usually a bad thing (tm),

    The attacker does not need physical access. All the attacker needs to do is sell hacked thunderbolt cables on ebay or alibaba.

    1. Re:Attacker does *not* need physical access ... by Anonymous Coward · · Score: 0

      Then the attacker has physical access. I see the possible debate, but fall on the side if this not being a remote exploit.

  25. Re:ROM by DigiShaman · · Score: 1

    This exploit can be used both ways as a "tool", right? If a malware infected Thunderbolt external drive can flash the EEPROM with a rootkit, is there any reason to believe that Apple couldn't create a utility Thunderbolt ROM drive (read-only to prevent client laptop cross-contamination) to stomp it back out?

    --
    Life is not for the lazy.
  26. I propose we name it: by Anonymous Coward · · Score: 0
  27. Re:So if you get hit by this attack, have you been by Anonymous Coward · · Score: 0

    You apparently did not get the joke

  28. Re:ROM by AmiMoJo · · Score: 1

    Aren't they still using those patented fuck-you^W pentalobe screws?

    But... but... but... they're better than normal screws! They are more robust, because you know, most people open their laptop up every week and replacement screws a really expensive...

    Come on fanboys, mod me down :-)

    --
    const int one = 65536; (Silvermoon, Texture.cs)
    SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  29. Dear Slashdot editors .. by lippydude · · Score: 0

    "The attack, dubbed Thunderstrike, installs malicious code in a MacBook's boot ROM (read-only memory), which is stored in a chip on the motherboard"

    Dear Slashdot editors, shouldn't this be malicious 'computer' boot ROM code. At least it would be so referenced if it infected a Windows 'computer' :)

  30. Re:ROM by LDAPMAN · · Score: 1

    Were talking about MacBooks here, not phones. The screws are normal phillips head. They are tiny but easily removed. Note that you can replace your SSD yourself. You can also replace the battery but they frown on that as they want to make sure they are disposed of properly.

  31. Re:ROM by Anonymous Coward · · Score: 0

    This assumes the malware bootkit allows you to rewrite the firmware.

    With access to the firmware, you could easily rewrite the appropriate function calls and politely nod your head Yes to the "Flash Firmware" command and do jack with it... hence the need for hardware based reprogramming (as per the summary)

    Captcha: screwed

  32. Re:ROM by Barny · · Score: 2

    Pfft, of course they are better screws. They are both more expensive and annoying to operate, just like other Apple Iproducts.

    iScrew

    Only meant to be used by the special Apple certified screwdriver, the iScrewyou.

    --
    ...
    /me sighs
  33. Re:ROM by Anonymous Coward · · Score: 0

    Well, they could have a single button on the side that says firmware update. Who knows when you press it if it's read-only or writeable, though...

  34. Apple used to have security for firmware updates by ZorinLynx · · Score: 2

    With older (PPC?) based Macs, to update the firmware you had to power off the machine, then turn it on by holding the power button until you got an extra beep or sound. This would physically un-write-protect the firmware EPROM so that it could be updated by open firmware.

    In their quest to make everything as "user friendly" as possible, they took out this hardware security feature, allowing the update to just happen without any physical action.

    Bad Apple, no donut.

  35. Loads into ROM by Anonymous Coward · · Score: 0

    Ummm no, if its truly ROM you cant write to it.. Geesh.

  36. READ ONLY by Jeremiah+Cornelius · · Score: 1

    You keep using that word. I don't think it means what you think it does....

    --
    "Flyin' in just a sweet place,
    Never been known to fail..."
  37. Watch out for VGA dongles by Stewie241 · · Score: 1

    Here's how you do it:
    1. Go to a conference, and allow your dongle to 'accidentally' fall out of your bag onto the floor. Wait for somebody to come and pick it up.
    2. Open up an online shop and sell knock-off dongles at a reduced price
    3. Post an ad on Craigslist selling your 'old' dongle
    4. Go to a conference and swap out the dongle that is there with your dongle

    At $30 a pop people many unwitting Mac users would pick up one of these devices if they were convinced it were impossible to find out the owner. They might not use it right away, but chances are that at some point they will be in a bind and need one.

    No physical access necessary - just a bit of social engineering to bring your device to the machine.

    This is really probably the scariest vulnerability I have seen in a while.

  38. Re:uh - by design? PROM ? by Anonymous Coward · · Score: 0

    If you can write to ROM it isn't ROM to begin with, but PROM*. And you can alter PROM by flipping (the default) ones to zeroes (making it harder, but often still possible to apply useful changes).

    And as not all attacks need lots of code even PROM is susceptible to being "updated" for something malicious.

    *For the ones who are wondering how data than is placed into the ROM, the full name is "masker-programmable ROM". The zeroes and ones are put into the ROM as a part of the physical manufacturing process.

  39. Overwriting ROM? by Toshito · · Score: 1

    Can someone explain to me how you can write to Read Only Memory?

    --
    Try it! Library of Babel
  40. Install into the ROM (read only memory) by allo · · Score: 1

    Find the mistake.

    Vendors are stupid, if they make ROM writable, without setting a jumper. Or making it writable at all.

  41. Re:uh - by design? PROM ? by CaptQuark · · Score: 1

    ROM -- Read Only Memory. As stated, data is stored during the manufacturing process. Non-changeable

    PROM -- Programmable Read Only Memory. Stores data by burning fusible links inside the chip using a special programming station. Non-changeable for most practical purposes. You can't fix a burned link, but you can burn additional ones.

    EPROM -- Erasable Programmable Read Only Memory. Data can be stored and then erased by exposing the chip to UV radiation. Chips of this type can be recognized by the opaque sticker covering the quartz window on the top of the chip. No UV sources are built into computer enclosures.

    EEPROM -- Electrically Erasable Programmable Read Only Memory. The only type of ROM memory that can be reprogrammed inside a computer. Almost identical to FLASH memory.

  42. Re:Apple used to have security for firmware update by strikethree · · Score: 1

    Such features were likely removed at the request of the NSA or other shadowy government agency.

    --
    "Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen