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

Christian Gagneraud chgans at gna.org
Tue Jun 9 20:47:20 PDT 2015


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_vulnerabilities_and_exploits

Krys

>
> 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
>>
>




More information about the cypherpunks mailing list