Carefully choosing only the MS patches I require

I agree that patching a service that is disabled is unnecessary. I disagree that there is any benefit to not patching it, such as perceived performance improvements. At most you'd save some disk space, though very little.

It neither hurts nor helps.

@GJ,

Grsecurity won't save you from an unpatched system. They state this - and don't even offer older patch versions because it would encourage the thought process that a hardened kernel won't need to be patched. It still does, and that goes for any system - an insecure kernel is an insecure system.

 

It might be harder to tell the performance differences between a fully patched system and a partially patched system on higher end hardware, but I know for fact than on my older hardware that I no longer have, P4 1.7GHz, a pre-SP2 installation held a staggering edge in performance over that of an SP2 or especially an SP3 installation, and it was not a placebo effect. To say all the patches post SP1 don't add bloat is imho...a false statement. My own XP installation grew by GB leaps and bounds after applying fewer than 50 updates, in addition to a SP and a few others for Office 2007, where I have only Word and Excel installed.

Of course I don't advocate this approach for most everyone, since obviously under most circumstances with a few exceptions, there has to be some sacrifice of performance to gain a minimum necessary level of security. As seen in this thread there are those who can achieve an acceptable or better than average level of security with far fewer patches than typically administered. it comes down to knowledge and expertise in achieving this goal.

 

Until you or something/someone else decides to enable it for some situation.

Let's get real, all the time the OP took to find which Windows XP patches might be designed only for what he uses/experiences (and guess what, that info he found may be incomplete in some parts, lol), and which Windows XP patches are for things/situations that he doesn't use/experience at the moment = a complete waste of time (oh... he acquired some "interesting knowledge"... LOL!).

It's infinitely more reasonable to install all the damm patches and call it a day.

 

Exactly.

 

Because the Windows/Microsoft Update mechanism also creates backups/cache/uninstallers, dude. You can always remove those if free disk space is a concern (tip: use CCleaner with Winapp2.ini). The patches by themselves don't add "bloat" - simply because they fix functionality, they don't add functionality.

 

CloneRanger, if you untick "Show placeholder icon" and tick "Collapse blocked objects", webpages will look a lot cleaner for you than they are looking now.

Bo

 

That's the infamous kernel exploit(true type font parsing vulnerability) that serves the so called state-sponsored Duqu trojan. Among the critical updates that should be patched, the foremost in my mind would be this one aside from the WMF bugs and LNK vulnerability(Stuxnet). The latter is not a kernel exploit and so AE accdg to Rmus can stop that except perhaps memory only dll.

Keywords are "Kernel" and "remote code execution." Be wary if you see those words together in one vulnerability and if there is in the wild exploit or malware for that.

Just patch to the latest win32k.sys kernel driver and GDI32.dll(for the WMF bugs), and you cover almost all of the past and present dangerous kernel exploits that can possibly bypass everything. And of course, don't forget to patch as well to the latest Shell32.dll for the LNK(stuxnet)vulnerability. The rest of the critical kernel exploits or privilege escalation exploits would require LOCAL ACCESS(initial infection) or in other words, another separate exploit(arbitrary code execution) to serve the privilege escalation exploit. Hopefully with fingers crossed that initial infection can be taken cared of by layered security approach(sandboxing, HIPS, AE, firewalls, NoScript, disabling unneeded services or hardening, etc). Or else the house of cards will fall if for e.g., a "memory only dll/malware" similar to metasploit's meterpreter shell would serve up a kernel exploit then write outside of for e.g. sandboxie if that will be possible. Any pentester willing to test that for us?

 

I didn't say it would.

From what I've read, one of the problems developers face is that things like ASLR are not possible in kernel space. One of the proposals I recall reading on the GrSecurity website involved a hypervisor that would run underneath an OS kernel, randomizing its memory allocations transparently as if it were a userspace program. This wouldn't remove the need for kernel updates, but if it worked it might reduce the frequency of critical ones... I think.

 

