Hacker News Reader

Comment by nykolasz | Hacker News Reader

Waiting a few days to patch my own servers... Not sure what is more dangerous right now: applying these rushed patches or the vuln itself.

View on HN

What distro are you running? I trust Red Hat to get kernel updates right the first time, I just patched externally facing servers and systems that handle PHI tonight with no issues (outside of one of my PostgreSQL servers showing a non-neglible increase in CPU usage, damnit Intel).

Of course, I also go into any updates with a rollback plan. ITIL sucks, but one thing it taught me was the value of well documented plans any time you make changes to production systems.

Same. RHEL/CentOS went without a hitch. The age of the kernel start’s to concern me, though.

According to the top comment in one of the posts in HN even 4.9 and 4.4 use a less ideal patch: https://news.ycombinator.com/item?id=16085672

I can’t really judge how much RH engineers are capable of fixing that kind of stuff in a kernel that’s officially out of support upstream.

Based on the general quality of RHEL/RHV I trust them to do the right thing, but I have no insight whatsoever in how kernel development actually works.

Red Hat pays the salary of a couple kernel developers, backporting security fixes is a pretty big part of their job. Keep in mind, RHEL/CentOS 7 doesn't even use something newer like 4.4 - it's still on 3.10 because Red Hat guarantees a stable kABI throughout the lifetime of a release

This seems like one of those things that is very hard to get right: https://forums.aws.amazon.com/thread.jspa?messageID=823033

I'm guessing Xen PV isn't well tested by Red Hat anymore since most (if not all) of their paying customers still (stuck) using it are likely on RHEL5, which they haven't released a patch for yet due to that very reason.

I'm kind of shocked Amazon doesn't have something like Linode's Fennix, but you can always do an EBS snapshot of your /boot volume and revert it if a kernel upgrade breaks stuff.

Unless you are running remote code there is no reason to patch.

This is wrong and bad advice. All you need is a remote code execution vulnerability in PHP or so.

Only don't patch if your server is isolated and not connected to the internet.

RCE is already kind of game over though. If you have RCE on the server, you can probably get to everything interesting without having to go through a slow side channel.

If you have a remote exploit, there are much bigger issues to worry about. And since this is a timing issue, I'm not even sure that would be enough.

Reply on news.ycombinator.com