0

I am getting this question from our clients where they are saying if we do Copy-Paste or store data in a variable, then there are chances where data can be hacked where a hacker can get the data from RAM and use it before GC disposes of it.

We generally don't dispose string objects where it gets stored in heap memory and will be collected by GC when it flushes the memory.

This is what I get about GC

The memory that is used by allocated objects on the managed heap surpasses an acceptable threshold. This threshold is continuously adjusted as the process runs. The GC.Collect method is called. In almost all cases, you do not have to call this method, because the garbage collector runs continuously

Is it possible where any hacker can get into RAM and read the data from it before GC flushes it? If yes, then how can we overcome it.

Programator
  • 81
  • 1
  • 3
  • 4
    You should probably prevent a "hacker" from getting onto your machine in the first place. Also have a look at [SecureString](https://learn.microsoft.com/en-us/dotnet/api/system.security.securestring) if you're storing passwords in variables. – Dennis Kuypers Aug 31 '18 at 02:19
  • I'm on the fence for whether or not this is a duplicate, but it's most definitely useful for the OP: https://stackoverflow.com/questions/26190938/is-securestring-ever-practical-in-a-c-sharp-application – David Aug 31 '18 at 02:19
  • 4
    If a hacker has direct access to RAM then you're toast. Hackers are much more likely to get data from social manipulation than unencrypted memory. What do these "expert" clients suggest? Also, strings are not disposable so you can't dispose of them, – D Stanley Aug 31 '18 at 02:20
  • Agree completely with other comments so far. If an attacker has control of the host, then that attacker has control of everything running *on* the host. – David Aug 31 '18 at 02:21
  • If you (as an atacker) can read arbitrary memory, then it's *game over*. You need to prevent that from being possible. The gc is irrelevant in that regard. – Jesper Juhl Aug 31 '18 at 18:12

2 Answers2

1

If the hacker can read memory in your process, the unpredictable lifetime of objects due to GC are the least of your problems. Any language is vulnerable to this kind of issue as computers effectively manipulate all data in memory (whether it's in a GC-able heap or elsewhere - C and assembly language need to store the data in memory too).

Technologies exist (like Intel SGX) that try to overcome this issue, but it too has exploits. Fundamentally, no software only solution can stop bad folks once they can read your memory.

Trent Gray-Donald
  • 2,286
  • 14
  • 17
1

I agree with the comments regarding the futility of trying to safeguard data in memory if an attacker already has the ability to read process memory entirely.

That said many attackers will be attacking via exploits that allow imperfect access to subsections of system memory, meaning use of SecureString is still of practical utility.

I recommend reading this thread for a discussion of the applications and limitations: When would I need a SecureString in .NET?

s3raph86
  • 556
  • 4
  • 17