Fwd: [Cryptography] Did Intel just execute its warrant canary ?

[Troy Benjegerdes]

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 at pipeline.com>
> Date: Mon, Jun 8, 2015 at 6:24 PM
> Subject: [Cryptography] Did Intel just execute its warrant canary ?
> To: cryptography at 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-offer-superior-stealth-and-computing-power/
> 
> 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 at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
> 

-- 
----------------------------------------------------------------------------
Troy Benjegerdes                 'da hozer'                  hozer at 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