Slashdot Mirror
Meltdown and Spectre Patches Bricking Ubuntu 16.04 Computers (bleepingcomputer.com)
An anonymous reader writes: Ubuntu Xenial 16.04 users who updated to receive the Meltdown and Spectre patches are reporting they are unable to boot their systems and have been forced to roll back to an earlier Linux kernel image. The issues were reported by a large number of users on the Ubuntu forums and Ubuntu's Launchpad bug tracker. Only Ubuntu users running the Xenial 16.04 series appear to be affected.
All users who reported issues said they were unable to boot after upgrading to Ubuntu 16.04 with kernel image 4.4.0-108. Canonical, the company behind Ubuntu OS, deployed Linux kernel image 4.4.0-108 as part of a security update for Ubuntu Xenial 16.04 users, yesterday, on January 9. According to Ubuntu Security Notice USN-3522-1 and an Ubuntu Wiki page, this was the update that delivered the Meltdown and Spectre patches.
All users who reported issues said they were unable to boot after upgrading to Ubuntu 16.04 with kernel image 4.4.0-108. Canonical, the company behind Ubuntu OS, deployed Linux kernel image 4.4.0-108 as part of a security update for Ubuntu Xenial 16.04 users, yesterday, on January 9. According to Ubuntu Security Notice USN-3522-1 and an Ubuntu Wiki page, this was the update that delivered the Meltdown and Spectre patches.
Kernel 4.4.0-109, which fixes this problem, has already been pushed out.
Apparently, the PTI fix was not quite backported correctly.
For details, see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1741934
Press down arrow at boot menu screen.
Failing to use a particular new kernel is not "bricking". Bricking, as commonly used, means the physical hardware is unrecoverable and needs to be replaced. Recovering a failed Ubuntu kernel means being able to select a different kernel to boot with. This means console access or access to the disk image. These are problematic and can disable production servers. But it's much less destructive than ruining the physical hardware.
From the article comments moments ago:
;-)
> Technically, if you are able to boot with an older kernel, your computer is not bricked.
> You are right. I've updated the title.
Close, but no cigar. When you have to throw the device away, then it's bricked.
1. No, a web page cannot "own" your system. SPECTRE has a proof of concept that'd allow a Javascript program to be able to read data in the same process. It's almost impossible to exploit, but, sure, if you can, you might possibly find that downloading a rogue JS file could copy your bank website's session cookie, if you're not running a recent version of Firefox or Chrome. But nothing SPECTRE allows will allow your computer to be modified in any way.
2. The discussion here is about kernel patches, which are related to MELTDOWN, not SPECTRE. Meltdown cannot be exploited using Javascript. It requires binaries. If you don't run AWS style services, then your current level of security is unlikely to be made worse by Meltdown. And like SPECTRE, MELTDOWN is read only, although in theory it could leak passwords that could allow someone else to hack into your system if it's not properly firewalled.
You are not alone. This is not normal. None of this is normal.
Kernel 4.4.0-109.132 has been issued to fix this
I.e. Yes javascript can read what it wants due to this bug, but good luck trying to get it to read what *you* want like the running encryption key.
Brute force read using an entropy estimation algorithm until you find an "interesting" blob of memory.
Once you find an interesting blob of memory start checking if that memory could be a valid secret key.
JavaScript CAN do this by inferring the memory values through the side-channel, first of all because JavaScript is assembled into machine language (Just-in-Time compilation). Did you see the Javascript POC for Spectre?
LISTING 2: Exploiting Speculative Execution via JavaScript
Manual tweaking of the source code leading up to the snippet above was done to get the value of
simpleByteArray.length in local memory (instead of cached in a register or requiring multiple instructions to
fetch). See Listing 3 for the resulting disassembly output from D8 (which uses AT&T assembly syntax).
The clflush instruction is not accessible from JavaScript, so cache flushing was performed by reading
a series of addresses at 4096-byte intervals out of a large array. Because of the memory and cache
configuration on Intel processors, a series of 2000 such reads (depending on the processor’s
cache size) were adequate evict out the data from the processor’s caches for addresses having
the same value in address bits 11–6 [38]. The leaked results are conveyed via the cache status
of probeTable[n*4096] for n 0..255, so each attempt begins with a flushing pass consisting
of a series of reads made from probeTable[n*4096] using values of n > 256.
Meltdown is easier to exploit, The hacks will get better as well. So it is a very serious problem, information leaks can be very harmful, think passwords and encryption keys. These can then allow for write attacks. Don't underestimate the capabilities of people to find ways to exploit this. It may seem far fetched but time and time again far fetched things have a way of being turned into quite practical exploits.
Meltdown cannot be exploited using Javascript.
Yes it can, even WebKit says so...
REF: https://webkit.org/blog/8048/w...
Most browser vendors are implementing many changes to mitigate Meltdown and Spectre, including things like reducing the precision of high-fidelity timers from 5us to 20us +/- 20us, disabling SharedArrayBuffers and recompiling with Spectre-aware compilers.
People who run remote machines usually have a way to remotely access the console (e.g. IPMI serial-over-lan, terminal server, virtual KVM, VM instance console etc).
The only exception is the retarded Amazon AWS which still doesn't have an interactive console. If AWS instance doesn't boot you have to mount its storage elsewhere to fix it or restore from a snapshot (really a lot of trouble).