Live data from Hacker News

Microsoft’s February security update release delayed to March

blogs.technet.microsoft.com

11–20 of 53 posts

Re: Microsoft’s February security update release delayed to March

#11
post #5

Earlier quoted context omitted.

If anything the cumulative patch is better, not worse. It's much harder to validate nine individual patches than a single cumulative update. What happens if patch seven fails? How about six? How about six and seven? There are an exponential number of failure cases with multiple patches vs one.

What are these security fixes that they fail so much? Although there are of course tough bugs with tough fixes, the vast majority presumably consists of off-by-ones, simple buffer overflows, use-after-free, etc.

Because the PC is an open platform, people can modify it in all kind of ways. A patch can for example fail if the user has for one reason or another removed or disabled a system component that is needed to validate or processes that patch.

I think the cumulative patches work fairly well, they install much faster than the old ones. I am however troubled by the amount of security fixes Microsoft has to do every month. This shows that security is mostly an afterthought at Redmond.

Re: Microsoft’s February security update release delayed to March

#12

Earlier quoted context omitted.

enterprises really hated that because it meant that sometimes 1000s of computers were all out of commission running updates at the same time. If a computer has to go out of commission for a security update, you are doing it wrong (as an OS vendor). Doing cumulative updates is only band-aid. The real solution is make the OS modular and reliable enough to replace/restart components while it is running.

To the downvoters: Red Hat, et al. can roll out security updates on running systems. Except for kernel updates, though kexec avoids long restarts.

This is a somewhat unpleasant semi-misconception. You can, indeed, update everything but the kernel without rebooting. In fact, I suspect you could even replace the kernel image and the modules while they're running (but this will certainly break any attempt to load modules at a later point without rebooting first). (Edit: most distributions choose to keep the old image along in case the new one breaks. It's relatively unfrequent now, but back in 2003...)

Generally, however, processes don't get restarted after updates and libraries don't get reloaded, so without rebooting, you're still running the unpatched versions.

I don't know if RHEL has a clever way to figure out what needs to be restarted (it's not entirely impossible, thanks to systemd), but pretty much everyone under "et al." has this problem.

See Peter Larsen's comment here: https://lwn.net/Articles/702664/ for a more authoritative take on this, I deserted to BSD land long ago...

tl;dr Rolling out the updates without restarting is one thing, and it's done, and Microsoft could do it too, they just take the easy route. Applying them without restarting is a very different and far murkier story.

Re: Microsoft’s February security update release delayed to March

#13
post #11

Earlier quoted context omitted.

What are these security fixes that they fail so much? Although there are of course tough bugs with tough fixes, the vast majority presumably consists of off-by-ones, simple buffer overflows, use-after-free, etc.

Because the PC is an open platform, people can modify it in all kind of ways. A patch can for example fail if the user has for one reason or another removed or disabled a system component that is needed to validate or processes that patch. I think the cumulative patches work fairly well, they install much faster than the old ones. I am however troubled by the amount of security fixes Microsoft has to do every month.…

Not really. It was in the bad old days, pre-XP SP1. Nowadays it's part of the design process for everything.

I think it's more due to the sheer surface.

And for comparison, I think Ubuntu updates almost as much. It just reboots less due to architectural differences.

Re: Microsoft’s February security update release delayed to March

#14

Earlier quoted context omitted.

To the downvoters: Red Hat, et al. can roll out security updates on running systems. Except for kernel updates, though kexec avoids long restarts.

This is a somewhat unpleasant semi-misconception. You can , indeed, update everything but the kernel without rebooting. In fact, I suspect you could even replace the kernel image and the modules while they're running (but this will certainly break any attempt to load modules at a later point without rebooting first). (Edit: most distributions choose to keep the old image along in case the new one breaks. It's relativ…

An important part to me is that usual linux updates don't cause the next reboot to take longer, or require multiple reboots. You can install the update without rebooting; it only applies on the next reboot.

Re: Microsoft’s February security update release delayed to March

#15

Earlier quoted context omitted.

To the downvoters: Red Hat, et al. can roll out security updates on running systems. Except for kernel updates, though kexec avoids long restarts.

This is a somewhat unpleasant semi-misconception. You can , indeed, update everything but the kernel without rebooting. In fact, I suspect you could even replace the kernel image and the modules while they're running (but this will certainly break any attempt to load modules at a later point without rebooting first). (Edit: most distributions choose to keep the old image along in case the new one breaks. It's relativ…

> Generally, however, processes don't get restarted after updates and libraries don't get reloaded, so without rebooting, you're still running the unpatched versions.

It's possible determine what processes run outdated library code. There are tools which hook into the package manager which do this, like https://github.com/liske/needrestart

Re: Microsoft’s February security update release delayed to March

#18
post #15

Earlier quoted context omitted.

This is a somewhat unpleasant semi-misconception. You can , indeed, update everything but the kernel without rebooting. In fact, I suspect you could even replace the kernel image and the modules while they're running (but this will certainly break any attempt to load modules at a later point without rebooting first). (Edit: most distributions choose to keep the old image along in case the new one breaks. It's relativ…

> Generally, however, processes don't get restarted after updates and libraries don't get reloaded, so without rebooting, you're still running the unpatched versions. It's possible determine what processes run outdated library code. There are tools which hook into the package manager which do this, like https://github.com/liske/needrestart

Like I said, it's not entirely impossible (a while ago I was using checkrestart on my Debian machine with pretty good results), but the result is still somewhat clunky. There are a lot of things that aren't so easily checked: changes in interpreted code (needrestart can, fortunately, deal with Java, Perl, Python and Ruby, but I don't know how well, and there's no shortage of packages that rely on old-fashioned bash scripts or -- hey, Polkit! -- JavaScript), changes in configuration files and so on.

This is a reasonable solution if you're running relatively non-critical processes on a single machine. If you really want to avoid downtime, a cluster with rolling updates seems like a solution with far fewer headaches.

Non-critical covers a lot these days, fortunately :-).

Re: Microsoft’s February security update release delayed to March

#19
post #16

Since Flash update is now bundled with Windows Updates it means that Edge users will be using vulnerable Flash for one more month, wow :/

Flash still exists?

I used to avoid annoyances by not having Flash. Now, thanks to the hard work of WHATWG on HTML5, I'm scrod.

Re: Microsoft’s February security update release delayed to March

#20
post #13
post #11

Earlier quoted context omitted.

Because the PC is an open platform, people can modify it in all kind of ways. A patch can for example fail if the user has for one reason or another removed or disabled a system component that is needed to validate or processes that patch. I think the cumulative patches work fairly well, they install much faster than the old ones. I am however troubled by the amount of security fixes Microsoft has to do every month.…

Not really. It was in the bad old days, pre-XP SP1. Nowadays it's part of the design process for everything. I think it's more due to the sheer surface. And for comparison, I think Ubuntu updates almost as much. It just reboots less due to architectural differences.

I think Ubuntu (and almost all other Linux distros) suffer from the same problem: there is no real security coordination during development. Compare that to OpenBSD which very rarely needs to do emergency security updates.

With that said, Canonical updates the whole system and all applications. Microsoft updates only the core system, even Office is not updated unless you manually opt in.

Post reply on HN