Fwd: [Cryptography] Did Intel just execute its warrant canary ?
---------- Forwarded message ---------- From: Henry Baker <hbaker1@pipeline.com> Date: Mon, Jun 8, 2015 at 6:24 PM Subject: [Cryptography] Did Intel just execute its warrant canary ? To: cryptography@metzdowd.com FYI -- I conjecture that the second GPU story following less than one month after the first GPU story is not just coincidence, but one of the requirements of a secret National Security Letter to Intel. The first story shows how GPU's can house malware, while the second story explains that Intel won't be sharing its GPU code where such malware will be housed. "no reverse engineering, decompilation, or disassembly of this software is permitted" As feared, the DMCA will be used against those who attempt to look for this malware in Intel GPU's. https://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act -------- http://arstechnica.com/security/2015/05/gpu-based-rootkit-and-keylogger-offe... GPU-based rootkit and keylogger offer superior stealth and computing power Proof-of-concept malware may pave the way for future in-the-wild attacks. by Dan Goodin - May 7, 2015 3:43 pm UTC Developers have published two pieces of malware that take the highly unusual step of completely running on an infected computer's graphics card, rather than its CPU, to enhance their stealthiness and give them increased computational abilities. Both the Jellyfish rootkit and the Demon keylogger are described as proofs-of-concept by their pseudo-anonymous developers, whom Ars was unable to contact. Tapping an infected computer's GPU allows malware to run without the usual software hooks or modifications malware makes in the operating system kernel. Those modifications can be dead giveaways that a system is infected. https://github.com/x0r1/jellyfish https://github.com/x0r1/Demon Here's how the developers describe their rootkit: Jellyfish is a Linux based userland gpu rootkit proof of concept project utilizing the LD_PRELOAD technique from Jynx (CPU), as well as the OpenCL API developed by Khronos group (GPU). Code currently supports AMD and NVIDIA graphics cards. However, the AMDAPPSDK does support Intel as well. Advantages of gpu stored memory: * No gpu malware analysis tools available on web * Can snoop on cpu host memory via DMA * Gpu can be used for fast/swift mathematical calculations like xor'ing or parsing * Stubs * Malicious memory is still inside gpu after shutdown Requirements for use: * Have OpenCL drivers/icds installed * Nvidia or AMD graphics card (intel supports amd's sdk) * Change line 103 in rootkit/kit.c to server ip you want to monitor gpu client from Stay tuned for more features: * client listener; let buffers stay stored in gpu until you send magic packet from server Disclaimer: Educational purposes only; authors of this project/demonstration are in no way, shape or form responsible for what you may use this for whether illegal or not. They provide no technical details about Demon keylogger other than to say it's a proof-of-concept that implements the malware described in this 2013 academic research paper titled You Can Type, but You Can’t Hide: A Stealthy GPU-based Keylogger. The Demon creators stress that they aren't associated with the researchers. http://www.cs.columbia.edu/~mikepo/papers/gpukeylogger.eurosec13.pdf "The key idea behind our approach is to monitor the system’s keyboard buffer directly from the GPU via DMA [direct memory access], without any hooks or modifications in the kernel's code and data structures besides the page table," the researchers behind the 2013 paper wrote. "The evaluation of our prototype implementation shows that a GPU-based keylogger can effectively record all user keystrokes, store them in the memory space of the GPU, and even analyze the recorded data in-place, with negligible runtime overhead." Aside from malware that taps GPUs to mint Bitcoin and other crypto currencies, Ars isn't aware of malicious software actively circulating in the wild that makes use of infected computers' graphics processors. And even then, most or all of those titles run mainly on the CPU and offload only the computationally intensive workloads to the GPU. In March, researchers from Kaspersky Lab documented highly sophisticated malware in the wild that infected firmware that runs 12 different models of hard drives. The group that created the malware had flown under the radar for 14 years. In its current form Jellyfish is likely to remain a highly niche undertaking, since it requires a dedicated GPU. Since many computers don't contain stand-alone graphics cards, such malware might greatly limit the machines that could be infected. Still, the approach may make sense in certain situations, say for attackers targeting gamers or video enthusiasts, or espionage campaigns where stealth is crucial. And as readers have pointed out in comments below, it's feasible malware could be developed that runs on graphics processors integrated into CPUs. Post updated to recast the last paragraph to account for integrated graphics processors, and to add details in the second-to-last paragraph about malware infecting hard-drive firmware. ---------------- https://www.phoronix.com/scan.php?page=news_item&px=Intel-SKL-BXT-Firmware-Blobs Intel Skylake & Broxton To Require Graphics Firmware Blobs Published on 05 June 2015 06:20 PM EDT Written by Michael Larabel in Intel Intel's upcoming Skylake and Broxton hardware will require some binary-only firmware blobs by the i915 DRM kernel graphics driver. Rodrigo Vivi of Intel's Open-Source Technology Center sent in the pull request for landing these binary files into the linux-firmware repository. Up to now there's been no i915 blobs within the linux-firmware tree. These first i915 DRM firmware blobs are for Skylake and Broxton for the GuC and DMC. DMC in this context is the Display Microcontroller, which is present in Skylake (Gen9) and newer and used within the display engine to save and restore its state when entering into low-power states and then resuming. The DMC is basically saving/restoring display registers across low-power states separate of the kernel. The GuC engine on Skylake is responsible for workload scheduling on the parallel graphics engines. Intel explained on 01.org, "GuC is designed to perform graphics workload scheduling on the various graphics parallel engines. In this scheduling model, host software submits work through one of the 256 graphics doorbells and this invokes the scheduling operation on the appropriate graphics engine. Scheduling operations include determining which workload to run next, submitting a workload to a command streamer, pre-empting existing workloads running on an engine, monitoring progress and notifying host SW when work is done." This page also seems to indicate that these firmware blobs are required by the DRM driver rather than being an optional add-on. The license of these firmware blobs also indicate that redistribution is only allowed in binary form without modification. Beyond that, "no reverse engineering, decompilation, or disassembly of this software is permitted." These new firmware blobs will certainly have some open-source enthusiasts less excited now about Skylake, Broadwell's successor beginning to ship later this year, and Broxton meanwhile is the new Atom SoC built using the Goldmont architecture and will feature Skylake graphics. If there's any good news out of the situation, at least Intel is shipping these firmware files early rather than NVIDIA that with their months-old hardware still hasn't released their GTX 900 Maxwell firmware files needed by the Nouveau driver to provide open-source hardware acceleration. AMD also tends to be timely with the releasing of their necessary binary-only GPU firmware files for the open-source Linux driver. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
OOOhhhhhHHH nice. One of these days someone's going to figure out the encoding method and private keys of all those keystrokes in various blockchains that were broadcast by GPU-mining malware. Now if I take my paranoia hat off and put on my 'scam the investors' hat, I'd say the only thing the DMCA will be used for is to provide plausible deniability that Intel just hired some AMD/Nvidia engineers and they keep using the same code they've been writing since the SGI days and just slap an Intel copyright on the output. Besides, if you wanted to hid malware on an intel chip, you could easily hide it here, no GPU needed. https://software.intel.com/sites/default/files/xeon-processor-7.png There are probably at least 3 debug interfaces in the chip for which the only good documentation exists in the Mossad, NSA, and Chinese intelligence offices. On Tue, Jun 09, 2015 at 01:01:44AM -0400, grarpamp wrote:
---------- Forwarded message ---------- From: Henry Baker <hbaker1@pipeline.com> Date: Mon, Jun 8, 2015 at 6:24 PM Subject: [Cryptography] Did Intel just execute its warrant canary ? To: cryptography@metzdowd.com
FYI -- I conjecture that the second GPU story following less than one month after the first GPU story is not just coincidence, but one of the requirements of a secret National Security Letter to Intel.
The first story shows how GPU's can house malware, while the second story explains that Intel won't be sharing its GPU code where such malware will be housed.
"no reverse engineering, decompilation, or disassembly of this software is permitted"
As feared, the DMCA will be used against those who attempt to look for this malware in Intel GPU's.
https://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act -------- http://arstechnica.com/security/2015/05/gpu-based-rootkit-and-keylogger-offe...
GPU-based rootkit and keylogger offer superior stealth and computing power
Proof-of-concept malware may pave the way for future in-the-wild attacks.
by Dan Goodin - May 7, 2015 3:43 pm UTC
Developers have published two pieces of malware that take the highly unusual step of completely running on an infected computer's graphics card, rather than its CPU, to enhance their stealthiness and give them increased computational abilities.
Both the Jellyfish rootkit and the Demon keylogger are described as proofs-of-concept by their pseudo-anonymous developers, whom Ars was unable to contact. Tapping an infected computer's GPU allows malware to run without the usual software hooks or modifications malware makes in the operating system kernel. Those modifications can be dead giveaways that a system is infected.
https://github.com/x0r1/jellyfish
Here's how the developers describe their rootkit:
Jellyfish is a Linux based userland gpu rootkit proof of concept project utilizing the LD_PRELOAD technique from Jynx (CPU), as well as the OpenCL API developed by Khronos group (GPU). Code currently supports AMD and NVIDIA graphics cards. However, the AMDAPPSDK does support Intel as well.
Advantages of gpu stored memory:
* No gpu malware analysis tools available on web * Can snoop on cpu host memory via DMA * Gpu can be used for fast/swift mathematical calculations like xor'ing or parsing * Stubs * Malicious memory is still inside gpu after shutdown
Requirements for use:
* Have OpenCL drivers/icds installed * Nvidia or AMD graphics card (intel supports amd's sdk) * Change line 103 in rootkit/kit.c to server ip you want to monitor gpu client from
Stay tuned for more features:
* client listener; let buffers stay stored in gpu until you send magic packet from server
Disclaimer:
Educational purposes only; authors of this project/demonstration are in no way, shape or form responsible for what you may use this for whether illegal or not.
They provide no technical details about Demon keylogger other than to say it's a proof-of-concept that implements the malware described in this 2013 academic research paper titled You Can Type, but You Can’t Hide: A Stealthy GPU-based Keylogger. The Demon creators stress that they aren't associated with the researchers.
http://www.cs.columbia.edu/~mikepo/papers/gpukeylogger.eurosec13.pdf
"The key idea behind our approach is to monitor the system’s keyboard buffer directly from the GPU via DMA [direct memory access], without any hooks or modifications in the kernel's code and data structures besides the page table," the researchers behind the 2013 paper wrote. "The evaluation of our prototype implementation shows that a GPU-based keylogger can effectively record all user keystrokes, store them in the memory space of the GPU, and even analyze the recorded data in-place, with negligible runtime overhead."
Aside from malware that taps GPUs to mint Bitcoin and other crypto currencies, Ars isn't aware of malicious software actively circulating in the wild that makes use of infected computers' graphics processors. And even then, most or all of those titles run mainly on the CPU and offload only the computationally intensive workloads to the GPU. In March, researchers from Kaspersky Lab documented highly sophisticated malware in the wild that infected firmware that runs 12 different models of hard drives. The group that created the malware had flown under the radar for 14 years.
In its current form Jellyfish is likely to remain a highly niche undertaking, since it requires a dedicated GPU. Since many computers don't contain stand-alone graphics cards, such malware might greatly limit the machines that could be infected. Still, the approach may make sense in certain situations, say for attackers targeting gamers or video enthusiasts, or espionage campaigns where stealth is crucial. And as readers have pointed out in comments below, it's feasible malware could be developed that runs on graphics processors integrated into CPUs.
Post updated to recast the last paragraph to account for integrated graphics processors, and to add details in the second-to-last paragraph about malware infecting hard-drive firmware. ---------------- https://www.phoronix.com/scan.php?page=news_item&px=Intel-SKL-BXT-Firmware-Blobs
Intel Skylake & Broxton To Require Graphics Firmware Blobs
Published on 05 June 2015 06:20 PM EDT
Written by Michael Larabel in Intel
Intel's upcoming Skylake and Broxton hardware will require some binary-only firmware blobs by the i915 DRM kernel graphics driver.
Rodrigo Vivi of Intel's Open-Source Technology Center sent in the pull request for landing these binary files into the linux-firmware repository. Up to now there's been no i915 blobs within the linux-firmware tree.
These first i915 DRM firmware blobs are for Skylake and Broxton for the GuC and DMC. DMC in this context is the Display Microcontroller, which is present in Skylake (Gen9) and newer and used within the display engine to save and restore its state when entering into low-power states and then resuming. The DMC is basically saving/restoring display registers across low-power states separate of the kernel.
The GuC engine on Skylake is responsible for workload scheduling on the parallel graphics engines. Intel explained on 01.org, "GuC is designed to perform graphics workload scheduling on the various graphics parallel engines. In this scheduling model, host software submits work through one of the 256 graphics doorbells and this invokes the scheduling operation on the appropriate graphics engine. Scheduling operations include determining which workload to run next, submitting a workload to a command streamer, pre-empting existing workloads running on an engine, monitoring progress and notifying host SW when work is done." This page also seems to indicate that these firmware blobs are required by the DRM driver rather than being an optional add-on.
The license of these firmware blobs also indicate that redistribution is only allowed in binary form without modification. Beyond that, "no reverse engineering, decompilation, or disassembly of this software is permitted."
These new firmware blobs will certainly have some open-source enthusiasts less excited now about Skylake, Broadwell's successor beginning to ship later this year, and Broxton meanwhile is the new Atom SoC built using the Goldmont architecture and will feature Skylake graphics. If there's any good news out of the situation, at least Intel is shipping these firmware files early rather than NVIDIA that with their months-old hardware still hasn't released their GTX 900 Maxwell firmware files needed by the Nouveau driver to provide open-source hardware acceleration. AMD also tends to be timely with the releasing of their necessary binary-only GPU firmware files for the open-source Linux driver.
_______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
-- ---------------------------------------------------------------------------- Troy Benjegerdes 'da hozer' hozer@hozed.org 7 elements earth::water::air::fire::mind::spirit::soul grid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash
On 10/06/15 14:41, Troy Benjegerdes wrote:
OOOhhhhhHHH nice.
One of these days someone's going to figure out the encoding method and private keys of all those keystrokes in various blockchains that were broadcast by GPU-mining malware.
Now if I take my paranoia hat off and put on my 'scam the investors' hat, I'd say the only thing the DMCA will be used for is to provide plausible deniability that Intel just hired some AMD/Nvidia engineers and they keep using the same code they've been writing since the SGI days and just slap an Intel copyright on the output.
Besides, if you wanted to hid malware on an intel chip, you could easily hide it here, no GPU needed. https://software.intel.com/sites/default/files/xeon-processor-7.png
There are probably at least 3 debug interfaces in the chip for which the only good documentation exists in the Mossad, NSA, and Chinese intelligence offices.
See this as well, no need to be Mossad, NSA, ... https://www.shodan.io/search?query=HTTP%2F1.1+Active+Management+Technology https://en.wikipedia.org/wiki/Intel_Active_Management_Technology#Known_vulne... Krys
On Tue, Jun 09, 2015 at 01:01:44AM -0400, grarpamp wrote:
---------- Forwarded message ---------- From: Henry Baker <hbaker1@pipeline.com> Date: Mon, Jun 8, 2015 at 6:24 PM Subject: [Cryptography] Did Intel just execute its warrant canary ? To: cryptography@metzdowd.com
FYI -- I conjecture that the second GPU story following less than one month after the first GPU story is not just coincidence, but one of the requirements of a secret National Security Letter to Intel.
The first story shows how GPU's can house malware, while the second story explains that Intel won't be sharing its GPU code where such malware will be housed.
"no reverse engineering, decompilation, or disassembly of this software is permitted"
As feared, the DMCA will be used against those who attempt to look for this malware in Intel GPU's.
https://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act -------- http://arstechnica.com/security/2015/05/gpu-based-rootkit-and-keylogger-offe...
GPU-based rootkit and keylogger offer superior stealth and computing power
Proof-of-concept malware may pave the way for future in-the-wild attacks.
by Dan Goodin - May 7, 2015 3:43 pm UTC
Developers have published two pieces of malware that take the highly unusual step of completely running on an infected computer's graphics card, rather than its CPU, to enhance their stealthiness and give them increased computational abilities.
Both the Jellyfish rootkit and the Demon keylogger are described as proofs-of-concept by their pseudo-anonymous developers, whom Ars was unable to contact. Tapping an infected computer's GPU allows malware to run without the usual software hooks or modifications malware makes in the operating system kernel. Those modifications can be dead giveaways that a system is infected.
https://github.com/x0r1/jellyfish
Here's how the developers describe their rootkit:
Jellyfish is a Linux based userland gpu rootkit proof of concept project utilizing the LD_PRELOAD technique from Jynx (CPU), as well as the OpenCL API developed by Khronos group (GPU). Code currently supports AMD and NVIDIA graphics cards. However, the AMDAPPSDK does support Intel as well.
Advantages of gpu stored memory:
* No gpu malware analysis tools available on web * Can snoop on cpu host memory via DMA * Gpu can be used for fast/swift mathematical calculations like xor'ing or parsing * Stubs * Malicious memory is still inside gpu after shutdown
Requirements for use:
* Have OpenCL drivers/icds installed * Nvidia or AMD graphics card (intel supports amd's sdk) * Change line 103 in rootkit/kit.c to server ip you want to monitor gpu client from
Stay tuned for more features:
* client listener; let buffers stay stored in gpu until you send magic packet from server
Disclaimer:
Educational purposes only; authors of this project/demonstration are in no way, shape or form responsible for what you may use this for whether illegal or not.
They provide no technical details about Demon keylogger other than to say it's a proof-of-concept that implements the malware described in this 2013 academic research paper titled You Can Type, but You Can’t Hide: A Stealthy GPU-based Keylogger. The Demon creators stress that they aren't associated with the researchers.
http://www.cs.columbia.edu/~mikepo/papers/gpukeylogger.eurosec13.pdf
"The key idea behind our approach is to monitor the system’s keyboard buffer directly from the GPU via DMA [direct memory access], without any hooks or modifications in the kernel's code and data structures besides the page table," the researchers behind the 2013 paper wrote. "The evaluation of our prototype implementation shows that a GPU-based keylogger can effectively record all user keystrokes, store them in the memory space of the GPU, and even analyze the recorded data in-place, with negligible runtime overhead."
Aside from malware that taps GPUs to mint Bitcoin and other crypto currencies, Ars isn't aware of malicious software actively circulating in the wild that makes use of infected computers' graphics processors. And even then, most or all of those titles run mainly on the CPU and offload only the computationally intensive workloads to the GPU. In March, researchers from Kaspersky Lab documented highly sophisticated malware in the wild that infected firmware that runs 12 different models of hard drives. The group that created the malware had flown under the radar for 14 years.
In its current form Jellyfish is likely to remain a highly niche undertaking, since it requires a dedicated GPU. Since many computers don't contain stand-alone graphics cards, such malware might greatly limit the machines that could be infected. Still, the approach may make sense in certain situations, say for attackers targeting gamers or video enthusiasts, or espionage campaigns where stealth is crucial. And as readers have pointed out in comments below, it's feasible malware could be developed that runs on graphics processors integrated into CPUs.
Post updated to recast the last paragraph to account for integrated graphics processors, and to add details in the second-to-last paragraph about malware infecting hard-drive firmware. ---------------- https://www.phoronix.com/scan.php?page=news_item&px=Intel-SKL-BXT-Firmware-Blobs
Intel Skylake & Broxton To Require Graphics Firmware Blobs
Published on 05 June 2015 06:20 PM EDT
Written by Michael Larabel in Intel
Intel's upcoming Skylake and Broxton hardware will require some binary-only firmware blobs by the i915 DRM kernel graphics driver.
Rodrigo Vivi of Intel's Open-Source Technology Center sent in the pull request for landing these binary files into the linux-firmware repository. Up to now there's been no i915 blobs within the linux-firmware tree.
These first i915 DRM firmware blobs are for Skylake and Broxton for the GuC and DMC. DMC in this context is the Display Microcontroller, which is present in Skylake (Gen9) and newer and used within the display engine to save and restore its state when entering into low-power states and then resuming. The DMC is basically saving/restoring display registers across low-power states separate of the kernel.
The GuC engine on Skylake is responsible for workload scheduling on the parallel graphics engines. Intel explained on 01.org, "GuC is designed to perform graphics workload scheduling on the various graphics parallel engines. In this scheduling model, host software submits work through one of the 256 graphics doorbells and this invokes the scheduling operation on the appropriate graphics engine. Scheduling operations include determining which workload to run next, submitting a workload to a command streamer, pre-empting existing workloads running on an engine, monitoring progress and notifying host SW when work is done." This page also seems to indicate that these firmware blobs are required by the DRM driver rather than being an optional add-on.
The license of these firmware blobs also indicate that redistribution is only allowed in binary form without modification. Beyond that, "no reverse engineering, decompilation, or disassembly of this software is permitted."
These new firmware blobs will certainly have some open-source enthusiasts less excited now about Skylake, Broadwell's successor beginning to ship later this year, and Broxton meanwhile is the new Atom SoC built using the Goldmont architecture and will feature Skylake graphics. If there's any good news out of the situation, at least Intel is shipping these firmware files early rather than NVIDIA that with their months-old hardware still hasn't released their GTX 900 Maxwell firmware files needed by the Nouveau driver to provide open-source hardware acceleration. AMD also tends to be timely with the releasing of their necessary binary-only GPU firmware files for the open-source Linux driver.
_______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
On 10/06/15 15:47, Christian Gagneraud wrote:
On 10/06/15 14:41, Troy Benjegerdes wrote:
OOOhhhhhHHH nice.
One of these days someone's going to figure out the encoding method and private keys of all those keystrokes in various blockchains that were broadcast by GPU-mining malware.
Now if I take my paranoia hat off and put on my 'scam the investors' hat, I'd say the only thing the DMCA will be used for is to provide plausible deniability that Intel just hired some AMD/Nvidia engineers and they keep using the same code they've been writing since the SGI days and just slap an Intel copyright on the output.
Besides, if you wanted to hid malware on an intel chip, you could easily hide it here, no GPU needed. https://software.intel.com/sites/default/files/xeon-processor-7.png
There are probably at least 3 debug interfaces in the chip for which the only good documentation exists in the Mossad, NSA, and Chinese intelligence offices.
See this as well, no need to be Mossad, NSA, ... https://www.shodan.io/search?query=HTTP%2F1.1+Active+Management+Technology https://en.wikipedia.org/wiki/Intel_Active_Management_Technology#Known_vulne...
BTW, every single CPU on this planet has a JTAG[1] port (or equivalent), so with physical access to the hardware you can install persistent backdoor on virtually any CPU/GPU/MCU/RAM/ROM/FPGA/CPLD/DSP/..., and yes the NSA did it: https://blog.pjhoodsco.org/nsa-device-godsurge/ Krys [1] https://en.wikipedia.org/wiki/Joint_Test_Action_Group
Krys
On Tue, Jun 09, 2015 at 01:01:44AM -0400, grarpamp wrote:
---------- Forwarded message ---------- From: Henry Baker <hbaker1@pipeline.com> Date: Mon, Jun 8, 2015 at 6:24 PM Subject: [Cryptography] Did Intel just execute its warrant canary ? To: cryptography@metzdowd.com
FYI -- I conjecture that the second GPU story following less than one month after the first GPU story is not just coincidence, but one of the requirements of a secret National Security Letter to Intel.
The first story shows how GPU's can house malware, while the second story explains that Intel won't be sharing its GPU code where such malware will be housed.
"no reverse engineering, decompilation, or disassembly of this software is permitted"
As feared, the DMCA will be used against those who attempt to look for this malware in Intel GPU's.
https://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act -------- http://arstechnica.com/security/2015/05/gpu-based-rootkit-and-keylogger-offe...
GPU-based rootkit and keylogger offer superior stealth and computing power
Proof-of-concept malware may pave the way for future in-the-wild attacks.
by Dan Goodin - May 7, 2015 3:43 pm UTC
Developers have published two pieces of malware that take the highly unusual step of completely running on an infected computer's graphics card, rather than its CPU, to enhance their stealthiness and give them increased computational abilities.
Both the Jellyfish rootkit and the Demon keylogger are described as proofs-of-concept by their pseudo-anonymous developers, whom Ars was unable to contact. Tapping an infected computer's GPU allows malware to run without the usual software hooks or modifications malware makes in the operating system kernel. Those modifications can be dead giveaways that a system is infected.
https://github.com/x0r1/jellyfish
Here's how the developers describe their rootkit:
Jellyfish is a Linux based userland gpu rootkit proof of concept project utilizing the LD_PRELOAD technique from Jynx (CPU), as well as the OpenCL API developed by Khronos group (GPU). Code currently supports AMD and NVIDIA graphics cards. However, the AMDAPPSDK does support Intel as well.
Advantages of gpu stored memory:
* No gpu malware analysis tools available on web * Can snoop on cpu host memory via DMA * Gpu can be used for fast/swift mathematical calculations like xor'ing or parsing * Stubs * Malicious memory is still inside gpu after shutdown
Requirements for use:
* Have OpenCL drivers/icds installed * Nvidia or AMD graphics card (intel supports amd's sdk) * Change line 103 in rootkit/kit.c to server ip you want to monitor gpu client from
Stay tuned for more features:
* client listener; let buffers stay stored in gpu until you send magic packet from server
Disclaimer:
Educational purposes only; authors of this project/demonstration are in no way, shape or form responsible for what you may use this for whether illegal or not.
They provide no technical details about Demon keylogger other than to say it's a proof-of-concept that implements the malware described in this 2013 academic research paper titled You Can Type, but You Can’t Hide: A Stealthy GPU-based Keylogger. The Demon creators stress that they aren't associated with the researchers.
http://www.cs.columbia.edu/~mikepo/papers/gpukeylogger.eurosec13.pdf
"The key idea behind our approach is to monitor the system’s keyboard buffer directly from the GPU via DMA [direct memory access], without any hooks or modifications in the kernel's code and data structures besides the page table," the researchers behind the 2013 paper wrote. "The evaluation of our prototype implementation shows that a GPU-based keylogger can effectively record all user keystrokes, store them in the memory space of the GPU, and even analyze the recorded data in-place, with negligible runtime overhead."
Aside from malware that taps GPUs to mint Bitcoin and other crypto currencies, Ars isn't aware of malicious software actively circulating in the wild that makes use of infected computers' graphics processors. And even then, most or all of those titles run mainly on the CPU and offload only the computationally intensive workloads to the GPU. In March, researchers from Kaspersky Lab documented highly sophisticated malware in the wild that infected firmware that runs 12 different models of hard drives. The group that created the malware had flown under the radar for 14 years.
In its current form Jellyfish is likely to remain a highly niche undertaking, since it requires a dedicated GPU. Since many computers don't contain stand-alone graphics cards, such malware might greatly limit the machines that could be infected. Still, the approach may make sense in certain situations, say for attackers targeting gamers or video enthusiasts, or espionage campaigns where stealth is crucial. And as readers have pointed out in comments below, it's feasible malware could be developed that runs on graphics processors integrated into CPUs.
Post updated to recast the last paragraph to account for integrated graphics processors, and to add details in the second-to-last paragraph about malware infecting hard-drive firmware. ---------------- https://www.phoronix.com/scan.php?page=news_item&px=Intel-SKL-BXT-Firmware-Blobs
Intel Skylake & Broxton To Require Graphics Firmware Blobs
Published on 05 June 2015 06:20 PM EDT
Written by Michael Larabel in Intel
Intel's upcoming Skylake and Broxton hardware will require some binary-only firmware blobs by the i915 DRM kernel graphics driver.
Rodrigo Vivi of Intel's Open-Source Technology Center sent in the pull request for landing these binary files into the linux-firmware repository. Up to now there's been no i915 blobs within the linux-firmware tree.
These first i915 DRM firmware blobs are for Skylake and Broxton for the GuC and DMC. DMC in this context is the Display Microcontroller, which is present in Skylake (Gen9) and newer and used within the display engine to save and restore its state when entering into low-power states and then resuming. The DMC is basically saving/restoring display registers across low-power states separate of the kernel.
The GuC engine on Skylake is responsible for workload scheduling on the parallel graphics engines. Intel explained on 01.org, "GuC is designed to perform graphics workload scheduling on the various graphics parallel engines. In this scheduling model, host software submits work through one of the 256 graphics doorbells and this invokes the scheduling operation on the appropriate graphics engine. Scheduling operations include determining which workload to run next, submitting a workload to a command streamer, pre-empting existing workloads running on an engine, monitoring progress and notifying host SW when work is done." This page also seems to indicate that these firmware blobs are required by the DRM driver rather than being an optional add-on.
The license of these firmware blobs also indicate that redistribution is only allowed in binary form without modification. Beyond that, "no reverse engineering, decompilation, or disassembly of this software is permitted."
These new firmware blobs will certainly have some open-source enthusiasts less excited now about Skylake, Broadwell's successor beginning to ship later this year, and Broxton meanwhile is the new Atom SoC built using the Goldmont architecture and will feature Skylake graphics. If there's any good news out of the situation, at least Intel is shipping these firmware files early rather than NVIDIA that with their months-old hardware still hasn't released their GTX 900 Maxwell firmware files needed by the Nouveau driver to provide open-source hardware acceleration. AMD also tends to be timely with the releasing of their necessary binary-only GPU firmware files for the open-source Linux driver.
_______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
On Tue, 09 Jun 2015 21:03:09 -0700, Christian Gagneraud <chgans@gna.org> wrote:
BTW, every single CPU on this planet has a JTAG[1] port (or equivalent), so with physical access to the hardware you can install persistent backdoor on virtually any CPU/GPU/MCU/RAM/ROM/FPGA/CPLD/DSP/...,
I trust that includes the Freescale chip used by the Novena hardware? [1] Any way for a hardware manufacturer to shave that bitch down so it can't be used by an implant?
and yes the NSA did it: https://blog.pjhoodsco.org/nsa-device-godsurge/
All for the low low price of $500! Lovely. [1] http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&tab=Documentation_Tab&pspll=1&SelectedAsset=Documentation&ProdMetaId=PID/DC/i.MX6Q&fromPSP=true&assetLockedForNavigation=true&componentId=2&leftNavCode=1&pageSize=25&Documentation=Documentation/00610Ksd1nd``Data%20Sheets&fpsp=1&linkline=Data%20Sheets
On Wed, Jun 10, 2015 at 09:47:30AM -0700, Seth wrote:
On Tue, 09 Jun 2015 21:03:09 -0700, Christian Gagneraud <chgans@gna.org> wrote:
BTW, every single CPU on this planet has a JTAG[1] port (or equivalent), so with physical access to the hardware you can install persistent backdoor on virtually any CPU/GPU/MCU/RAM/ROM/FPGA/CPLD/DSP/...,
I trust that includes the Freescale chip used by the Novena hardware? [1] Any way for a hardware manufacturer to shave that bitch down so it can't be used by an implant?
Xray your novena. Compare it to Bunniestudios pgp-signed xray images. Removing the jtag is like welding your hood shut because you're worried about cops tracking you. It pisses off your mechanic and doesn't do anything about the cell phone that's already tracking you. Jtag is incredibly usefull stuff if you are a hardware geek or a kernel and you want to debug why your laptop crashed. If you actually want to make the Novena more secure, start reverse engineering a full-open source toolchain to program the Xilinx FPGA, which is the most likely target for implants, cause we have to use the crappy xilinx tools to program it.
On 6/9/15, Christian Gagneraud <chgans@gna.org> wrote:
... so with physical access to the hardware you can ...
if your threat model is NSA, and they get arbitrary physical access, you have concerns much larger than insecure default JTAG configurations... i'd be happy with a device providing system JTAG controller restrictions (IEEE 1149.1, 1149.6) bound by efuses. most of these features go un-used in practice. :/ best regards,
participants (5)
-
Christian Gagneraud -
coderman -
grarpamp -
Seth -
Troy Benjegerdes