On 30/01/2018 18:52, Greg Wooledge wrote:
On Tue, Jan 30, 2018 at 12:13:47PM +0100, Michael Lange wrote:
Michael Fothergill <michael.fotherg...@gmail.com> wrote:
The response from Greg was the following:
On Thu, Jan 25, 2018 at 12:36:46PM +0000, Michael Fothergill wrote:
If I become sid and install the kernel correctly, could I go back to
being
just buster (sounds like an energy drink) and carry on using the new
kernel?
No.
*******************
At that point I really did seem that:
1. I had no choice but to become sid/unstable here.
I can only guess of course, I think probably they figured you would
upgrade your system to Sid, then compile a kernel and then *downgrade*
the system again to buster. The answer to that would clearly be "no".
But running a kernel compiled on a *different* Sid system on buster or
stretch is an entirely different thing of course.
Yes, that's correct. If you actually "become sid" (upgrade your whole
system to sid), there is no going back.
But you can set up a *separate* system (either an entirely new box,
or a chroot into which you debootstrap sid, or a virtual machine, or a
container, or whatever other fancy thing the kids are using these days),
build a kernel .deb package there, *copy* that package to your buster
system, and install it.
Or you can do what most of us are doing: wait for the Debian security
team (and, really, for the entire *world*) to figure out how best to
approach, mitigate, and/or solve the issues.
Meanwhile, I would recommend not letting random people get shell access
to your critical systems. Near as I can tell, exploiting a Spectre-type
CPU vulnerability requires the ability to install and execute a program
of the attacker's creation on the target system. If you don't have
users logging in and running commands, then you probably don't have to
worry so much about this. Unless I'm completely missing something.
(If you have users issuing commands on your system through some other
vector, like a PHP web-app exploit, then that's a bigger issue you
should address directly.)
It should be possible to exploit Spectre via javascript, the prominent
web browsers (G.Chrome/Chromium and Firefox) have already applied
mitigation for this scenario. For G.Chrome/Chromium you can also use an
experimental flag do harden site isolation (at the cost of memory
consumption). But you can be sure the clever kids in their basements,
the mafia networks and the state sponsored rogue agencies are hard at
work trying to find novelty use for these new pathways to our systems.
So patch, update, and be careful what emailed link you click on (hint:
none).
In Debian we are lucky as far as I can judge, Stable received a backport
of the Kaiser/kpti patches, and Sid has retpolined kernel and patched
gcc (but still vulnerable to Spectre 1 just as everybody else on the
planet).
On Stable and Backport kernel you are covered for Meltdown (for Intel
cpu) but still vulnerable to Spectre. That will be the case as long as
the gcc patches are not backported, or the Debian deities decide to
break the taboo and issue a kernel and gcc bump for Stable, unlikely.
In Testing you are following Sid, remember there is no official security
support for Testing outside of the very end of the pre-stable release
freeze period. So you can cherry-pick what you want from Sid, or wait
for the migration to naturally happen (if it has not happened yet, I
don't know).
The cpu microcode side of things is a lot murkier, Intel is going back
and forth with crappy code that crashes some systems, and the decision
to apply or not those microcode updates is a tricky one. As for board
vendors they don't seem to scramble to send updates out...
In any case right now there is no cause for alarm for the general public
(IMHO), that may change if a working javascript exploit surfaces but it
isn't here yet. If you are hosting virtual systems for distrusted
clients (aren't they all) then you need to weight your options
seriously, keeping in mind that when an efficient exploit surfaces it
will be too late to patch.
All of the above is just my attempt at offering a synthesis of my
experience, I am not working for US-CERT and I am not a DD, so you can
ignore all of the above and go find out for yourself (the best way®).
