Highly critical “Ghost” allowing code execution affects most Linux systems (Ars Technica)

I read it all, three times, and reviewed the linked article, before replying. You may know what you meant with what you said, but you omitted much. I thought that _maybe_ you were referring to ability to edit the data pulled from the config files, but couldn't see how you thought that helped with a design where the config file is parsed into variables which hold the individual settings. Now, some of those are subject to re-expansion, and it might be useful to adjust the memory pool used for allocating storage for all stuff coming from a config file, so that it can transition to read-only at a later point, but you're into seriously diminishing returns here: you're tackling one subset of potential avenues of attack, once an attacker can overwrite memory, but really once memory overwriting has happened, you're fighting a battle you've already lost. Yes, it's reductively true that mprotecting away access is "better", but I don't think it's productive as anything more than barely-above-theatre.

The real issue is that for too long, C has been the only practical language for portable Unix systems software development, and the degree of care required to prevent problems such as off-by-one errors tramping memory elsewhere approaches superhuman. It's been 30+ years and we're still discovering issues in base BSD code. If I were starting an MTA project from scratch, instead of helping maintain one, I damned well wouldn't write it in C. Heck, on some systems, we can't even trust the base system services library. ;)