Update: 2020.03

“The newly developed Rowhammer- attack TRRespass can crack the RAM-a security mechanism by many DDR4-DRAM-modules as well as LPDDR4 Chips. Until now, these were considered to be almost immune to Rowhammer attacks.”

https://www.com-magazin.de/news/sicherheit/software-hammer-ram-schutz-attackiert-2515621.html

Update: 2019.10

Zombieload is back.

“This time a new variant (v2) of the data-leaking side-channel vulnerability also affects the most recent Intel CPUs, including the latest Cascade Lake, which are otherwise resistant against attacks like Meltdown, Foreshadow and other MDS variants (RIDL and Fallout).” (src: thehackernews.com)

Update: 2019.05 Microsoft, Apple, Google Release Updates to Address Microarchitectural Data Sampling (MDS) Vulnerabilities Impacting Most Chips Made by Intel 

Millions of computers powered by Intel processors are affected by vulnerabilities that can be exploited by malicious actors to obtain potentially sensitive information. Intel and other tech giants have already released patches and mitigations.

The side-channel attack methods, named ZombieLoad, RIDL (Rogue In-Flight Data Load), and Fallout, are similar to the notorious Meltdown and Spectre, which researchers first disclosed in January 2018. At the time, experts accurately predicted that other similar speculative execution attacks would be discovered.

The attack methods work against both PCs and cloud environments, and they can be launched against most Intel CPUs made in the past decade. The techniques can be used to get applications, the operating system, virtual machines and trusted execution environments to leak information, including passwords, website content, disk encryption keys and browser history.

ZombieLoadFor example, experts have demonstrated that hackers can use the ZombieLoad attack, which is a subclass of RIDL, to obtain a user’s browsing history even if the victim surfs the web from a virtual machine and uses the Tor anonymity network. (src: securityweek.com)

Update: 2019.04 “Speculative Execution”

Update: 2019.02: ExSpectre: Hiding Malware in Speculative Execution

“Co-authored by three computer science boffins from the University of Colorado, Boulder in the US – Jack Wampler, Ian Martiny, and Eric Wustrow – the paper, “ExSpectre: Hiding Malware in Speculative Execution,” describes a way to compile malicious code into a seemingly innocuous payload binary, so it can be executed through speculative execution without detection.” (src: theregister.co.uk)

Update: 2019.01: Redhat CPU fixes overview: Is CPU microcode available to address CVE-2017-5715 via the microcode_ctl package?

https://access.redhat.com/articles/3436091

Update: 2018.12: ForeShadow – guest reading Level1 Cache of host

ForeShadow (known as L1 Terminal Fault (L1TF) by Intel)[1][2] is a vulnerability that affects modern microprocessors that was first discovered by two independent teams of researchers in January 2018, but was first disclosed to the public on 14 August 2018.[18] The vulnerability is a speculative execution attack on Intel processors that may result in the disclosure of sensitive information stored in personal computers and third-party clouds.[1]

https://www.golem.de/news/foreshadow-l1tf-intel-cpus-ermoeglichten-unberechtigtes-auslesen-von-speicher-1808-136008.html

Update: 2018.07 – it’s getting worse – steal bytes WITHOUT RUNNING ANY CODE

