10

I'm reviewing a system that is using Redis to store all client secrets, private keys, and other things. The problem is that Redis loads the entire DB into RAM

Since SSL's heartbleed, Rowhammer, and other hacks are known to expose memory to untrusted users, I would think that any other similar hack might expose the entire database, wherein if I used SQL server, fewer private keys would be in RAM at a given time.

There is probably a better way to do this.

Since they are required to host and store client's secrets and PI, I want them to use a load on demand approach and not too aggressively load unneeded data in RAM, and unload whatever I have in RAM as soon as possible.

If I subscribe to the philosophy that ....

My data is safer from attack when there are fewer copies of it laying around

... then what is the best approach to reduce exposure in RAM? SecureErasing of memory?

I'm looking at SecureString with ASP.NET, and DiskIO, but I'm hard pressed to find an end-to end implementation that doesn't leave unneeded copies of the string in drivers, prefetch queues, or other locations.

Community
  • 1
makerofthings7
  • 50,090
  • 54
  • 250
  • 536
  • 5
    Why would anyone downvote this? – HorseHair Mar 22 '15 at 13:59
  • 1
    While I understand the need for risk analysis, surely the solution here isn't doing away with Redis, but rather using hardware that is known-safe against Rowhammer? It seems that modern UEFI patches are decreasing the DRAM refresh timings, and there's currently no known practical attack against ECC. – Polynomial Mar 22 '15 at 21:19

1 Answers1

6

The risk/issue is exactly the same and the mitigation as well. Regardless if it loads the database partially or completely into memory. There will be no way for you to tell which keys have been compromised and which haven't. So the only option would be to revoke them all, regardless if it's a Redis or SQL database.

Most of the time the reason why people are using Redis vs SQL is because of performance issues. I think the likelihood of such a succesful attack is considerable low if you have a decent design and prevent direct exposure of your database server. If they already implemented this then the investment to fix it on one hand will be great considering half of the codebase will require updates. I think you should look into isolating the Redis cluster, monitoring all operations (SIEM logs), seeing if you can implement extra controls (anomaly behavior) and verifying their incident response plan in case of breach, rather than shoot down their solution.

Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196
  • Perhaps if a partial load happened old, unaccessed secrets would be safe. Either database-side row level auditing would tell what was exposed over time, or the app can update a last-accessed field. – makerofthings7 Mar 22 '15 at 14:03
  • Thank you for the tips regarding design, mitigation, and the threat assessment. – makerofthings7 Mar 22 '15 at 14:03