Sigh. See, this kind of thing is what happens when developers don't take the most elementary precautions when sanity checking their inputs. Haven't those people ever heard of Fuzz Testing?
http://pages.cs.wisc.edu/~bart/fuzz/ The researcher documents research published in 1990, 1995, 2000, and 2006. One of my favorite quotes in those articles is this passage from the last paper: ---- " With each new release of fuzz testing results, we are often asked "do these bugs really matter". When we present our results to software developers and managers, we get a mixture of three basic responses: 1. These bugs do not reflect realistic usage patterns, so it is not cost effective to spend time on fixing them. In the early years of our studies, we did not have a good response to this criticism. However recent events have shown this view to be obsolete. The kinds of bugs that we find are true favorites for those who are developing security exploits. Even if we wish to ignore reliability as an end in itself, vul- nerabilities in security have a clear cost. As Garfinkel and Spafford noted several years ago, reliability is the foundation of security [6]. And we quote from Microsoft, "An insecure driver is inherently unreliable, and an unreliable driver is inherently insecure." [13] 2. This crash data is easy to obtain and free, and the crashes might occur in actual use, so the bugs should be fixed. This is the view that we hope to hear. It is rarer than we would like. Note that by "easy to obtain and free", we mean that the test programs, results, and fixes are available on our web site. 3. These are bugs! Bugs! My code is malformed and I must fix it! This view is one that resonates with those who see software development as a true craft, and not just a job. A woodworker, artist, or stonemason would be loath to produce a work with a known flaw, and would cringe at the thought of not fixing such a flaw if one was pointed out to them. You either get this view or you do not. These are the folks that we would like to have working for or with us." ---- Which attitude above do you think probably reflects Valve's current management and dev team? To summarize: This is NOT a new class of problem that suddenly sprung up. In fact, the tools to perform the testing necessary to find this problem have been freely available in a platform agnostic, language neutral way for nearly 20 years. This is very, VERY basic stuff that should _never_ affect an application with such a huge public presence. IOW, Valve screwed up in a very, very big way. Frankly, I'm surprised it took this long for someone to create a packet generator that takes advantage of the weakness. Here's hoping that Valve gets to work doing some basic tests before their next release. > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 28 Apr 2008 19:38:57 -0700 > From: "Nephyrin Zey" <[EMAIL PROTECTED]> > Subject: Re: [hlds] Critical "Nuke Attack" Exploit within Source > engine > To: "Half-Life dedicated Win32 server mailing list" > <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=UTF-8 > > It can send any packet of data you tell it to, the key to the attack > is the fact that it spams it over and over. I successfully took down a > test server here after instructing the tool to spam the string "aaaa" > (4141414100) > > - Neph > [HUGE snip. Doesn't anyone bother to practice netiquette these days?] _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
