4

Recently, at the organization I work for, we've been using a static code inspection tool.

One of the more interesting findings is that private information, such as passwords, may be stored in the heap where it could potentially be intercepted by an application scanning the heap or perhaps a disk swap.

The app being scanned is a web app that runs on a private web server behind a firewall, so I'm wondering if this finding is relevant.

The app is written in C# and the "remediation" suggestion is to store sensitive information in character arrays rather than string objects so that they aren't stored in the heap. I realize it would take up some time to properly remediate this issue, so I wanted to ask if this finding is relevant when the code runs on a private server because presumably, a hypothetical attacker would have to bypass the firewall and run malicious code on the web server to steal data.

Vivian River
  • 2,397
  • 5
  • 21
  • 32
  • I'm also questioning how storing a password in a character array is any safer. That password gets passed to some procedure, and most likely as a string... which gets allocated on the heap. – Greg Burghardt Nov 04 '21 at 03:26
  • My understanding is that a character array gets stored in the function call stack rather than the heap. – Vivian River Nov 04 '21 at 04:16
  • 3
    My understanding is that heap, stack, or static memory are all vulnerable to scanning since the only difference between them is what some easily ignored pointer thinks. – candied_orange Nov 04 '21 at 10:19
  • 1
    Related: [How to solve Heap inspection vulnerability for MVC viewmodel?](https://stackoverflow.com/q/40789379/3092298). – Greg Burghardt Nov 04 '21 at 11:33
  • To be honest, I'm lacking knowledge about this more than I care to admit. Now I'm doing a little searching too (for **c# heap inspection vulnerability**). A good read: [Why Should “Heap Inspection” Not Be Marked As False Positive?](https://kondukto.io/why-you-should-not-mark-heap-inspection-as-false-positive/). – Greg Burghardt Nov 04 '21 at 11:37
  • Depending on how important security is, consider planning for the longer-term to move away from handling credentials altogether; for example by choosing an OAuth2/OIDC provider (with MFA), or using certificates, etc. – Ben Cottrell Nov 04 '21 at 12:42
  • 1
    @BenCottrell This is a matter that upper management in the organization was sold this static code inspection tool and it falls on me to report back to them about the "findings" from this tool and how I "remediated" them. I can make changes to the code to "remediate" this "finding", or I can "suppress" it. I would like to be able to give them reasons for my decision. – Vivian River Nov 04 '21 at 14:00
  • Cross-posting is frowned upon, but this question might also be interesting on security.stackexchange.com. I assume this boils down to what your [threat model](https://en.wikipedia.org/wiki/Threat_model) is, and whether this vulnerability is an issue when taking into account that threat model. – Vincent Savard Nov 04 '21 at 14:11
  • For Java, see this SO question: https://stackoverflow.com/questions/8881291/why-is-char-preferred-over-string-for-passwords – Hulk Nov 04 '21 at 14:58

1 Answers1

1

In C# and Java, String objects are immutable, so they remain in memory until the GC decides to reuse that memory. A character array is mutable, so it can be overwritten with other (e.g. random or zero) data as soon as the credentials are no longer needed, reducing the time the data is potentially visible to attackers.

So the solution is not just dropping in a mutable type instead of an immutable string, but also requires actively overwriting it as soon as it is no longer needed. There are classes specifically designed for this purpose that make this easy, e.g. SecureString, but also note the disclaimers in the limitations section.

Whether that is relevant to your threat model depends on a lot of factors. For example, it is more relevant if

  • the difference between the time the credential data actually needs to be in memory (possibly only a few 100ms while assembling a request) between the uptime of your application (in the case of a web server, perhaps days or months) is large
  • the number of credentials that may be loaded into memory during the uptime of your application is greater than the number of credentials used concurrently.
  • your application is running in a context where the degree of isolation to other applications is not under your control

Of course, exploiting this vulnerability requires access to the memory, but note that this may be worse if you store coredump-files on crashes, or similar. If such a file leaks, you want it to contain the absolute minimum number of credentials possible. The likelyhood of that happening is up to your judgement... e.g. how likely is it for a server admin of your organisation to send the developer of the application a heap dump via unencrypted mail while debugging some problem?

Hulk
  • 508
  • 3
  • 8