I don't think this applies to valve, as the packet contents do not matter in this case, but just the amount of packets hit at the server. Valve did a good job on making sure that random packets do not crash the server, but didn't put any internal limits on the number of packets a server will process from a given IP, and perhaps did not check these packets efficently.
Basically, this is just a DOS attack, where the user floods the server with packets, which I believe a firewall rule should be able to fix the issue for now. [EMAIL PROTECTED] wrote: > 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. > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
