[Discussion] Consequences of CPU vulnerabilities

[Discussion] Consequences of CPU vulnerabilities

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 3763 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello *,

during the past months, more and more vulnerabilities in modern CPUs
were detected. At the moment, there is
- - Spectre v1 and v2
- - Meltdown (sometimes referred to as Spectre v3)
- - Spectre v4
- - a bunch of vulnerabilities similar to v4 (summarised as Spectre-NG)
- - Spectre v5
- - and a lot more, at least five of them undisclosed.

Needless to say, this complex is a total nightmare for anybody caring
about security - not only because of the technical issues, but mainly
due to very sloppy responses from the hardware vendors (I cannot resist
naming Intel here directly).

Further, the current CVE and patch situation (especially when it comes
to the Linux kernel) is completely confusing, making it nearly impossible
to check which has been backported whereto, addressing which security
bulletin. In my humble opinion, the significance of security has decreased
a lot and is still dropping. Being discontent with the overall security
situation in the Linux kernel, the handling of recent CPU vulnerabilities
did not help.

That being said, I would like to discuss some changes to improve security
in IPFire, most of them at kernel or sysctl level.

(a) Disable hyperthreading by default?
OpenBSD did so a while ago, arguing this makes some side-channel attacks
more complicated or even impossible. HT was the source of some serious
vulnerabilities in the past (starting around 2006), which is one reason
why I never liked it too much. Would you consider disabling it acceptable
(it will probably cause some performance impact)?

(b) Update kernel more frequently
It seems to be necessary to ship new kernels more frequently, as some
security fixes are backported to 4.14.x very quickly. Unfortunately, this
causes updates to become very big, as C121/122 turned out, and I am not
familiar with the procedure behind this. How often do we want to ship a
new kernel? Every second update? Every forth? I have no idea... :-)

(c) Introduce kernel and sysctl hardening
Fortunately, there are some configure flags and /etc/sysctl.conf settings
improving the overall situation:
https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
Their implementation in IPFire is on my TODO list (forgive me for being
slow during the last time) and filed here: https://bugzilla.ipfire.org/show_bug.cgi?id=11659

How small should the chunks be here? A patch for every changed setting
or can portions be bigger (same applies on OpenSSH hardening as well)?
Just asking to avoid unnecessary noise afterwards.

Comments? Anything I forgot here?

Thanks, and best regards,
Peter Müller
- -- 
Microsoft DNS service terminates abnormally when it recieves a response
to a DNS query that was never made.  Fix Information: Run your DNS
service on a different platform.
		-- bugtraq
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEvP4SiGhEYDJyrRLk2UjyD317n2gFAlt0T2IACgkQ2UjyD317
n2h8XQ//bWEYXJPfVzocEd1yZTKaoCRc4VyVSugV0p8kHfd42CS8uA0Pp3mM3Bzy
cWWxu3ru7oDc344BD54jtdPHLYP6WidEOF6Omgd8xYoFudHBc1zodBnKfeMkFLmZ
0YwblIA4arg5pVmUiqrCiRbyn2B+07e8fYO9DyGKESfJHw/RwPzW7jhJv3J4R7+Z
wabLfxaF3rbgB264FZ0YcfA1XUswvlvE4eKxxaOEUfnis7dFcmKZHB+LiQsIMXDj
AshlnCuWl5r1OczAwlyQw4xEykyCEVDCeeoGjOyXqx373+ThaODSGQovOIEFxPz/
TCERMUQNvAZQ0mi113Nw8MIZ5ofCJWZZhYldxsYNptVk425BMH+7moQDDQfaWmWc
GW/10j+rJITRhaYDq3LRNu6qACPE2N/T/7vz5kl5vslbmQ0pBuIf9HpdVIFHr5t9
yBclnxBs3r8z7G74Jvv0c9oNX5kUZ3AXUttZDghJQVkw15AOa1oZfl8nLZtW3KL2
aaeW8o9h19SBhywmUNL/7VMssM8IHeKf2rkT+ybOUC52MtXHnGuSKSdrjtFhpnAe
h3irxsJf0EFjZoxq2id3vtOzX8BWFxGFKOHXog33dNlNKDD/COqv4iAx8tb0eyiS
9F49HlB4NDK5oT4SF+6HIzBp4MYv8nmkX6j+9TVTKfmFQbmzc9w=
=Y+k+
-----END PGP SIGNATURE-----

Re: [Discussion] Consequences of CPU vulnerabilities

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 6024 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

On Wed, 2018-08-15 at 18:06 +0200, Peter Müller wrote:
> Hello *,
> 
> during the past months, more and more vulnerabilities in modern CPUs
> were detected. At the moment, there is
> - Spectre v1 and v2
> - Meltdown (sometimes referred to as Spectre v3)
> - Spectre v4
> - a bunch of vulnerabilities similar to v4 (summarised as Spectre-NG)
> - Spectre v5
> - and a lot more, at least five of them undisclosed.
> 
> Needless to say, this complex is a total nightmare for anybody caring
> about security - not only because of the technical issues, but mainly
> due to very sloppy responses from the hardware vendors (I cannot resist
> naming Intel here directly).

Yes, I thought I was overstating a little bit in the last blog post
that there are many more to come, but I guess was quote right with
that.

