winblows update

so i'm using my computer thursday night when i get a notification that updates have been applied that require a reboot. ok, whatever, i've mostly come to terms with the fact that Windows 10 updates itself without asking me, at least it asks me when is a good time to reboot. that wasn't a good time so i said later.

well, later came in the wee hours of the morning when i was done working and ready to head to bed. i go to shut off the computer and the new options in the shutdown menu remind me that there was an update to take care of, so i choose the update and reboot option.

i chose that option rather than update and shut down because, from past experience, the update process has not actually completed by the time the system shuts down. there's a bunch of stuff it needs to do on the next restart and that takes up time i could be doing something else, so no shutdown just yet, just an update and reboot and i head off to take care of my evening oral hygiene routine thinking that the process would be done by the time i get back.

when i come back the computer is still in the process of rebooting? what the heck? oh no, i've seen this before (or at least i think i have). is the computer stuck in a reboot loop? powering off for a few moments usually breaks out of the loop, but this time i discover it wasn't a reboot loop at all. when i let it power up again i see a screen saying that it's applying updates and that several reboots will be required.

are you kidding me? this is not what i want to deal with in the wee hours of the morning when i still have to go to work the next day. this is not convenient, and frankly "several reboots" for an update is bullshit. i understand the need to perform a reboot during an update; files and other resources that need to be changed may be locked by running processes and rebooting eliminates that impediment, but several reboots? Microsoft has been at this update business for decades now, you'd think their little minions would have figured out how to coordinate their efforts so that each part of the update could make use of the same reboot, but no, apparently that kind of unified effort is beyond them and in fact they seem to be moving in the opposite direction where every bit and piece of their updates (and the operating system itself) is becoming more separate and isolated from the others.

so i did what i hate doing. i left the computer on completely unattended overnight so that hopefully by morning the update would be done. and it was, but that's not the end of the update related problems. you see, Microsoft's updates aren't just for security fixes. those are important, yes, and the fact that people were taking too long to apply them and leaving their systems to become part of massive botnets is part of the reason the user's control over updates was taken away from them. however, Microsoft has re-imagined how versioning of their operating system will work so those updates now also come with feature changes, which (due to the increasingly isolated approach units within Microsoft are taking nowadays) means new binaries with new behaviours.

how the hell is anyone supposed to develop a behavioural baseline for their system with this never ending parade of new binaries and new behaviours? this morning's culprit? BackgroundTransferHost.exe. what does it do? who the hell knows? not only does Microsoft give us less agency now that we can't control if/when updates occur, but there's also less transparency now too because the number of separate/isolated binaries they're introducing to the system has far, far outpaced anyone's efforts to document them.

maybe BackgroundTransferHost.exe isn't even Microsoft's. maybe it's malware. if i were going to make a downloader trojan, that sounds like just the sort of name i'd use - but what do i know, i'm not a malware writer. i suppose they expect me to trust it because it's signed, but that's not how that works. being signed (and passing the signature validation procedure) just means it hasn't been modified after getting signed, not that it's legitimate, not that it's safe, not that it's trustworthy. signing certificates get stolen. there's plenty of signed malware out there.

oh, and the cherry on top is now VMware is non-functional.

what the actual f#$% Microsoft. stop making alternative security approaches so much harder than they have to be. i'm regretting moving on from Window XP. at least there i could perform application and behavioural whitelisting with relative ease.

to patch or not to patch: an edge case

i find myself in a rather odd predicament today. i've been using an older computer (we'll call it one of my secondary computers since it get very little use compared to the one i'm writing this with right now) and i got a pop-up notification that i was running out of space on drive C:.

now i want to put this in context; this computer sees very little use, mostly it gets turn on, has some files transferred to it or from it, and then switched off. i can't remember the last time i actually installed anything on it (for that matter, since i've switched over to using portable software, i can't recall the last time i installed anything on my primary system either) so let's say it's been a really, really long time since i touched the C: drive at all. mostly it's the larger secondary physical disk that gets used.

