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.

Comments

Baby out with the bathwater

[Lab Rat Jason]

It seems that these companies (Microsoft and Ubuntu and others) are forgetting everything about sound software development practices here. They're in such a hurry to deploy patches that they aren't taking the time to fully test them. The cure is worse than the ailment.

Re:Baby out with the bathwater

[king neckbeard]

To be fair, there is a major security flaw covering the majority of desktop CPUs sold over the last two decades. You are correct that they have not done proper testing, but this is on a ridiculous scale.

Re:Baby out with the bathwater

[110010001000]

When you are connected to the Internet (especially through the web) you have many users of your system. For example, any website you visit can run a Javascript program on your machine. With this flaw it can "break out" of your browser. What a mess.

Re:Baby out with the bathwater

[squiggleslash]

There are two bugs here:

Meltdown is Intel-only and requires the ability to run binaries on the victim's computer. If you can run binaries on the victim's computer, you probably already have enough access to do whatever it is you want to do that made you want to hack them in the first place. The extent to which Meltdown adds security issues is miniscule.

Spectre is cross platform and can be exploited with Javascript. With difficulty. But it can. Kinda. There's sorta a proof of concept out there. Which works with one JS engine. And doesn't extract any useful information. But in theory if you know the exact status of the user's browser and you're very lucky you might be able to extract some information from it that you wouldn't normally have access to.

So, what is the rush here? Especially with Meltdown?

The entire fucking industry has gone completely nuts. You'd think that we were back in the 1990s with no memory protection and ActiveX given the panic about this.

And before anyone goes "Yeah, but it's still a problem", so are kernel patches that brick computers. We're bricking computers, and slowing down the ones we don't brick, because we're panicking over this rather than doing this properly.

Re:Baby out with the bathwater

[squiggleslash]

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.

Re:Baby out with the bathwater

[chill]

Meltdown is Intel-only and requires the ability to run binaries on the victim's computer. If you can run binaries on the victim's computer, you probably already have enough access to do whatever it is you want to do that made you want to hack them in the first place. The extent to which Meltdown adds security issues is miniscule.

That isn't really accurate. Meltdown is potentially devastating for virtual machines and set-ups like shared hosting. Getting a VM slice on a much larger machine is where Meltdown scares cloud-deployed companies. Spin up a small VM, execute Meltdown exploit, and compromise who else is on that host. Ditto with a shared web host.

Re:Baby out with the bathwater

[Merk42]

You know what's pushing this on the average Joe? DRM. Microsoft can't let those DRM keys leak... and now that the flaw is known, that's exactly what *could* happen. This isn't about user's data falling into evil-hacker's hands...

Ah Slashdot, where a vulnerability from Intel and a bad patch from Canonical, is still, somehow, Microsoft's fault.

Re:Baby out with the bathwater

[mysidia]

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
 

1 if (index < simpleByteArray.length) {
2 index = simpleByteArray[index | 0];
3 index = (((index * TABLE1_STRIDE)|0) & (TABLE1_BYTES-1))|0;
4 localJunk ^= probeTable[index|0]|0;
5 }

... To obtain the x86 disassembly of the JIT output during development, the command-line tool D8 was used.

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.

LISTING 3: Disassembly of Listing 2

1 cmpl r15,[rbp-0xe0] ; Compare index (r15) against simpleByteArray.length

2 jnc 0x24dd099bb870 ; If index >= length, branch to instruction after movq below

3 REX.W leaq rsi,[r12+rdx*1] ; Set rsi=r12+rdx=addr of first byte in simpleByteArray

4 movzxbl rsi,[rsi+r15*1] ; Read byte from address rsi+r15 (= base address+index)

5 shll rsi, 12 ; Multiply rsi by 4096 by shifting left 12 bits}\%\

6 andl rsi,0x1ffffff ; AND reassures JIT that next operation is in-bounds

7 movzxbl rsi,[rsi+r8*1] ; Read from probeTable

8 xorl rsi,rdi ; XOR the read result onto localJunk

9 REX.W movq rdi,rsi ; Copy localJunk into rdi

Re:Baby out with the bathwater

[Eravnrekaree]

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.

Bricked!!?!?! Oh wow!

