Hacker News Reader

Comment by athenot | Hacker News Reader

> unfortunately, not everyone keeps their systems totally up to date for various reasons

Because patching requires a quick risk calculation. Should I patch to the bleeding edge and get the latests security but risk a regression bug, or do I wait a bit so I can run a full regression test?

On my machines, sure I like to stay on the latest and greatest. But I'm sure there are plenty of companies that got bitten because some critical software they rely on didn't play well with the latest OS upgrade. Blame game notwithstanding, it comes down to a business disruption risk.

Of course, the right answer is to test the patches as they come out in a non-production environment, and go from there based on results. But I can see where some companies wouldn't have the resources devoted to do that on a frequent basis, which is unfortunate.

View on HN

Similar to this, I didn't patch my OS X laptop for something like three months because the darn update was a firmware update. It said something along the lines of "Make sure your laptop doesn't lose power, and make sure you have a full backup before starting." Uh-huh. I do have a full backup, but clicking that "Later" button was far more valuable than dealing with the 0.001% chance of disaster.

And I'm a security guy. If I don't care enough to update every day, what do other people do? (There's not much reason to keep a personal laptop up to date when you're not interesting enough to be targeted and not in the habit of running random internet programs. Or rather, a few months of lag is fine, as long as you're paying attention to what the updates are for.)

I think we just don't like to acknowledge the fact that updates sort of suck, yet we bash people and shame them for not doing them. I mean, we don't have many other tools to force them to update, but surprise surprise when people are just concealing the fact that they don't update at all. Even in corporate settings.

Platforms should maybe get better at differing security patches from other types of updates to help make the choice easier. But, I suppose, at a certain point any sufficiently old setup is simply no longer supported because it becomes too difficult to align the security patches with old versions.

This. It still amazes me that MS hasn't done a better job of this.

I'd be interested to hear a heavyweight enterprise sysadmin's take on this, but my experience and read is that it's "toss it at the wall and see what sticks".

Which is crazy when MS knows all of the following things: (a) which files the patch changes, (b) how it changes those files, (c) which programs a customer uses, & (d) which MS files get loaded by which customer programs.

In days where we can do ISA-to-ISA conversion on the fly, you'd think it wouldn't be rocket science to be able to say "Warning! This patch may effect operation of commonly used programs X, Y, and Z". Or at least have an admin tool to provide that information.

That sounds sounds like a problem perfect for a startup to tackle.

Microsoft does a pretty good job at this, but some patches disrupt certain configuration. The latest round, for example, impacts printing for many people on Windows 7.

This is part of what I do. We do a risk assessment -- SMB and Kerberos get patched no matter what, everything else depends on a test cycle and may be deferred for up to 6 mo.

>Microsoft does a pretty good job at this, but

What? With the large monolithic patches that Microsoft has moved to, they have got worse, much worse, recently. It does make it easier to patch everything at once quickly, but if one thing goes wrong, you have to back it off and lose all protections.

Unless you were doing external vulnerability assessment, that granularity was a false sense of security. Rolling back sometimes re-introduced old bugs.

Granularity is impractical when applying patches is optional, as it drastically increases the number of applied patch combinations to QA.

But my point was more towards MS programatically alerting customers as to what programs and subsystems patches might effect.

As far as I've seen, they give you a file list, some brief notes on what the patch is for, and assurance that they internally QA'd it.

But I can't see why there's any technical reason that my system can't warn me that an MS library called into frequently by a particular program I use every day is modified in this patch.

Which is something I care about almost as much as "MS QA passed this patch" (side note: thanks so much to all the unloved, unknown internal QA folks out there, keeping things from breaking!).

I mean... they're trying pretty damn hard with Win10.

The LTSB version is designed to essentially stay the same with regards to applications/apis/etc while still proffering up security updates as fast they have them.

http://windowsitpro.com/windows-10/understanding-long-term-s...

Also the security patch channel has been incredibly abused to deliver non-patches.

Windows 10 has tons of security patches in it. Yes, it also has some UI changes that are less than great, but, seriously, stop using Windows XP already.

So you are just going to ignore the fact that Microsoft abused the security patch channel to automatically "upgrade" people to windows 10?

OS updates should come through the normal security patch channel! That's how OS X does it, and that's how Chrome OS does it.

Still, Microsoft misused the channel. They made it intrusive, misleading and impossible to control more than once.

OS updates should come through the normal security patch channel!

Except when you are "updated" from a full, paid version to a spyware/adware-ridden version.

Seriously: I think Windows 10 is great, technically and usability wise.

But MS need to learn that they can't have it both ways:

Paid xor ads. (I can think of two exception: inside the store app and inside settings for onedrive.)

Well, it's not how most Linux distros do it. If your update has breaking changes, it's not a security update.

There is no good reason to excuse Microsoft for maliciously disguising updates as security patches in order to manipulate the non tech-savvy into switching to their new unprecedentedly invasive OS. Especially when, as you said, the UI is worse.

The entire UX of Windows 10 is worse, every time I have to use it for something I get physical anxiety from claustrophobia.

I really don't like that I have to install untrusted 3rd party software on my computer in order to prevent my operating system from automatically ruining my user experience and spying on me.

Windows XP is a red herring. No one uses it anymore, and WannaCry didn't even successfully spread from that version of Windows.

Windows 7 is the new holdout, and people aren't eager to swallow 10.

Except in countries that used XP extensively like China. Non-Microsoft parties had to create and release patches that protected against wannacry.

Why? The only reason XP came up was because Microsoft went out of their way to patch it themselves.

Because XP patches only worked on valid licenses. A ton of XP in China is pirated. So Qihoo 360 created custom patches for all those pirated versions of Windows. Weird Alice in Wonderland situation.

https://www.engadget.com/2017/05/15/pirated-windows-china-ru...

Microsoft deserves ALL the blame for people still running XP. They broke so many hardware drivers with the XP->Vista change that people basically got stuck forever.

Then, not having learned their lesson, they pulled similar crap with the Windows 7->Windows 8 transition which pissed people off so badly that they refused to go to Windows 10 and are currently suing Microsoft for attempting to shove it down people's throats.

Insecure old version of Windows are Microsoft's own damn fault.

I recall the driver change was because under XP, drivers ran under kernel privileges.

Moving them out of the kernel is a great engineering decision, infinite backwards compatibility isn't feasible. Sometimes breaking changes are needed.

Drivers still run inside kernel. What was changed in Vista is that the kernel tries to detect when kernel data structures that should be immutable are changed, which some drivers do.

The idea of non-privileged drivers is neat, but in general is not worthwhile because the driver has to somehow access the hardware, which for significant amount of device/platform combinations leads to access to arbitrary memory locations.

Edit: perfect example are GPU drivers, which are for a long time typically composed of small priviledged kernel driver and all the complex logic in userspace. In many cases the interface between these two components could be abused to get code execution in kernel context (in 2k/xp times there was even RCE in kernel context triggered by displaying properly crafted image in IE)

As I recall, the issue they meant to address wasn't security but stability. Apparently a majority of BSODs were caused by faults in the driver taking down the kernel with it.

This means you aren't preventing drivers from having full access. You just need to prevent more unintended side-effects.

And you can do things like give people specific permission to access the kernel when doing the driver install. ie. "This driver does not adhere to Vista driver standards. Do you wish to install as an XP driver?"

Suddenly, people can run that business critical, single, old driver as unsafe while running the other drivers safely.

Alas, some manager at Microsoft decided it was more important to get his numbers up this quarter so he could get his bonus. In so doing, Microsoft orphaned a bunch of people on XP just like they orphaned a bunch of people on VB6.

Microsoft made its own bed; now it has to lie in it.

Yes, the final analysis showred that Windows 7 systems were the most affected by WannaCry. And they were targeted for more than a year by Microsoft with the multiple "upgrade now to 10" ads delivered through the security update channel. And I personally had the computers which didn't work under Windows 10, and worked correctly under Windows 7, so I really understand those who disabled auto-updates.

Not to mention that also afterwards there were Windows 7 patches that kept one CPU core 100% busy for days!

You're giving people too much credit. A lot of people, and companies, totally ignore their software. There's no risk calculation; they're not thinking about it at all.

Most of the time a security patch doesn't break software. There are exceptions and disasters have of course happened but you're kind of conflating general updates, upgrades and security patching. You can even canary test patches against percentages of your userbase since it's really simple with a Windows environment. Patching windows itself is probably the easiest thing to patch in an enterprise environment. The real reason these companies/organizations don't patch Windows is because they don't prioritize it and/or they're lazy.

You speak in certainties about vagaries.

There are plenty of companies where "most of the time it's not broken" is a big problem. Possibly bigger than the cost of a security issue (I don't know, because this is both hypothetical and I'm an outsider to the issues at play).

To not acknowledge that others would value a different part of the risk curve lacks perspective.

I mean, in my line of work Windows Update suddenly running and rebooting means fire risks. I wish I could connect the computer to the network so I could monitor equipment remotely, but it's too much risk. I hope utilities take the same measures. Certainly some work computers are vulnerable to all mess of viruses from not having gotten updates in years.

> I mean, in my line of work Windows Update suddenly running and rebooting means fire risks.

With all due respect, if that's the case you should not be running Windows.

I agree in spirit, but there's always a balance. And to clarify, I meant "risk" in the "failure analysis" sense. I didn't intend to imply that such risks should go unmanaged. Disconnecting from the internet is part of that risk management, but of course it is multi-layered.

I can't buy an Emerson control system for a small reactor getting reconfigured every other week, and LabView on an un-networked Windows computer is perfectly fine.

I would not use a PC (with any OS) to control a 10 kg reactor though. At least directly. I think it'd be okay to use a PC to coordinate discrete controllers as long as they couldn't change state without a command (i.e. latching valves and the like) and as long as there was a backup safety that didn't have a computer in the loop.

Safeties that do things like shut off furnaces if temperature sensors break or valves that shut off flow if it becomes too high or detect a flame are common, analogous to a fuse on a circuit board. You sure hope not to use them, but they'll suffice for unexpected situations.

But there's definitely a risk that has to be managed, and connecting infrastructure and industrial equipment to the internet is not managing it very well!

Reply on news.ycombinator.com