2

Realizing that garbage collection and memory management is implemented differently in different environments for sake of simplicity this question will focus on JavaScript (either V8 or Seamonkey).

I realize that garbage collection is a means to determine if a portion of memory needs to be deallocated or not. The simplest example I know of is setting a variable to null:

var x = 'foobar';
// x)-┐
//    V
//   ┌-┬-┬-┬-┬-┬-┐
//   |f|o|o|b|a|r|
//   └-┴-┴-┴-┴-┴-┘
x = null;
// x)--> null
//
//   ┌-┬-┬-┬-┬-┬-┐
//   |f|o|o|b|a|r| Eligible to be garbage collected
//   └-┴-┴-┴-┴-┴-┘

So I was musing how can I securely change the value so that it isn't available to poking? I realize this is a purely contrived example. The reason I ask is to better understand how memory is allocated in JavaScript and if there are methods of data manipulation that would avoid reallocation of memory leaving some of it littering up the free memory space.

In other words can I change the memory values in JavaScript or is reassignment the only way leaving it in free memory?

To further illustrate my contrived example, let's say I want to store a password but then securely obfuscate it before I send it into garbage collector land. I believe Reassignment would look like this:

var x = 'foobar';
// x)-┐
//    V
//   ┌-┬-┬-┬-┬-┬-┐
//   |f|o|o|b|a|r|
//   └-┴-┴-┴-┴-┴-┘
x = '******';
// x)--------------┐
//                 V
//   ┌-┬-┬-┬-┬-┬-┐┌-┬-┬-┬-┬-┬-┐
//   |f|o|o|b|a|r||*|*|*|*|*|*|
//   └-┴-┴-┴-┴-┴-┘└-┴-┴-┴-┴-┴-┘
//    \_________/
//         |
//         Eligible for garbage collection
x = null;
// x)--> null
//
//   ┌-┬-┬-┬-┬-┬-┐┌-┬-┬-┬-┬-┬-┐
//   |f|o|o|b|a|r||*|*|*|*|*|*|
//   └-┴-┴-┴-┴-┴-┘└-┴-┴-┴-┴-┴-┘
//    \_________/  \_________/
//         |            |
//         Eligible for garbage collection

So can I manipulate the first memory partition so that the values are not left in memory unreferenced but instead replaced so a memory scan would find the replacement instead of the old value?

2

2 Answers 2

3

"So I was musing how can I securely change the value so that it isn't available to poking?"

you can't. You have no access to the actual memory location where the data is stored, so you can't determine where you're writing.
The attempt to overwrite the data is likely to write to another location entirely.

3
  • Of course, in a language with mutable strings (e.g. Ruby) things are different - it's not the garbage collection process itself that prevents this, but the combination of immutable strings (so you can't directly change the data) in a type-safe language (so you can't work around the restriction and directly access the memory the string is stored in).
    – Jules
    Oct 6, 2015 at 15:53
  • @Jules not necessarily. You don't know how the VM handles things internally, it could reassign to the new string and then discard the old (though I doubt that happens, it's not very efficient).
    – jwenting
    Oct 6, 2015 at 16:42
  • @jwenting: It's more than likely that JS engines will write the new data to another part in memory, given that -last I checked- all engines manage memory using a mark-and-sweep strategy. As for higher-level languages like ruby reassigning a string and then discarding the old one: that wouldn't be that outlandish. Mutable strings can require the VM to do something like realloc + strncat. realloc in turn can result in something like malloc + memcpy + free Oct 8, 2015 at 13:45
2

So I was musing how can I securely change the value so that it isn't available to poking?

In JavaScript, you cannot. However, there is a need to delete sensitive data, so other languages have workarounds. For example, in Java 8 the Destroyable interface was added so that sensitive objects can be cleanly destroyed, but this requires implementation support. Currently, JavaScript does not support anything like this. Garbage collection does not make it impossible to protect sensitive data from poking, it just requires implementation support.

3
  • You may wish to expand on why poking cannot be prevented in Javascript and why you are mentioning Java 8 for someone who is asking about Javascript.
    – Jason K.
    Jun 17, 2020 at 17:09
  • Also, any Destroyable object must keep its sensitive data outside the managed head to avoid heap-compaction leaving copies, so significant parts of its implementation have to be native. Jun 17, 2020 at 19:24
  • @deduplicator This is true, but I don't see a clean way to mention it. Please take a shot at it if you have the time. Jun 18, 2020 at 17:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.