#rust adherents are deluded in believing the idea that merely memory access violations are the only kind of way in which the security of software is breached

firstly, this only applies to binary code running on physical or virtualized hardware, where a kernel is managing access to memory - it isn't relevant to such runtime environments like WASM or JVM because they already have automatic access controls and generally are not targeted by languages that have pointer arithmetic

secondly, more often the problem comes from poorly constructed access control systems, where simplicity of the code is the key thing to enabling the developers to notice that there is a problem and prevent the code running in the wild to be exploited by hackers looking to breach potentially valuable user data

thus, the more complex and circuitous the language syntax is, the more ways in which it can be made completely idiosyncratic by the use of macro programming, the harder it is to learn the language, ie, the more complex the syntax, the more ways in which errors in ACL systems can be introduced and lead to methods to bypass the ACL and/or privilege escalate to enable read/write access to data that is supposed to be privileged

and lastly, a hard to understand, and difficult to learn memory management system, that prevents the aforementioned buffer overflow attacks, creates a false sense of security for those who make decisions about what language to implement a system with

most of the shitcoins now run smart contracts written in rust, and unless i'm mistaken, the frequency of breaches and hacks has not changed one iota

#fuckrust

The JVM has the String pool. An area of memory which is NEVER garbage collected. It only cleans itself on heap dump or application restarts. Unless you are encrypting client-side, your PII and credentials are stored in plain text in memory. #NoMoreJava

Reply to this note

Please Login to reply.

Discussion

that sounds like a nightmare... but in android runtimes it is one memory map per app right?

That gets a little complicated. The short answer is yes, but the are not any security measures preventing heap dumps from memory access violations. If your application is on the device, it can cause a dump and grab the info from it.

does this require an exploit in the app itself or is this an exploit in linux LXC namespaces?

Neither. This is a weakness in how the JVM responds to invalid memory access. While there are some security issues existing in the LXC namespace, they do not correlated with this issue.