Hacker News Reader

Comment by jrochkind1 | Hacker News Reader

> I'm less thrilled about it being written in a garbage collected language

What are the security problems with garbage-collected languages?

(not being sarcastic, don't have an agenda, I have no previous knowledge on this, and am not a security expert. Just had never heard this suggested before, and am curious what he meant. Legit question!)

View on HN

Usually security nuts like to override the clear-text string with zeros or random characters before calling free() on it. This way, if this chunk of data stays in memory (which is most likely the case with libc's free()) it cannot be read by exploiting a buffer overflow.

With garbage collected language, programmers don't know when their variable is "free()ed", since it could be held in multiple thread, and the last thread dying will release the memory for this variable. Since programmers often don't know when the password variable will be "free()ed", it is very unlikely that they scrambled the password before releasing the memory. Thus, leading to the password being kept in some region of the program memory, in clear text, exploitable by a buffer overflow & co. for an indefinite amount of time.

Another thing to note about garbage-collected languages (like Java with the G1 collector) is that blocks of memory will often be *copied* to other parts of the physical memory as part of compaction phase [1] (see quote), in order to be able to provide large segments of sequential space. Since the GC is designed with performance in mind rather than security, the original copies are not zero'd as part of this compaction, and instead their raw data will potentially stay in memory indefinitely until overwritten by another part of the application, and will not be zero'd upon termination of the application. Because of this, even with meticulous tracking of references and "raw" memory access only, GC'd applications can leave traces of secrets on memory. There may be workarounds for this by exclusively using "Unsafe" methods, but that drastically limits your API-interoperatility with libraries and such.

> G1 reclaims space mostly by using evacuation: live objects found within selected memory areas to collect are copied into new memory areas, compacting them in the process. After an evacuation has been completed, the space previously occupied by live objects is reused for allocation by the application.

[1] https://docs.oracle.com/en/java/javase/18/gctuning/garbage-f...

> Usually security nuts like to override the clear-text string with zeros or random characters before calling free() on it.

If you are worried, you can store the password in a byte array and zero that out.

But further, a buffer overflow is practically impossible with a GCed language (especially a popular one). A programmer using a GCed language cannot write code which has a buffer overflow. That must come from a bug in the runtime itself. Not likely.

As far as I'm aware, every gced language has bounds checks on arrays. Certainly all the popular ones.

> 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).

The majority of GCs on the market are tracing collectors. Memory is periodically collected when it is not longer referenced (mark and sweep). What triggers that collection is a whole host of potentials interactions. How frequently and deep it runs also depends on a lot of application characteristics.

> If you are worried, you can store the password in a byte array and zero that out.

if it's a copying collector this is no guarantee of anything

but the same is true of general memory allocated with the OS (swap/THP/...), unless you use something like mlock()

Fair point, but really one of those situations where if an attacker is in the position to look at a password stored in a tombstone, you've got bigger problems (for example, would be trivial in that scenario to simply intercept the password rather than looking for it in VM memory).

Could it still add some defense in depth for other scenarios?

> 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=...

> 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.

By checking if things are referenced or not as the basis for collection is a bad idea.

Take 2 classes that reference each other, but nothing references either.

In your example they won't get cleaned up. You'll want a tree-based collector. If an object is no longer referenced from the tree it can be cleaned up.

Funnily enough, if you are using the clipboard to enter your passwords most of this is pretty moot.

>With garbage collected language, programmers don't know when their variable is "free()ed", since it could be held in multiple thread, and the last thread dying will release the memory for this variable

And there is simply no way to deal with this, technology just isn't there yet.

> it cannot be read by exploiting a buffer overflow

What does the attack that does this actually look like? Lastpass reads text off an html page and decides when to inject auto-fill prompts and/or enter in a password. Is it possible for a buffer overflow to be exploited there, that lets an attacker (who controls the site) gain access to a password for a different site? How does that work?

Is there some other attack possible here? Ie: is it possible another user-space application can read passwords from memory used by the password manager? How does another app know it's a password? How does it trigger a buffer overflow?

(I'm ignoring apps running with kernel or privileged access: that seems like game over)

CPU side channel attacks are a possibility. In the worst case, it could let an attacker cross OS process boundaries, making it exploitable remotely through Javascript executed in the browser. Although such vulnerabilities would be hard to find and even more difficult to exploit on scale, the possibility seems more realistic than it did pre Meltdown & Spectre. It would be nice if something as high stakes as a password manager was prepared for this kind of scenario.

You should be able to know all the references to a variable, if you are careful when writing your program. Also, you could write a destructor that scrambles the memory location before the object is collected. However, you would still not have control over copies that the GC may decide to make and it is a bit trickier to force a free, since the GC is in no obligation of freeing an object as soon as it has no more references (though you can probably force that to happen in most GCed languages).

In most GC languages, the String type itself is not a managed handle to a single memory buffer, but a reference into a whole copy-on-write datastore. So you can't even scramble the underlying memory - mutating the string to erase it will not zap the original, it will just create a copy.

Your best bet is to ensure no references to the password string exist - including in library code you may use, which means constant revalidations whenever you update a library or your underlying language runtime. Once you do that, you can force garbage collection, either by some explicit language mechanism to request garbage collection, or by trying to allocate gobs of memory in some way that can't be easily optimized out.

You don't need to use the String type for your sensitive data, though. You can create your own type that acts the way you want.

There are strong incentives to use the built-in String class. APIs for UI will use it. The first google result for "c# Clipboard" certainly uses string. It'll be a lot of extra effort, that you might not have with a different language. That is, if actually you consider the risk worth it... i probably wouldn't.

To avoid the risk outlined here, knowing all the references to a variable is not sufficient; without an understanding of their lifetimes in every possible permutation of the program's use (and misuse), you cannot act on that information to minimize the exposure posited here.

I won't get into the question of whether a programmer should also know all that, as there is another consideration which renders it moot: Even with a non-GC'd language, a programmer could leave variables with sensitive information in memory for the remaining duration of the program (e.g. local variables left deep in the stack when a function returns or throws an exception - do you know when they will be overwritten?) What matters here is that the programmer understands the risks, knows what constitutes the most sensitive data, and acts accordingly - but, armed with that knowledge, the programmer can just as well ameliorate the risk in a GC'd language as one that is not.

> You should be able to know all the references to a variable, if you are careful when writing your program.

The issue is: what if thread A and thread B hold a reference to the password variable? And you don't know in which order they will execute. In which thread do you scramble the password before releasing the variable reference?

From what I understand, OP's point is: because of the nature of C, you have to know where your variable is "free()ed", because you have to do it yourself. Therefore you can scramble there. Even if you have two thread doing:

    n = decr_reference(password)
    if (n == 0) {
      scramble(password)
      free(password)
    }

That issue seems the same in a GC language as it is in a non-GC one. Either way you need to know when you're done with the data and it's time to scramble.

One possibility would be to reference a password variable always from t he same thread. But even if you use multiple threads referencing the same memory location, you could make some of them weak references (which the GC doesn't take into account when deleting the object) or you could make sure you stop referencing them in both threads and force the GC to run on that object. The destructor could handle the scrambling.

> Also, you could write a destructor that scrambles the memory location before the object is collected.

This assumes you can write destructor at all and that it's run deterministically.

> though you can probably force that to happen in most GCed languages

I'd actually be surprised if any GC'd language allows this. You normally need to resort to different kinds of tricks for RAII-like behavior.

Python has `gc.collect` which should work for user created types. Besides, it does have a reference counting GC. So, as long as you don't create cycles, you should be able to force the collection of objects similarly to C++'s shared_ptr.

Java has try-with-resources for this. Python has with. Unlike say C++ you do have to indent your code once for every such resource though which can be cumbersome.

Neither of these things are equivalent to destructors, however

They aren't equivalent but they can do the task in question:

   with prompt_password() as password:
     stuff

Once the scope exits, the context manager can scramble the memory.

Nono, a lot of GCs copy the whole known variables to a new area, then delete the old area in bulk (“but it consumes twice as much memory!?” yes, but it’s very efficient - doesn’t require tracking). Therefore you may have a constant char[] and it could still be in 2 places in memory.

An interesting point and I wonder if there are thoughts on if the JVM should implement flags that do overwrite before gc (obv worse perf but some cases have use for it).

Or at the least, let a program implement parts of the gc api and plug it in themselves.

You can with the JVM.

https://docs.oracle.com/javase/9/docs/api/java/lang/ref/Clea...

However, the issue isn't so much that doing that, rather it's that GC will potentially never collect the memory. In the JVM, the GC primarily runs when enough allocations happen. It's not on some timer.

So the concern would then be having a password sitting in memory for hours (or even days) on end.

Typically you would be using something like JCE for these sensitive functions, and a JCE implementation could be written (potentially with VM support) to have such functionality. These also can do things like zero out binary data/keys after use.

This wouldn't help once you create your own objects however, e.g. JSON parse from a decrypted block.

There are definitely mechanisms to do this in the JVM, such as the `finalize` method or in more recent versions, the `java.lang.ref.Cleaner` class.

However, using them correctly in the context of memory leakage and safety is non-intuitive and is definitely a bit tricky.

they don't know when it's going to be freed, but they do know when they're not going to need it anymore and can overwrite it exactly like in C. or am I missing something?

Yes. Except unless of course you're not certain if the buffer you have your secret in was copied at some point. Maybe by the text control you rendered it in.

Can we not simply overwrite the the data when we're "done" with it and then not worry about when it's actually unallocated by the GC?

Depends on the type and language. For example, in Java strings are immutable. Therefore you can’t really write over it.

That's fair, a lot of GC languages use immutable strings. That said, all(?) of them have some form of mutable buffer, albeit some care would have to be taken to avoid accidentally turning it into a string.

Then for sensitive strings you wouldn't use the built-in string and have to build your own?

I'm not sure I see the issue, you just implement a memory-safe string class that manages arbitrary bytes, it's slower but that wasn't the goal.

I can’t remember off the top of my head which major Java library I was using a few years ago but that’s exactly how it took sensitive string params - via a char array instead of a String object. I was scratching my head why they would do that for a bit until I learned.

The GC may copy data around, though. So, when you scramble the data there may be already be copies of the previous value in memory. I think that's the biggest drawback.

People have described the concern about memory not being zeroed in a predictable way, but not why that's a security concern. And, honestly, for most people I don't think it is. If an attacker is in a position to read arbitrary memory out of your browser then the chance that they won't obtain something else about as powerful as a password (eg, a valid session cookie) seems minimal. Or a crash dump file may include passwords, but then how does someone have access to that and not be able to read your cookie store? For a niche set of people I think there's greater concern around cold boot attacks - someone with physical possession of a suspended machine powers it off and quickly boots another OS, then dumps RAM (think laptop being taken away from you in an airport situation). That can be mitigated through firmware just wiping RAM on unclean boots (TCG has a spec for this, Linux and Windows implement it), and getting around that involves much more invasive attacks.

I don't want to say the concerns are entirely unwarranted, but I really don't think it's a big deal for the vast majority of people.

At the risk of conjuring a strawman, I've heard people worry about the loss of control, like maybe the process has some sensitive data in RAM that it will release and then the OS will alloc() it to another process. And that's true on one level, but nothing prevents a garbage collected language from overwriting all the data in a block of RAM as it free()s it. I think the risk of memory related bugs in a non-managed language is far, far greater than any GC-related hypothetical risks. And then you have languages like Rust which "feels" like it's a GC language because it manages all the alloc()s and free()s for you, but isn't GC at all because the language's semantics make those calls deterministic.

I'd vastly rather see sensitive security software developed in a modern garbage collected language (or in Rust and similar languages) than in C or C++.

> At the risk of conjuring a strawman, I've heard people worry about the loss of control, like maybe the process has some sensitive data in RAM that it will release and then the OS will alloc() it to another process.

I'm sure some people worry about this, but I think you will be hard pressed to find a modern OS that actually would give away your contents to another PID.

Just because a program can malloc(8), fill eight bytes with known content, free() the pointer, malloc(8) again and see their old content doesn't mean the OS hands your data to anyone, just that the libc (or whatever runtime you use) is not actually getting a whole page for that single 8 byte malloc, and it didn't give it back to the OS at free() either, so you "owned" the page where those 8 bytes lives all the time during execution of this simple test.

The limit for which your allocator starts _actually_ handing back data is probably never less than 4k and upwards to 256k depending on page size, malloc settings and OS/libc defaults.

So while there are a lot of traps code can fall into as mentioned in other comments in this thread, I think everyone can stop worrying about "the next program to malloc() will get my old data" because that just doesn't happen.

The arguments people are giving about being able to explicitly call `free` make a lot of sense to me for getting rid of some attack vectors, but it still seems like the security risks of using a memory-unsafe language would heavily outweigh the risks of the garbage collector not clearing strings fast enough?

I know that's not an either-or proposition, there are memory safe languages that aren't garbage collected. But if people aren't talking about those languages, if they're just bringing up C or something...

I am not an expert, I might not know what I'm talking about here at all -- but my instinct is that I would rather see security-critical code written in a garbage collected language than in C. Frankly, I don't trust developers not to make memory errors in C.

Maybe I'm underestimating the risk of the garbage collector not zeroing out variables? Or maybe I'm over-complicating it and the answer is just the obligatory "write it in Rust" refrain so you can avoid both problems?

But I'm also a little surprised to see this line, my impression was that security advice was starting to trend towards recommending GC languages, not away from them.

These kind of concerns are so funnily out of touch.

The real dangers always turns out to be crazily bad security practices (the kind obvious to everyone after the fact), not theoretical attacks that probably weren’t ever demonstrated in the wild.

I'm not an specialist, but I suspect the rationale is that you have less control of how the memory is cleaned up after use. In special, the GC can actually copy objects around without the programmer's knowledge, potentially making multiple copies of secrets which the programmer cannot clean up (by setting the bits randomly) later on. Without a GC, the programmer is able of knowing how many copies there are of any given secret and can dispose of them, if needed. On that note, probably writing their own "malloc" is probably a good choice.

That said, I'm sure there are workarounds even in GCed languages. For instance, you can usually create C extensions which could allocate and manage memory outside of the GC's control. So, such extesion could potentially give back memory control of certain special memory regions where secrets can be stored, while everything else just goes through normal GC.

I buy the explanations that they mostly want to be able to explicitly overwrite sensitive memory at a time of their choosing.

My question: does the nondeterministic execution pauses that garbage collection injects into a program's runtime aid or prevent timing attacks?

It seems like it would prevent them, since it makes it that much harder to predict execution duration, but I have this vague impression that high-security operations are more likely to demand real-time computing. Maybe that's just incidental, and applications that must highly perform also tend to need to be secured from attack?

I suppose it's a lot more difficult to wipe memory clean in a garbage collected language.

For example:

    password = "my-secret-password";
    // do stuff then remove the pass from memory
    password = "" or null or delete or unset

We have no guarantee that the first string "my-secret-password" will be collected and removed any time soon whereas in C or C++ we could just memset it before freeing it.

But that feels like a very generous interpretation, I'm sure the author really meant it as a "real programmers don't use GC language"...

C# has SecureString. I assume BitWarden uses this.

edit: https://learn.microsoft.com/en-us/dotnet/api/system.security...

Interestingly, in those docs they recommend against using that class and point to this github repo explaining the reason: https://github.com/dotnet/platform-compat/blob/master/docs/D...

To be pedantic, they're not saying the class is making things worse - it just doesn't do anything on .NET Core because it lacks cross-platform encryption APIs comparable to the ones used on .NET Framework. So it's basically just a String.

It's a little frustrating that their only recommended alternative is "just give us your secrets bro" though:

> The general approach of dealing with credentials is to avoid them and instead rely on other means to authenticate, such as certificates or Windows authentication.

Nice. Less of a SecureString and more of a SlightlySmallerWindowOfInsecurityString. TIL.

There's a pretty important note in the remarks, that you should not use SecureString in new code, as it only shortens the lifespan of the plaintext in memory.

That's only if you use immutable strings. In C# or js (and probably in others as well) you can use some form of byte arrays / buffers, and overwrite their content after use.

those references aren't real pointers though, the underlying runtime may have copied/moved around the underlying memory behind the scenes

Technically C/C++ have an as-if rule (the optimizer can do whatever it wants as long as the program behaves as-if it ran the source code provided) that allows the optimizer to create cached copies and/or omit the memset. There is no way to express in C/C++ that all traces of a given variable should be removed. Though I guess there are constructs that work well enough in practice and you can always check the generated assembly.

If anything I would intuit such an implementation is sacrificing performance for security, since it rules out some classic vulnerabilities.

> What are the security problems with garbage-collected languages?

None that I'm aware of. I think this is a petty swipe at programmers who use garbage-collected languages, implying they're "less" than programmers who use "real" languages that don't have garbage collection.

Reply on news.ycombinator.com