... Are buffer overflows an intrinsic risk, or a symptom of bad software engineering?
as long as stack memory is immutably executable, and software is written in the C language, buffer overflows are an intrinsic (though manageable) risk. one expects that they don't program interplanetary missions in C.
... But its easier to fix a well-designed system than one held together with lots of duct tape.
and yet it's a lot harder to break 500 duct-taped systems of mixed and varied heritage than to break one well designed system. monoculture is intrinsically brittle no matter how strong the genes themselves may be.
SSH is worth the protection, as reference implementations are available, and it requires very little in the way of system support.
and it's been broken a couple of times now, from buffer overflows to integer overflows. and now i hear that mr. bernstein has a paper out about how RSA isn't nearly as secure as we thought it was, and there's a rumour of another ssh integer overflow attack in the offing. there's no silver bullet or silver buzzword. programs written in languages other than C are susceptible to buffer overflows, bitswizzlers other than just RSA will turn out to be trivial in hindsight, IPsec and DNSsec and XYZZYsec will each turn out to be crocks of dung at some point in the future. but for some values of "now", each might have its place. the best security-related records will be set and held by people and companies who are unceasingly vigilant and who practice professional risk management, and not by people or companies who depend on silver buzzwords. (note that i hold the single-author record for total CERT advisories, proving that in my copious youth i knew how to sling code but not how to manage risk.)