[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
I think Assembler, C, and C++ basically make it too easy to go wrong. I know I have released code with such issues. The criticism of Rust having "unsafe", when most of the time it is used to access existing libraries in these unsafe languages is misguided, it provides probably the most reasonable approach to making things safe, whilst not insisting everything be reinvented now (although it is getting close). Whilst there are safe subsets of C++, it is going to be a mammoth task to separate that subset from existing code bases, primarily a branding exercise, think "TypeScript" for typing in JavaScript. But pragmatically if safe code is in ".cpps" or some such then it might become acceptable. Maybe call the compiler "gccs" so it fails hard unsafe code unless it is explicitly tagged. Realistically what software purchasers want is a guarantee of memory safety in new code, or in entire products. Java has essentially given this and taken over the business world, but Java lacks some of the safety elements which ironically native languages have. You don't have protection on memory regions, because Java is interpreted, and rewrites and optimises its byte code at run time. In theory if it is memory and type safe (which was still a question last time I looked) then it shouldn't be exploitable, but we all know that these things break down if they aren't enforced somewhere. Also worth noting that exploitation of these types of memory vulnerabilities is becoming pretty specialist. Especially on things like iPhones, with their latest set of memory protections on the iPhone 17 and back ported to previous versions in some cases. So whilst these issues still often underlie some of the worst incidents, creating these exploits has gotten much harder quite quickly (I remember when you could just chuck a bunch of nulls and standard shell code into a buffer overflow and something useful would quite often happen without having to understand memory layout, or return orientated programming etc. For me the issue was always more manually managed memory programs were more likely to corrupt their memory leading to crashes, or worse still corrupted output. Where a database, or a log, is corrupted, or corruptible. Rather than necessarily a skilled attacker using some sort of fancy return orientated programming to get a shell on a web server, if you log in and find your credit card system has bits of emails where the financial logs should be, as I dealt with on a Unix system written in C with a wonky Token Ring driver once. I'm sure said bug was also exploitable, but in reality I was called in because there was email data in the credit card log and no one knew why. That some genius hacker could also have stolen the credit card data that route, well it would have been a hard way to get the 5 million credit card credentials (would have been easier to pose as an IT consultant with expertise in fixing them ;). Simon -- The Mailing List for the Devon & Cornwall LUG FAQ: https://www.dcglug.org.uk/faq/