Writing super secure code is usually not a requirement for gamedev, and I completely agree, this is hard and potentially harder in C than, say, in Rust.
Writing super secure code is usually not a requirement for gamedev, and I completely agree, this is hard and potentially harder in C than, say, in Rust.
The OS should protect where it can. So should software, lest your networked game nuke, say, the parts of your home directory to which it has permissions because without those permissions it can't do something it needs to.
This is just defense-in-depth. It's super basic stuff and HN is literally the only place I see people galaxy-braining about the idea that you have an obligation to not write shit code.
Defense in depth. Write good, sane, secure, fail-closed code when you want to ship that code to other people--or don't write code.
A first line of defence is authentication. Make sure the packets come from a trusted source (you can MAC each packet for this), so only those trusted sources could possibly trigger the vulnerability.
If the only trusted source is an authoritative server, you might be able to hide that buffer overflow. If your network code is peer to peer however, you have to trust the other players not to run a cheat that takes over your machine… but at least that's not the whole internet.
I am far from an expert in security but I've done a bit of reversing/hacking when I was 16 years old (DOS era)
I think this is hard to check for everything, but in my opinion, good security can be achieved with extreme simplicity.
Packets are fixed-size, every fields are manually bound checked and the packet is rejected if anything looks wrong.
But I've seen some real weird stuff before. ;) Folks using variable-length fields and happily just dumping the contents into eval(), all sorts of awful.
In fact, generally a memory safety vulnerability will initially manifest itself as a crash before a more advanced targeted exploit can be used against it.
Many consoles have been "jailbroken" by making buggy games load specially crafted savegames that ended up in code execution.
That also extends to players downloading innocent-looking maps, savegames, models. etc that exploit bugs and end up in code execution too.
Also if you have an online game then you can have RCE bugs, especially if players are expected to be able to connect to 3rd party servers.
(Not saying I necessarily disagree with you, just a counterpoint)
That's an argument for using C in gamedev, isn't it? ;)