Buggy game client can only be hazardous if the client/server architecture is built incorrectly — and at least that is not hard to avoid. (Screams "DON'T TRUST THE CLIENT" in the architecture meetings usually help.)
> (Screams "DON'T TRUST THE CLIENT" in the architecture meetings usually help.)
Yeah, except that in many (most?) modern games you can't have a fully-untrusted client... for performance reasons you have to give the client too much information. From what I understand, getting that balance just right is rather tough. :(
> Buggy game client can only be hazardous...
Don't forget that the vast majority of games pass data to 3D graphics card drivers which are terrible, awful, and somewhere between hardly and not at all concerned with security. A bug in a game could hard-lock your system, [0] or lead to code execution in kernelspace. (Not to mention the usual host of problems a buggy program that has read/write access to everything that the system user it's running as, and generally full network access has.)
[0] Despite Windows 7's graphics card driver fault isolation system, I've had a couple of graphics-related hard-lockups in the many years I've been using my gaming PC.
Being a client-side developer in gamedev (i.e. a space that's not as sensitive to security as a lot of other industries) feels so good.