3 ms·

> But further, a buffer overflow is practically impossible with a GCed language (especially a popular one) Because the JVM had no buffer overflow? [1] Also I p

> But further, a buffer overflow is practically impossible with a GCed language (especially a popular one) Because the JVM had no buffer overflow? [1] Also I purposefully wrote "buffer overflow & co" because buffer overflow are not the only possibility. Shellcodes could ptrace() and inspect the memory of the program. > > the last thread dying will release the memory for this variable. > Really not how GCed languages work. Memory lifetime is not bound by thread lifetime except in the rare case when memory is bound to a thread (static/global variables). That was bad phrasing from by part. You should have read "the last thread releasing the variable reference". [1] https://www.cvedetails.com/vulnerability-list.php?vendor_id=93&product_id=19117&version_id=&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=3&trc=707&sha=e7bd4bdaede94939bbb984bced9c264b834fc20c https://www.cvedetails.com/vulnerability-list.php?vendor_id=...

cogman10 4y ago
> Because the JVM had no buffer overflow? Happens extremely rarely and is frequently not in JVM core code but rather something like the 2d renderer or applets. Code not likely to be executed on a server. Take a deeper look into those CVEs and count how many are for Java 8+ and server code (it's a pretty short list). You might as well argue the linux kernel is insecure because there's been buffer overflows in the various drivers. > Shellcodes could ptrace() and inspect the memory of the program. Certainly, and they can redirect socket traffic and inject a MITM for any process to directly intercept a password. Even if you are zeroing memory, there will be a period of time when a password is present in memory which means the ptrace attack also works with C. The bad part of a managed language is that passwords stay in memory for longer, but that risk is somewhat moot considering exploiting requires a compromised system. In which case, there's little reason to pull out passwords by sniffing memory.

cogman10 4y ago

> Because the JVM had no buffer overflow? Happens extremely rarely and is frequently not in JVM core code but rather something like the 2d renderer or applets. Code not likely to be executed on a server. Take a deeper look into those CVEs and count how many are for Java 8+ and server code (it's a pretty short list). You might as well argue the linux kernel is insecure because there's been buffer overflows in the various drivers. > Shellcodes could ptrace() and inspect the memory of the program. Certainly, and they can redirect socket traffic and inject a MITM for any process to directly intercept a password. Even if you are zeroing memory, there will be a period of time when a password is present in memory which means the ptrace attack also works with C. The bad part of a managed language is that passwords stay in memory for longer, but that risk is somewhat moot considering exploiting requires a compromised system. In which case, there's little reason to pull out passwords by sniffing memory.