[Anonymous Coward]

"have been forced to roll back to an earlier Linux kernel image."

So, not actually bricked then...

WORDS MEAN THINGS!

Re:Bricked!!?!?! Oh wow!

[AvitarX]

Doesn't this just mean pressing down in grub once, then setting it to use that kernel by default?

This is barely even a slight annoyance.

Re:Bricked!!?!?! Oh wow!

[El_Muerte_TDS]

It's 2018, we have SmartBricks now. You can change the software of your SmartBricks.

Re:Bricked!!?!?! Oh wow!

[billyoc903]

Yeah, but who's going to click on a link that says "Ubuntu kernels rolled back to the one from the day before yesterday"? Do you know ANYTHING about social media marketing strategies? It's like you're not even trying.

Re:Bricked!!?!?! Oh wow!

[ThanatosMinor]

Article title updated because we used the term "bricking" incorrectly. Bleeping Computer regrets the error.

We apologise for the fault in the title. Those responsible have been sacked.

Re:Bricked!!?!?! Oh wow!

[GameboyRMH]

I would say that if a software hack, or even a simple hardware hack with common tools can fix it, it's not bricked. If you have to get out a JTAG adapter, then it's bricked.

Re:Bricked!!?!?! Oh wow!

[religionofpeas]

We apologise for the fault in the title. Those responsible have been sacked.

You mean, they've been bricked.

Re:Bricked!!?!?! Oh wow!

[fibonacci8]

We apologise for the fault in the title. Those responsible have been sacked.

You mean, they've been bricked.

A brick once bit my sister.

Re:Bricked!!?!?! Oh wow!

[k.a.f.]

Close, but no cigar. When you have to throw the device away, then it's bricked.

Re:Bricked!!?!?! Oh wow!

[viperidaenz]

Nah, if you have to press a key during the boot process to bring up a boot menu and select the previous kernel, then it's bricked.

Ultimate security

[OrangeTide]

Let those hackers try and get into my system now!

Already fixed...

[Anonymous Coward]

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

It is *NOT* bricking!

[Qbertino]

Bricking is the equivalent of applying a killpoke. A software action that makes the hardware henceforth unusable.

This just screws up the kernel and requires you to set up a fresh one, perhaps reinstalling the core system. On Linux this is usually nothing more than a minor annoyance.

Again: it's not bricking. Bricking is when a software update or piece of code renders my smartphone not more useful than a brick and irreversibly so.

Stop using the word just because it's new and describes something significant. It doesn't make your news more interesting, it makes your news false.

Thank you.

Not bricked #2305473

[Fly Swatter]

Press down arrow at boot menu screen.

Failed reboot is not "bricking"

[Antique Geekmeister]

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.

Not "bricked" - Misleading title

[michaelcole]

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.

Not everyone is affected/Nobody "Bricked"

[mykepredko]

Just saw the headline and panicked, checking my Linux systems (all running ubuntu 16.04 LTS) and did a quick check:

myke@mimeticsL01:~$ uname -a
Linux mimeticsL01 4.4.0-108-generic #131-Ubuntu SMP Sun Jan 7 14:34:49 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
myke@mimeticsL01:~$

I've never had a problem with Ubuntu updates (although I RFTA, it sounds like all Ubuntu users have an issue at one time or another). I suspect that the kernel update was tested before it was released so this updates affects some subset of the systems out there.

Like many other people, I was very concerned when i saw the headline saying the updated was "bricking" systems - whoever wrote the headline needs to have the term "bricking" explained to them (ideally with an actual brick).

In the future, msmash, you might want to be a bit less sensational in the headlines and make sure you understand if the terms used in it are correct.

Re:A web page can now own your system

[scdeimos]

Meltdown cannot be exploited using Javascript.

Yes it can, even WebKit says so...

Meltdown means that userland code, such as JavaScript running in a web browser, can read kernel memory. Not all CPUs are affected by Meltdown and Meltdown is being mitigated by operating system changes. Mounting a Meltdown attack via JavaScript running in WebKit requires first bypassing branch-based security checks, like in the case of a Spectre attack. Therefore, Spectre mitigations that fix the branch problem also prevent an attacker from using WebKit as the starting point for Meltdown.

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.