OK, thanks

 

""Until you or something/someone else decides to enable it for some situation""

That is why it needs to be completely removed, not just disabled

 

ASLR is possible in the kernel. It's just not implemented fully in vanilla kernels because of performance reasons. If you're talking about VMs within the kernel/ JITd code, that's different - but I dont think a hypervisor is the answer.

All of the techniques in grsecurity are implemented in the kernel (like full kernel stack randomization). You even have BPF JIT code randomized. Even with all of this, if an attacker has enough holes, they will get through. It definitely extends the time that you have to patch (it'll take a long time to bypass all of those techniques) but not indefinitely.

 

Selected only four candidates to install from the latest Patch Tuesday batch

 

Well, I've followed the approach of not installing ANY patches (obviously there could be some wisdom in installing kernel level patches and the like) and installing all patches with the exception of the MS removal tool.

The former can be quite safe under certain circumstances. If you have no valuable information on the machine, use imaging software or something similar and of course practice common sense.

The latter is what is recommended and I've had no problems following that approach except a couple of years ago when that frequently broke the system or conflicted with security software. I seem to recall that I once had a problem with XP SP3 on an AMD system.

I think that the bottom line is to do what works for you ! The overall picture is far more important than blindly installing updates. Personally I strongly dislike the neverending avalanche of Windows and Flash updates.
'Security through updates' is not much of a security approach.

 

I installed all 7 of mine... you may have saved a nanosecond of boot time compared to me ; )

hey, every little bit counts.

You can certainly remain uncompromised without keeping your box up to date. I know a few people that refuse to update to SP3 on XP still getting along just fine. I could most certainly be one of them if I chose to. It's just one piece of the puzzle... but to me one I choose to snap in place. And as long as you're applying all the ones that apply to you, then there's nothing lost whatsoever. I'm just too lazy to do the research personally. I do admire what wat is doing though, personally, not ridicule him like some here are. He's learning things, and I don't see that ever being a bad thing. It's not like he's recommending this approach to others. I believe that would be negligent.

 

You'll get lots of disagreement on this, even from me of all people Many of the updates do address security exploits that might be difficult to properly address by other means.

Actually, 3 nanoseconds Seriously, I don't place too much importance on boot times. Rather, I place it on overall system performance, and I know for fact from my own experience that these piles of security updates takes a considerable toll on system performance.

Thanks Lucid, I appreciate the kind words Certainly, I don't endorse this approach to those who just want to keep things simple and easy and take the normal mainstream approach. I've learned the hard way to ignore the trolling attempts.

 

I'll also be taking it against myself, so be gentle... ...

I often also pick which updates to install, but aren't we sometimes forgetting about something that should be quite obvious to people like us? While the updates are meant to patch known security bugs, can't these same updates indirectly patch unknown bugs as well? By not using all updates, even those that apparently patch some bugs that require local privileges/execution, aren't we also not patching unknown bugs that only require remote privileges/execution?

The same way new code always introduces new bugs, new code may also patch old and unknown bugs, so why do we play dangerously?

 

I don't know m00nbl00d, I've never thought of it that way before. Maybe you're right. My perception is not as in depth as this. I just look at what the patches address and the conditions that the exploit requires. If it requires, for example, local login credentials from the attacker or some sort of specially crafted SMB server response, then I reason it's not needed.

I'm rather thoroughly convinced that the majority of these exploitable vulnerabilities are easily addressed through either or a combination of limited rights and 3rd party security measures.

I've nothing to hide; if I get exploited with this significantly trimmed down MS patched OS I will gladly post here the particulars if it ever happens

 

I measure footprint in that way too. When I boot up Windows I usually walk way and do something else for awhile anyway and give it ample time to wake up. Like us, it needs to clear the flem out of it's throat, wipe the crud from the corner of it's eyes, etc...

