full-disclosure - Re: Getting Off the Patch

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]

Date: Mon, 17 Jan 2011 17:02:55 +0100
From: Pete Herzog <lists@...com.org>
To: "Thor (Hammer of God)" <thor@...merofgod.com>
Cc: Zach C <fxchip@...il.com>,
	"Valdis.Kletnieks@...edu" <Valdis.Kletnieks@...edu>,
	"full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Getting Off the Patch

> Excellent example.  I'd like to also throw one in that has network connectivity consequences.   Regarding SQL Slammer - what would have given 100% protection from Slammer.  Outside of the obvious ones like firewalls and such which are already deployed.  That's a "real life" example, and I'm interesting in what controls would have already been in place.

I responded tot he previous example but I should have focused on this 
one. There's some interesting things about slammer that I really 
didn't understand. Why was the SQL service reachable over the 
Internet? Why hasn't server access been limited to only packets within 
a TTL of 1 or locally only if so required? Why hasn't the server been 
better managed to prevent applications from running or connecting 
however they want?

Even something as simple as least privilege and a host-based 
white-list hooking all apps and services running would have been able 
to prevent something from starting here. I see this as a server not 
fit for Internet use be marketed for Internet use without a good way 
to limit damage. Now I'm not an MS server expert so I can't say 
specific solutions but I do know that the MS Windows systems I've seen 
are shy of elegant solutions to create op controls for various vectors 
(in-server being a big one). From a network perspective, ingress 
filtering to white-list types of commands allowed, including 
size-restrictions, would have helped.

But really, you say no firewalls and no filtering the port/service 
because? I don't know. Maybe you're saying for all those who have 
small businesses, just a couple servers, and don't do any segregation 
of network then perhaps NAT alone helped some of those small 
businesses escape the dreaded slammer by not passing that port back in 
to their server.

But really, the results of slammer, like the results of many of these 
Internet scourges popping up, there's a case to be said for too much 
black-list authentication for prevention filtering and not enough 
control on what can run and what it can do/send/listen. For example, 
why should any secured system run something off a USB key that's 
plugged in? That's just not taking operational control over the 
server. So in such cases, the lack of a patch didn't affect those who 
had control over what reached that particular port.

I know the OSSTMM isn't the easiest thing to read for some but it is 
about trying to make a model that can be re-designed in more specific 
and more eloquent ways to help more people understand some basic 
aspects to making controls. But if it's not for you and you think that 
op-controls can't protect where patches are needed then just feel free 
to do your own thing the way you want to.

Sincerely,
-pete.

-- 
Pete Herzog - Managing Director - pete@...com.org
ISECOM - Institute for Security and Open Methodologies
www.isecom.org - www.osstmm.org
www.hackerhighschool.org - www.badpeopleproject.org

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/