this attack is SUPER SLOW but it could steal arbitrary Bytes (how many bytes are one root password? (well yes you would to have to know in advance where exactly the root password is in memory and then it is probably (hopefully) not in an unencrypted state but in an sha512sum hashed/encrypted state) from routers and servers WITHOUT RUNNING ANY CODE on the system itself?

https://misc0110.net/web/files/netspectre.pdf

mirror: netspectre.pdf

src: https://www.heise.de//security/meldung/NetSpectre-liest-RAM-via-Netzwerk-aus-4121831.html?wt_mc=nl.heisec-summary.2018-07-30

another reason, why JavaScript should be avoided in WebDevelopment

(this will hit the AngularJS, JQuery and NoScript guys BADLY, Richard Stallmann is right.)

Websites should get rid of JavaScript all together – if a website does not work – with NoScript turned on – it sucks.

https://vvdveen.com/publications/dimva2018.pdf

mirror: GuardION – Practical Mitigation of DMA-based – Rowhammer Attacks on ARM – Vrije Universiteit Amsterdam.pdf

Hello , this is . And these are your passwords.

… intel, i think you just broke the internet.

src: https://github.com/IAIK/meltdown

Update: Android and ARM affected – iPhones too?

Over the last two years, the Rowhammer bug transformed from a hard-to-exploit DRAM disturbance error into a fully weaponized attack vector”

Paper on RowHammer: https://gruss.cc/files/rowhammerjs.pdf

mirror download for paper: Paper on Rowhammer.js – A Remote Software-Induced Fault Attack in JavaScript Daniel Gruss, Clementine Maurice and Stefan Mangard Graz University of Technology Austria – rowhammerjs.pdf

Doesn’t this sound great?

I wonder when i can install the first JavaScript based exploit on my website X-D and connecting an ARM-based SmartPhone to the internet becomes equally dangerous than an non-updated Windows 7 or Windows XP. (you can count down 10 seconds until the first virus is remotely installed)

2015: RowHammer.js (src)

“it’s a piece of JavaScript code that can escape a web browser’s security sandbox and gain access to the physical memory of your computer.”

“Insanity: doing the same thing over and over again and expecting different results.”
Albert Einstein – Who did not live long enough to see Rowhammer

ccc 2015:

https://media.ccc.de/v/32c3-7197-rowhammer_js_root_privileges_for_web_apps

Google is downplaying the problem.

the paper continues:

“Researchers demonstrated exploits not only against desktop computers, but also used single bit flips to compromise the cloud and mobile devices, all without relying on any software vulnerability.

Since hardware-level mitigations cannot be backported, a search for software defenses is pressing.

Proposals made by both academia and industry, however, are either impractical to deploy, or insufficient in stopping

all attacks: we present rampage, a set of DMA-based Rowhammer attacks against the latest Android OS, consisting of (1) a root exploit, and (2) a series of app-to-app exploit scenarios that bypass all defenses.
To mitigate Rowhammer exploitation on ARM, we propose guardion, a lightweight defense that prevents DMA-based attacks – the main attack vector on mobile devices – by isolating DMA buffers with guard rows.
We evaluate guardion on 22 benchmark apps and show that it has a negligible memory overhead (2.2 MB on average).
We further show that we can improve system performance by re-enabling higher order allocations after Google disabled these as a reaction to previous attacks.”

src: https://vvdveen.com/publications/dimva2018.pdf

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

risc v is very new: https://wiki.debian.org/InstallingDebianOn/SiFive/HiFiveUnleashed

buy here: https://www.crowdsupply.com/sifive/hifive1

why no ethernet port per default? Freedom U540

From: David Woodhouse 
Date:  Sun Jan 21 2018 - 15:28:51 EST

On Sun, 2018-01-21 at 11:34 -0800, Linus Torvalds wrote:
 > All of this is pure garbage.
 > 
 > Is Intel really planning on making this shit architectural? Has
 > anybody talked to them and told them they are f*cking insane?
 > 
 > Please, any Intel engineers here - talk to your managers.Â
 
 If the alternative was a two-decade product recall and giving everyone
 free CPUs, I'm not sure it was entirely insane.

 Certainly it's a nasty hack, but hey â the world was on fire and in the  end we didn't have to just turn the datacentres off and go back to goat  farming, so it's not all bad.

my comment: that is exactly what Intel OUGHT to do: recall all CPUs of the last 20 years.

IMHO the “motive” of intel/AMD is pretty clear: “yes we admit our product is flawed – we try to give you a choice: flip the IBRS_ALL bit and get a 20% speed penalty but (probably) fix the security whole. Or leave the whole wide open because your infrastructure is physically shielded against intruders and NOT connected to the internet.”

Another possibility: fire their managers close down and start over under a new name with a new design and a hacking team that tries to constantly break things?

That would be the clean thing to do to save their economic asses uh i mean assets.

But that will not be enough: Intel / AMD / CPU and Hardware manufacturer: To avoid future mistakes follow the UNIX philosophy: 1. Simplify 2. Simplify 3. Simplify – everything.

Even Dr Sheldon Cooper or Einstein makes mistakes: Complexity is THE ENEMY in this game for perfection. (that only god and/or nobody can achieve, check out the “perfect software” paradigm)

if you don’t believe me, you might believe: McIlroy:

src: https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s07.html

“We used to sit around in the Unix Room saying, ‚What can we throw out? Why is there this option?‘

It’s often because there is some deficiency in the basic design — you didn’t really hit the right design point.

Instead of adding an option, think about what was forcing you to add that option.”

Never the less errors will be made: If architectural / design errors surface that can not be fixed by software – there should be some kind of recall mechanism, but this is expensive for the producer, so what probably happens is: Make the customer / re-seller bear the risk: If you want to run a Intel based computer, you will have to agree to some disclaimer like on software:

“THIS CPU IS SOLD “AS IS” WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
You are solely responsible for determining the appropriateness of using or redistributing this CPU and assume any risks associated with Your exercise of permissions under this License.”

Means: We don’t know if we just sold you a bunch of crap technology with unfixable security wholes – because this product is so complex – we kind of lost control over it’s quality – so all risk is on YOU!

That is just how mankind is: Apes with complex technology and technology dependent lifestyles that could get out of hand if no learning curve existed: so simplify, simplify, simplify!

Let’s just hope your lifestyle has no unfixable security problems.

Even worse: The monetary system actually might “encourage” to repeat mistakes such as war – because it is good money for the “hardware” (weapons) manufacturers.

And that is exactly what Intel will do: Save it’s ass – despite the flood (32 and more) lawsuits.

So Intel tries to sell it’s fix as “security” and will not compensate the damaged datacenter owners – which probably are forced to rebuy, rebuy, rebuy Intel’s new CPU or go to an alternative CPU manufacturer that does not have this trouble (is there still one? Apple gave up on that… MISTAKE! another reason why monoculture sucks – not only in farming and nature).

Look at traffic: You could go by train, by car or by bus or by airplane or bicycle or horse or elephant or soon: DroneTaxi or Elon’s HyperLoop or simply: walk.

There are basically completely different “methods” of doing the same thing: travel distances and/or transport stuff.

And thus provide redundancy for the: travel/transport problem.

But redundancy costs money… repeating mistakes does too.

Oracle SPARC has the same problems.

This could be THE CHANCE for alternative CPU manufactureres and maybe even: Open Hardware?

“The RISC-V Foundation says that no currently announced RISC-V CPU is vulnerable to Meltdown and Spectre”

“Until recently, RISC-V hadn’t seen much adoption in industry, but, in the past two years, Nvidia and Western Digital both announced that they would be adopting RISC-V CPUs. In light of the recent Meltdown/Spectre issue, the RISC-V foundation has released a statement on the vulnerabilities’ impact on RISC-V development.”

https://www.tomshardware.com/news/risc-v-not-vulnerable-meltdown-spectre-cpu-bugs,36231.html

Home

https://en.wikipedia.org/wiki/RISC-V

https://github.com/freechipsproject/rocket-chip

“As CISC raises too many verification problems, and a closed-source chip design cannot be trusted, the only solution is open-source RISC:”

openSPARC T1

OpenSPARC T1 is the open source version of the UltraSPARC T1 processor, a multi-core, 64-bit multiprocessor. The UltraSPARC T1 processor with CoolThreads technology was the highest-throughput and most eco-responsible processor ever created when it became available in the UltraSPARC T1 system. It was a breakthrough discovery for reducing data center energy consumption, while dramatically increasing throughput. Its 32 simultaneous processing threads, drawing about as much power as a light bulb, gave customers the best performance per watt of any processor available.

OpenSPARC T1 source components are covered under multiple open source licenses. The majority of OpenSPARC T1 source code is released under the GNU General Public License. GNU General Public License Source based on existing open source projects will continue to be available under their current licenses. Binary programs are released under a binary Software License Agreement.

 Docs & Specs
 Source Browser
 Download
 FAQ

openSPARC T2

https://github.com/openrisc

https://github.com/riscv https://github.com/riscv/riscv-qemu

Is Open Source RISC-V Ready to Take on Intel, AMD, and ARM in the Data Center?

http://www.datacenterknowledge.com/hardware/open-source-risc-v-ready-take-intel-amd-and-arm-data-center

Open source startup SiFive introduces a single board computer running Linux on the open RISC-V architecture. Is the data center next?
costly RISC-V mainboard and CPU: https://www.crowdsupply.com/sifive/hifive-unleashed

LinuxGizmos.com:”Aside from being open source and customizable, one of the main benefits of RISC-V is that it is fully modern, purpose built, and unburdened with legacy code.”

https://www.heise.de/newsticker/meldung/RISC-V-Entwickler-Board-mit-64-Bit-Chip-und-Linux-ab-Juni-3960308.html

… but only if we (can) buy it.

Debian supported CPU architectures:

Motorola 680x0:      | m68k
       - Atari            |   - atari
       - Amiga            |   - amiga
       - 68k Macintosh    |   - mac
       - VME              |   - bvme6000
                          |   - mvme147
                          |   - mvme16x
                          | 
     DEC Alpha            | alpha
                          |   - generic
                          |   - jensen
                          |   - nautilus
                          | 
     Sun SPARC            | sparc
                          |   - sun4cdm
                          |   - sun4u
The UltraSPARC class systems fall under the sun4u identifier,
and are supported using the sun4u set of install images.
                          |   
     ARM and StrongARM    | arm
                          |   - netwinder
                          |   - riscpc
                          |   - shark
                          |   - lart
                          | 
     IBM/Motorola PowerPC | powerpc
       - CHRP             |   - chrp
       - PowerMac         |   - powermac, new-powermac
       - PReP             |   - prep
       - APUS             |   - apus
                          | 
     HP PA-RISC           | hppa
       - PA-RISC 1.1      |   - 32
       - PA-RISC 2.0      |   - 64
                          |
     Intel ia64-based     | ia64
                          |
     MIPS (big endian)    | mips
       - SGI Indy/I2      |  - r4k-ip22
                          | 
     MIPS (little endian) | mipsel
       - DEC Decstation   |  - r4k-kn04
                          |  - r3k-kn02
                          | 
     IBM S/390            | s390
                          |  - tape
                          |  - vmrdr

… the mail continues:

 
 As a hack for existing CPUs, it's just about tolerable â as long as it
 can die entirely by the next generation.
 
 So the part is I think is odd is the IBRS_ALL feature, where a future
 CPU will advertise "I am able to be not broken" and then you have to
 set the IBRS bit once at boot time to *ask* it not to be broken. That
 part is weird, because it ought to have been treated like the RDCL_NO
 bit â just "you don't have to worry any more, it got better".
 
 https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf
 

 

We do need the IBPB feature to complete the protection that retpoline
 gives us â it's that or rebuild all of userspace with retpoline.
 
 We'll also want to expose IBRS to VM guests, since Windows uses it.
 
 I think we could probably live without the IBRS frobbing in our own
 syscall/interrupt paths, as long as we're prepared to live with the
 very hypothetical holes that still exist on Skylake. Because I like
 IBRS more... no, let me rephrase... I hate IBRS less than I hate the
 'deepstack' and other stuff that was being proposed to make Skylake
 almost safe with retpoline.

http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04601.html

“As a programmer, it is your job to put yourself out of business. What you do today can be automated tomorrow.”

Doug McIlroy

Damn this guy is a philosopher.

liked this article?

  • only together we can create a truly free world
  • plz support dwaves to keep it up & running!
  • (yes the info on the internet is (mostly) free but beer is still not free (still have to work on that))
  • really really hate advertisement
  • contribute: whenever a solution was found, blog about it for others to find!
  • talk about, recommend & link to this blog and articles
  • thanks to all who contribute!
admin