But I really didn't notice a difference upgrading from SP2 to 3. What I do notice, and in a big way, is adding .NET Framework to my OS. My box is far less responsive afterward. It puts my OS partition size from like 5 GB to 7, so that's like a 40% increase. And it shows. That makes a far greater difference than a glob of security patches to my experience.

But I know you see that as a necessary evil... because EMET makes your setup stronger to the point it's worth that trade off. But that's an opinion I do not share. I see an attack surface so miniscule, and a chance of being exploited so low, that in addition to having images to wipe the slate anyway and having nothing sensitive online anyway, that it's just not worth that (massive) performance hit. And I know your hardware is better than mine and can take it in stride better. But then at that same time, that would also imply to me that you could take that glob of patches in stride as well without noticing it.

On my box .NET FW is heavier than every single critical patch combined. That's with a 2.4 ghz Celeron CPU and 1 GB of RAM (haven't tried .NET FW since upgrading to 2 gigs of RAM). I don't know what it is about it, but it makes my system crawl on all fours. It even makes Firefox noticeable slower even though FF doesn't use it. And adds an annoying addon as well and makes it very difficult to get rid of... then if you did, it'd just come back with the next Windows update again anyway. So I lost my stomach for .NET FW in several regards.

But we all know things can vary (greatly) from one setup to the next.

 

Did you try NEMET? .NET framework is only needed for the EMET interface. NEMET doesn't require NET framework.

 

I looked into NEMET, but had some questions about it that went unanswered and/or remained vague to me. Such as, it appears you need the EMET.dll to make the thing function properly, is that correct? You can't just install NEMET and make it work out of the box, can you? If that was the case I'd probably use it. But from what I gathered you have to jump through a few hoops to get it to run on XP without .NET FW.

Unless I'm misunderstanding... I asked these questions and the responses very very vague, and ended up leaving me even more confused. So I just dropped the issue...

I tried contacting the developer on his site about getting a native .dll he'd supposedly developed for it, but was unwilling to release publicly due to the fear of legal action. I tried to get him to send me the thing privately... but no response.

So I'm confused. Can I just install this this as-is and it will work properly? From what I gathered the answer is no. And if I need the EMET .dll... where can I find it? I was unable to from searches, surprisingly. I'd have thought such a thing would be readily available at DL sites. If it is indeed needed, I'd appreciate some help in obtaining it. Let me know in this thread, or PM it to me please.


... somebody mentioned WehnTrust too, or something. But then I heard it like creates a copy of every file on your OS, or something, which doesn't sound too kosher to me. And is very heavy. It sounded less than encouraging to me.

 

It may as well never happen.

 

While I apply all patches, I'm following this thread as it contains some interesting views and information, so do continue

Everytime after patchday, if there is an update to the .net framework, after reboot the .NET runtime optimization service runs for quite a while using very much CPU constantly, sometimes 100%. MS claims it has low priority and doesn't slow down the system, but even on my machine with a 2 GHz Core 2 Duo, RAM upgraded to 4GB and hard drive upgraded to 7200rpm(It's already 5 years old, but compared to some of the systems in here, it's quite powerful) there is very noticable lag and slowdown. Are you sure that's not what is causing the slowdown after you install the .NET framework?

 

The last time i used XP i didn´t installed SP3, just SP2 without updates, so the installation was only something beetwen 2,5-4 GB (i dont quite remember the exact value)...

 

Since most patches are not in any way critical especially when assuming a proper security setup and responsible user - do all those patches not introduce new vulnerabilities ?

Patching unknown vulnerabilities ? I don't know, but that seems a stretch.

The more code, the bigger the attack surface. More changes, more chances that MS makes an error - a real one or 'on purpose'. The more updates, the greater the chance that something goes wrong - interaction with security software/setup or a buggy installation.

 

I've done this for the past 9 years or so on my old Emachine PC that I'm currently using XP on and guess what no issues

Lotsa worry about nothing IMO.