so you can imagine my surprise when the notification about running low on space popped up. was there something malicious going on? had the system been compromised? no, it was in the process of applying system updates. patches had actually eaten up the majority of my free space - the WINDOWS directory was taking up over 7 gigs of my 10 gig drive. i'm actually in the position where i have to uninstall software so that the patching will succeed.

now, this is an XP system so one might reasonably suggest that i upgrade to the latest version of windows so that i can avoid having all those patches on my system. unfortunately, this system is so old, i doubt it will meet the system requirements of anything newer than XP.

one might also, entirely reasonably, suggest upgrading the harddisk to something larger. memory is cheap, after all. it's a little difficult to justify upgrading the drive just to accommodate microsoft's attempts to fix their earlier mistakes, though. it's certainly not like i'm going to get any additional benefit from greater space on a drive i never make use of.

one could even go so far as to suggest upgrading all the things so that not only would i be able to move to the latest version of windows, i could have more space and a snappier system that is more amenable to being used day to day. but i already have a computer that's more amenable to being used, so really everything that was wrong with the idea of upgrading the drive is also wrong with this plan, in spades.

it's times like this that make one question things we normally take for granted, like why does it patching take so much space? is the fixed binary that much larger than the one with the error in it? no, that doesn't appear to be what's going on. it appears that windows keeps a bunch of stuff around so that you can uninstall the patch if you want to. does anyone ever actually do that? there may be a way to reclaim the space those uninstall files take up, but it's not obvious just by looking at the system, and right now simply letting the updates happen the way an ordinary user would is actually reducing the utility of the system.

thankfully the utility that's been lost wasn't really needed anymore. but what about next time? support for XP is ending, but it's not over yet, there are still more patches coming. i'm going to be facing the prospect of no longer getting patches anyway, so i might as well get used to it early - and since the system is little more than a network attached storage device that spends most of it's time powered off, i can't really see the harm.

in security, we normally think of applying patches as a no-brainer. it may present some logistical hurdles in the enterprise, but it still needs to get done. sometimes, though, there are cases where it just doesn't pay off. no practice is so universally beneficial that it should be mindlessly applied 100% of the time.

a whitelist user's perspective on windows update

as i may have mentioned before, i use whitelists - for web content (via noscript), for basic network traffic (via my router's port forwarding functionality), and also for traditional applications (via the application launch control functionality of my software firewall). whitelisting is an important part of my security strategy but if there was one thing that made me wish i didn't use application whitelisting it would be windows update.

you see, i don't add the programs involved in software updates to my whitelist. in fact, i don't add the majority of programs on my system to the whitelist. i don't want them being able to run without my knowledge or authorization, especially those that give no indication that anything is running in the first place, and even more so for components that have any role in installation/update. i'm not about to enable silent installs using existing components. and frankly i expect updates to be new anyways so there's little point adding those. for the most part that's not a big deal, i just take note of what program is trying to run (so that i can catch anything that looks suspicious) give a one-time authorization and let the program do it's thing. even for updating most software that's not a big deal, but when it comes to windows update it's a very big deal.

microsoft, for reasons that i can't begin to fathom, are clearly cobbling the update procedure together from as many bits and pieces as they can. i know this because of the number of program executions i need to permit (it's a lot) and how big of an interruption it is. on my older, slower system that i only power on on the weekends i started permitting various parts of windows update on saturday. i don't really have the time (or patience) to sit around clicking every couple of minutes for hours on end so the confirmation dialog only gets clicked when i have to time to go back and check on it's progress (and i sit there for a little bit, clicking here and there until i have to leave again). as of tuesday morning the update was still going. it took until monday just to get to the point of saying "there are updates ready to install". i can only hope that by the time this post is published the update will finally be finished and i can power the machine down.

some people might consider this a failure of application whitelisting, but i don't.  microsoft has designed their update procedure to involve far, far too many invocations of far, far too many separate executables. they need to stop expecting that they can run whatever system components they want, whenever they want, however many times they want with impunity. it's wasteful of resources and it's wasteful of my time.