I personally cannot grasp this any more that such *severe*
vulnerabilities are in such an essential part of our infrastructure.
This is not just an oversight, this is negligence and prioritizing the
wrong things like performance which translates into profit.

At the same time I have to say that there is just no alternative to
Intel CPUs in most sectors of the market.

> Further, the current CVE and patch situation (especially when it comes
> to the Linux kernel) is completely confusing, making it nearly impossible
> to check which has been backported whereto, addressing which security
> bulletin. In my humble opinion, the significance of security has decreased
> a lot and is still dropping. Being discontent with the overall security
> situation in the Linux kernel, the handling of recent CPU vulnerabilities
> did not help.

I do not think that this is a Linux kernel issue. I think it is
inherited from Intel who do not seem to be helping the kernel community
(and that seems to include their own developers, too) to develop any
functioning mitigation because it slows things down. That was the main
concern for the media when PTI was being developed - not that there is
a huge hole in the CPU. Just that it is slower than before.

It is also very obvious where people's priorities are. I.e. nobody
cares about 32 bits any more because there is no money in it. But that
doesn't mean that those systems are not out there...

> That being said, I would like to discuss some changes to improve security
> in IPFire, most of them at kernel or sysctl level.
> 
> (a) Disable hyperthreading by default?
> OpenBSD did so a while ago, arguing this makes some side-channel attacks
> more complicated or even impossible. HT was the source of some serious
> vulnerabilities in the past (starting around 2006), which is one reason
> why I never liked it too much. Would you consider disabling it acceptable
> (it will probably cause some performance impact)?

I do not think that this is a good solution to the problem.

You can do that with the "noht" parameter at boot time and you can
disable it in your BIOS. I would vote against making this the default.

There reason for that is the solution to just disable it isn't really
one. It is just a hack that works if performance isn't an issue. In the
big picture, performance is an issue.

> (b) Update kernel more frequently
> It seems to be necessary to ship new kernels more frequently, as some
> security fixes are backported to 4.14.x very quickly. Unfortunately, this
> causes updates to become very big, as C121/122 turned out, and I am not
> familiar with the procedure behind this. How often do we want to ship a
> new kernel? Every second update? Every forth? I have no idea... :-)

Well, I have to have a little bit of a rant here:

I would like to push out core updates more often and also faster, but
there is literally no feedback from any testers.

EFI images? No response to my email

Latest kernel update? Nothing

How can we push out more code that is not being tested? That's just
irresponsible and will break down very quickly.

So, we have to have testing doing better first before we can think
about it. A strict release schedule didn't work for us because people
are often unavailable for quite a while.

We are doing best-effort on some of the bigger changes here and you can
believe me that we have been trying hard in the past.

> (c) Introduce kernel and sysctl hardening
> Fortunately, there are some configure flags and /etc/sysctl.conf settings
> improving the overall situation:
> https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
> Their implementation in IPFire is on my TODO list (forgive me for being
> slow during the last time) and filed here: https://bugzilla.ipfire.org/show_bug.cgi?id=11659
> 
> How small should the chunks be here? A patch for every changed setting
> or can portions be bigger (same applies on OpenSSH hardening as well)?
> Just asking to avoid unnecessary noise afterwards.

One at a time.

  https://wiki.ipfire.org/devel/submit-patches#separate_your_changes

> 
> Comments? Anything I forgot here?
> 
> Thanks, and best regards,
> Peter Müller
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE5/rW5l3GGe2ypktxgHnw/2+QCQcFAlt1bBMACgkQgHnw/2+Q
CQc1zg/9EHHE0QxNVeCn6zidyuHBnCaW0r6X6HMS6jEURmiErgR0WQZ9BqiTP7v6
m/tYIOm+Pn8DrbTrP6EKZOfy98qvhXaWa9tcvfighrGNTX3hcwxnQOQpeLN7upDa
deRa33aorQxfA/8cxGkfTmT++g00dDNCk2CZDozBCFeM8s/g16VZX/CNpdEbvo9H
6MH4YGknrOPXmEM8IurNxNYyi8fmNxwfQGtm/HSNGJvyyDBZ1SbXQ4A7k2C5vKfd
H6gN/YDZhTyDdLCGiTplEFvNqKAhleEzGcwTTFcUklD1cPjcuZfNJECpLhqrVWe0
xJtv1VwaxTkFGXBU7EFf4HxZgP4LtQJ/41+j/FdZbYQvgUsIXmKHStet+IlNgGJc
ux3MAtRJPy897bgqUfxNJ6L3/9yg1yDhYqKbbZuf7yGOBDYEP4whm9wdIr0J5os5
LdQnveP2vlEZKzCHJikyV4Qi/EWVB9luvhEb/Ii7oOAc+5RMwWTocdjz9MYgqBky
An8M6b/y6nwbDy/cgZQk1R6RZY81tS2aPGgY/33vggs32aFHMyocU5CZFMZFaHYA
31dI79fDuT0W8AAQMG+Ndb9a1dsW6y5JmyhHHfvQaJnZ082uHNe1VImTBwz6Kufh
P/n/pLWgcaHaaRDVO5vQo4yx3+Zhs9G76iqeCDRqEhT+aF0pdH0=
=OsnR
-----END PGP SIGNATURE-----