Meltdown and Spectre Patches Bricking Ubuntu 16.04 Computers (bleepingcomputer.com) 233
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.
Baby out with the bathwater (Score:5, Insightful)
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 (Score:5, Insightful)
Comment removed (Score:4, Insightful)
Re:Baby out with the bathwater (Score:5, Insightful)
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 (Score:5, Informative)
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.
Re: (Score:2)
If you're running on a VM in the cloud, it's not that hard for someone else to run an executable (in their own VM) on the same server. Meltdown can cross VMs.
That's why the big rush to a workaround patch.
Re: (Score:2)
I was just pointing out that this isn't the big nothing squiggleslash was claiming. The problem is real and the exploit is practical in several very large environments.
People not in those environments probably should have had a better way to sit back a few days and wait for bug reports.
Re: (Score:2)
To be fair, there is a major security flaw covering the majority of desktop CPUs sold over the last two decades.
It's been around for two decades, and known about for years based on earlier reports, and the world did not some to an end during that time. Taking a few months for proper testing before deploying isn't going to be an issue.
People don't install Ubuntu to be on the bleeding edge.
Re: (Score:2)
Re:Baby out with the bathwater (Score:5, Insightful)
Re: (Score:3, Insightful)
In a controlled environment or on a system that you already 0wn that would be a problem. However if I go to a website right now there's no reliable way of accessing a desired chunk of memory from another process without knowing where that memory is in the first place or without dumping absolutely everything and manually looking afterwards.
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.
This attack would work w
Re:Baby out with the bathwater (Score:4, Informative)
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.
Re: (Score:3)
A typical desktop or laptop or tablet computer is no longer truly a single-user computer. Most of these computers have web browsers, which by default are configured to download and execute code written by other people to serve their interests. Perhaps your computers don't do this anymore, but your mom's neighbor's former roomm
Re: (Score:3)
With all the crap that runs on a machine, multiple users running at the same time is a must. The days of a cooperative multitasking OS are long gone. You can have a single user OS with preemptive multitasking (OS/2, for example), but you then run into issues where if one item gets infected, the whole machine is pwned. The fact that Windows has UAC has probably stopped/prevented a lot of infections, and is why Microsoft put it in after XP.
Operating systems need not just to be multiuser, but have varying c
Re: (Score:2)
No, they will login as your father’s brother’s nephew’s cousin’s former roommate. Which will give them access to absolutely nothing related to you. ;)
Re:Baby out with the bathwater (Score:5, Informative)
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.
Re: (Score:3)
This is common sense and it's what I used to believe too. I totally don't fault you for thinking that.
Now I direct you to section 4.3 of the Spectre paper [spectreattack.com]. You need to read it. This isn't about "you're wrong," it's about "here's something very interesting."
And if you're anything like me, you will
Re: (Score:2)
I have read the white paper and now think I understand,
You are not doing an out of bounds memory access at all, what you are doing is making the predictive out of bounds check, that gets loaded into in bounds memory
the only thing that is an issue is getting an accurate enough time, if your machine is fast enough might not work, window.performance.now()
Re: (Score:2)
Except when it is. Javascript is very often compiled with JIT to machine code and there exist Spectre exploits that can read whole browser process memory from Javascript. It needs high precision timers and JIT, but it works. Thats why MS in their Spectre mitigation for Edge reduces timer precision and introduces extra jitter.
Re:Baby out with the bathwater (Score:5, Funny)
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:A web page can now own your system (Score:5, Informative)
Meltdown cannot be exploited using Javascript.
Yes it can, even WebKit says so...
REF: https://webkit.org/blog/8048/w... [webkit.org]
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.
Comment removed (Score:5, Informative)
Re: (Score:2)
That sounds like a pretty crappy sandbox.
NB: Mozilla released a security update for Firefox already.
Vast permutations of hardware, 3rd party driver ? (Score:2)
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.
Both Microsoft and Ubuntu are plagued by the vast permutations of hardware out there, all the combinations of motherboard, cpu, video, etc. Aren't there identified problems with various anti-virus software? Did some driver developer out there try something tricky too that is incompatible with the fix(es)? Historically various problems with Windows came from 3rd party drivers not necessarily Microsoft itself, perhaps Ubuntu is having similar problems?
Re: (Score:2)
Why bother with testing when there are a lot of paying beta testers around? Windows 10 anyone?
Re: (Score:2)
To be fair it must be a nightmare to fix something like this so the fix works on a wide variety of configurations and doesn't kill performance on any of them. Especially if news of the exploit gets leaked or discovered independently.
https://en.wikipedia.org/wiki/... [wikipedia.org]
On March 27, 2017 researchers at Austria's Graz University of Technology developed a proof-of-concept that could grab RSA keys from Intel SGX enclaves running on the same system within five minutes by using certain CPU instructions in lieu of a fine-grained timer to exploit cache DRAM side-channels.
In June 2017, KASLR was found to have a large class of new vulnerabilities. Research at Graz University showed how to solve these vulnerabilities by preventing all access to unauthorized pages. A presentation on the resulting KAISER technique was submitted for the Black Hat congress in July 2017, but was rejected by the organizers. Nevertheless, this work led to kernel page-table isolation (KPTI, originally known as KAISER) in 2017, which was confirmed to eliminate a large class of security bugs, including the not-yet-discovered Meltdown - a fact confirmed by the Meltdown authors.
In July 2017, research made public on the CyberWTF website by security researcher Anders Fogh outlined the use of a cache timing attack to read kernel space data by observing the results of speculative operations conditioned on data fetched with invalid privileges.
Meltdown was discovered independently by Jann Horn from Google's Project Zero, Werner Haas and Thomas Prescher from Cyberus Technology, as well as Daniel Gruss, Moritz Lipp, Stefan Mangard and Michael Schwarz from Graz University of Technology. The same research teams that discovered Meltdown also discovered a related CPU security vulnerability now called Spectre.
On October 2017, Kernel ASLR support on amd64 was added in NetBSD-current, making NetBSD the first BSD system to support kernel address space layout randomization (KASLR).
On November 14, 2017, security researcher Alex Ionescu publicly mentioned changes in the new version of Windows 10 that would cause some speed degradation without explaining the necessity for the changes, just referring to similar changes in Linux.
After affected hardware and software vendors had been made aware of the issue on July 28, 2017, the two vulnerabilities were made public jointly, on January 3, 2018, several days ahead of the coordinated release date of January 9, 2018 as news sites started reporting about commits to the Linux kernel and mails to its mailing list. As a result, patches were not available for some platforms, such as Ubuntu, when the vulnerabilities were disclosed.
Re: (Score:2)
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.
Is it really that they are forgetting or do they just not care?
Re: (Score:2)
Re: (Score:2)
No: it would appear the standard alternative to a best effort is to make a fairly pathetic, half-assed effort.
Re: (Score:2)
Running this very thing in AWS right now (Score:1)
Re: (Score:2)
Re: (Score:2)
******* 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 22:00:44 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
My CPU is: Intel Core i3-2120 CPU @ 3.30Ghz
Updated my Linux Mint 18.3 Cinnamon 64 bit this afternoon and all is well after reboot.
Ran sysbench tests on CPU and File IO before and after and noticed no difference.
Bricked!!?!?! Oh wow! (Score:5, Insightful)
"have been forced to roll back to an earlier Linux kernel image."
So, not actually bricked then...
WORDS MEAN THINGS!
Re:Bricked!!?!?! Oh wow! (Score:5, Interesting)
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: (Score:3)
Fair point.
It'd be nice if it could fall back to a last known good config like on Windows (not that that ever works, but the way Ubuntu seems to keep old ones seems like it could be made to work).
Exactly. The headline is rubbish. Part of the kernel installation is to leave the last one in the menu. It's just the new one is a default. If grub is configured with 'savedefault', then the last picked kernel will be chosen for future boots.
Re:Bricked!!?!?! Oh wow! (Score:4, Informative)
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).
Re:Bricked!!?!?! Oh wow! (Score:5, Funny)
It's 2018, we have SmartBricks now. You can change the software of your SmartBricks.
Re:Bricked!!?!?! Oh wow! (Score:4, Insightful)
Re:Bricked!!?!?! Oh wow! (Score:5, Funny)
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! (Score:5, Funny)
We apologise for the fault in the title. Those responsible have been sacked.
You mean, they've been bricked.
Re:Bricked!!?!?! Oh wow! (Score:5, Funny)
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: (Score:2)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Exactly. If the kernel scrambled the UEFI files or hosed the firmware beyond recovery, that is a bricking. Having to boot from an earlier kernel in GRUB2... well, that is just an "oh shit", like anything else on the OS side. Definitely not good, but it doesn't mean that you have to buy a new motherboard.
I think part of the confusion come in with a lot of appliances blurring the line between BIOS and OS, combined with the lack of control of the OS. A kernel panic on a phone preventing it from starting co
Re: (Score:2)
Shhh! Lennart might be lurking.
Re:Bricked!!?!?! Oh wow! (Score:5, Insightful)
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! (Score:5, Informative)
Re: (Score:2)
Re: (Score:2)
No, when an end user can't bring the device back to life without spending money going out and buying a JTAG programmer, THEN it is bricked.
If the software problem can't be recovered from the software domain it is bricked. Just because the manufacturer can revive it doesn't make it any less bricked.
Re: (Score:2)
By that reasoning, only [effective] kill switches or DRM will brick a device. Remarkably, most devices these days can still be repaired with a hot air gun.
Re:Bricked!!?!?! Oh wow! (Score:5, Funny)
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.
Re: (Score:2)
No. That is trashed, but not bricked. Bricked is when it is not recoverable by means available to members of the general public - not just "stupid Lusers". Bricked is not just when it won't boot a bootable image, but when it does not even appear to try.
Re: (Score:2)
I must have forgot the </sarcasm>
Re: (Score:2, Insightful)
No when Microsoft did it, it was not bricking. Several people even pointed it out in the very comments of that Slashdot article.
On the other hand, you have selective memory or didn't even bother to check, because your are a Microsoft fanboi/shill.
Re: (Score:2)
YMMV
Re: (Score:2)
That was mean
Re: Bricked!!?!?! Oh wow! (Score:2)
Ultimate security (Score:5, Funny)
Let those hackers try and get into my system now!
Re: (Score:2)
Already fixed... (Score:5, Informative)
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
Re: Already fixed... (Score:2)
Re: (Score:2)
It is *NOT* bricking! (Score:5, Insightful)
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.
Re: (Score:2, Insightful)
It's part of a larger Millennial Trend to make their stupid, worthless "contributions" seem much more impressive.
"literally" -> absolutely, positively NOT literally
"hacking" -> doing something differently, like putting avocado on toast
"crypto" -> some retarded cartoon-backed pseudo currency
Mint 18.2 w/ 4.4.0-108.131 (Score:2)
Not bricked #2305473 (Score:5, Informative)
Re: (Score:2)
Not all environments allow access to boot menue screens. In particular, virtualized hosts do not allow access unless the owner of the virtual server elects to allow graphical access to the hypervisor. This is technologically feasible but proscribed for basic security reasons by various virtualization providers, such as AWS and many locally administered virtualiztion toolkits.
You keep using that word... (Score:3)
I don't think it means what you think it means. If working around the bug means selecting a different item from the menu to boot, it's not really bricked.
Re: (Score:2)
Failed reboot is not "bricking" (Score:5, Informative)
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.
Re: Failed reboot is not "bricking" (Score:3)
As most of these devices were locked down regarding firmware and encryption, to limit rooting the device, etc., most of the causes were software r
No problem with 16.04.3 LTS (Score:2)
Wow! Guess I'm fortunate to have a newer kernel. I was running the 4.10 kernel and the update upgraded me to the 4.13 kernel. All my computers (including one running the equivalent level of Linux Mint) booted just fine with the 4.13.0-26 kernel.
Not "bricked" - Misleading title (Score:5, Informative)
> 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" (Score:5, Insightful)
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: (Score:2)
"Bricking" (Score:3)
This is not what "bricking" is. If you can fix it (i.e. roll back to an earlier kernel image in this case), it's simply a botched kernel update.
C'mon, msmash.
No bricking here! Just.. (Score:2)
All new crashes:
[ 22.462856] kernel BUG at /build/linux-J4_1pC/linux-4.4.0/mm/slub.c:3627!
[ 22.462874] invalid opcode: 0000 [#1] SMP
Yay for regressions.
Thank the FSM... (Score:2)
I'd previously upgraded to 4.10.x (for some hardware support). Xenial still wanted me to do the 4.4.0-108 kernel. Needless to say, I didn't do it.
NOT "Bricking", read TFA (Score:2)
A bricked machine is completely useless. If you can roll back to an earlier kernel, you are not bricked. Read the article and don't just parrot a clickbait headline.
Bricking vs Bricking (Score:2)
IMO, there's a difference between bricking a Linux box vs a Windows box. Unless you have a System 76, you probably installed Linux yourself, or had your nephew do it. That means you have the install media and can reinstall the damn thing.
OTOH, Windows machines don't come with install disks. If Windows is foobar, then for all intensive porpoises, it's bricked (short of taking it to a PC repair place that will unbrick it for what you can pay for a new one).
Kernel 4.4.0-109.132 has been issued to fix this (Score:3, Informative)
Thank God for Slashdot... (Score:2)
...and a slow ISP(Frontier). I was actually in the process of downloading the update when I stumbled across this article and canceled the update. It is the xxxx.109.x kernel update but I've seen at least 1 report of that still having an issue here. I'll just wait a couple of days for this to get sorted out....
Re: (Score:2)
https://news.slashdot.org/comm... [slashdot.org]
might be 4.4 (Score:2)
Re: (Score:2)
Ubuntu 16.04.3 with kernel 4.4.0-109-generic (Score:2)
Absolutely no disturbances with Ubuntu 16.04.3 with kernel 4.4.0-109-generic.
Hysterical headline (Score:2)
The headline: "Meltdown and Spectre Patches Bricking Ubuntu"
The reality: The new kernel you upgraded to won't boot. So at the grub menu, scroll down to your old kernel and boot that. Good thing this kind of issue was anticipated and is easy to deal with as a result.
It's not bricking (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Unlike last time this article is click bait, if you can roll back the PC it isn't bricked.
My patching script includes purging of all old kernel versions.
... but what about...
I said ALL! It bricked. I need a new laptop now. Can't be helped.
Re: More bricking... (Score:2)
Or you could just boot the new HDD, and pull the data off the old drive into the new install. Presto! Laptop works again.
Re: (Score:2)
If you thought you're PC was bricked, you REALLY want to see this...
Re: (Score:2)
Really? Let me try i...***Signal Lost***
Not when it's horribly exaggerated (Score:2)
If Microsoft released an update that required two key presses to fix and some moron claimed in the headline that it "bricked" computers, we'd have chorus of people saying "the author is an idiot. That's not bricked.". I imagine we'll get the same response today.
It's like most of MD Solar's submissions. There may be a kernel of truth somewhere in them, but they are so wildly exaggerated that the appropriate response is an outpouring of derision for the misleading articles and headlines, not hunting for s
Re: Microsoft's problem? (Score:2)
Ubuntu may be a "free" OS, built around what was once a hobby for a bunch of nerds. That doesn't excuse where it is strategically positioned. Ubuntu is now included with Microsoft Windows. It is a part of a truly commercial desktop system. They are backed by a commercial entity in Canonical, which provides enterprise level support to compete with RedHat, etc.
In my experience, kernel updates, which deploy as part of the normal update process, are not triv
Re: (Score:2)
I had to add "rcu_nocbs=0-15" to the grub kernel arguments. I'm running an 1800x and RX480, so not too different from yours. Previously it was locking up at least twice a day, now it hasn't had one lockup in over a month.
Re: (Score:3)
Anybody actually paying attention knew well before The Register printed anything.
The flaw was spelled out reasonably well by LWN as far back as November 15th, and it was noted that it was highly unusual for the patchset to be fast-tracked as it was. LWN also mentioned the initial KPTI patchset (then called KAISER) about a week earlier than that (Nov 10th). A month later, LWN followed up (including notes that ARM64 was affected) - more than a week before The Resister printed anything.
It was clear that someth