full-disclosure - [inbox] Re: 3 new MS patches next week... but none fix

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: tim-security at sentinelchicken.org (Tim)
Subject: [inbox] Re: 3 new MS patches next week... but none fix

>   It's not that Microsoft doesn't have a clue, they do.  We are getting
> regular patches for holes that are found are we not?  If they didn't have a
> clue, we would have yearly patches or none at all.  Ok, there may be some
> holes that aren't patched yet, but I'm sure they're working on them and
> they're coming.  Some patches just have to take precedence over others.

No.  Microsoft blatantly ignores many vulnerabilities.  Come this next
round of patches, they will have ignored the %00/%01 IE hole for well
over a month.  No notice to customers, no workarounds, nothing.

How long did the IE Certificate vulnerability sit on Thor's site before
it was finally patched in all versions of windows?  2 years? 3?

>   I've seen quite a few vulnerabilities come across this list in this past
> week, not many have vendor fixes yet either.  This is not a Microsoft
> exclusive problem.  We need a better way to patch systems, ALL systems.

Of course.  A lot of vendors suck.  But some have it (almost) figured out.

>    I've said it once on another list, and I'll say it here, we need a sort
> of "patching server" that is on an isolated subnet.  When a machine first
> connects to the network, it gets an IP address and is only allowed to talk
> to the patching server(s).  Once the patching servers (for ALL OS's mind
> you) determine that the machine is up to date with it's patches, then and
> only then is it allowed to connect to the production network.

Ok, that's fine and all, until you run across the next M$ patch that
rolls "feature" changes into the bugfix patch, and they happen to break
your custom application.  Or until you try to roll a patch out that
accidentally rolls BACK some of your other DLLs to an old, vulnerable
version. *cough slammer cough* 

So, here are two rules a patching system should follow:

1. All patches regression tested against all previous vulnerabilities.
2. Never roll any functionality changes along with security fixes.

I am sure there are others to follow, but I can't think of them right now.

>   Let me ask this question, if you were running a company with 30,000 LINUX
> boxes.  How would you patch all of them?  Don't a lot of Linux patches
> require a re-build of the kernel?

NO.  The vast majority of vulnerability patches do not require any
rebuild of the kernel, which means you don't even have to reboot.

How I run a secure server?  Debian stable.  To patch:

# apt-get update
# apt-get upgrade

DONE.

Many other Linux distributions have similar sets of commands that are
just as easy, and you don't have to buy 3rd party software to make it
work.

Oh, and if you want to patch ALL of your 30000 systems, just install
your public SSH key on each of the when you build them, and:

for S in `cat servers.txt`; do 
{ ssh root@$S "apt-get update; apt-get upgrade"; } 
done;

or something to that effect.

tim