3 ms·

This might be a bit of a strange question, but it's interesting to think about and I know antirez will probably read it here, so I want to bring it up: Could t

This might be a bit of a strange question, but it's interesting to think about and I know antirez will probably read it here, so I want to bring it up: Could there be some potential privacy or data-leakage concerns with this, since the server is now storing and acting on info about what data has been accessed, by which clients, and even when (to a limited degree)? For example, say that some kind of sensitive data is stored in redis (e.g. user private messages). By watching for relevant invalidation messages (or if there's any way for clients to read the data in the Invalidation Table directly), it could be possible to learn some info about how that data was accessed. Without knowing more about the implementation, I don't know if this is even a concern at all, and I haven't come up with a specific method of abusing it even if it is. I think it's probably something to keep in mind though.

jhgg 7y ago
No more risk than using MONITOR.
- Deimorz 7y ago
  MONITOR can only be used through redis-cli or telnet, you already need a very high level of access to the server for that. I'm thinking about more subtle methods of using this info, where a client might be able to get info about the activity of other clients (or other users of the same client through something like a web application). If someone already has full access to the redis server, then yeah, I can't imagine how this would expose anything more than what's already available.
  - jhgg 7y ago
    What? MONITOR is a command like all other commands - you can run it from a client, or really, anything that can establish a TCP a connection to the Redis server. (Eg telnet.).
    - Deimorz 7y ago
      Right, but if someone has the ability to run arbitrary commands on your redis server, they can already look at or do whatever they want with your data. We're agreeing: if someone can already run MONITOR, this won't make anything worse.
      - jhgg 7y ago
        Yes, and my point is, if the client is connecting to a redis server, it can just run MONITOR to see all the "sensitive" data you are talking about, and thus, this new feature poses no additional privacy risk. If you cannot trust your client to talk to your database, this isn't a problem with the database, but a problem with the client. In your specific example, your client is also probably the one issuing the commands to store and retrieve the private messages in Redis - meaning, it already has access to all the data required for a breach. If you have an unrelated workload that is accessing a shared redis, but it does not need access to the sensitive data, perhaps, use an ACL to limit clients from the alternate workload to a different redis DB (which provides some level of isolation), or simply use a different redis entirely, and don't allow clients running the alternate workload to connect to the database that contains sensitive data.
antirez 7y ago
Everything could be a risk, but in the specific case of a software device holding data, I believe that the main problem is the exposure of the data itself, so in the specific case of Redis the fact that the database stores informations about which key was retrieved by which client should not be an issue AFAIK. A few random arguments: 1. The database anyway sees such connections and there is a continue stream of activity about clients, so there is also an instantaneous state that discloses who does what, at any time. 2. Companies trace everything in order to have data to do debugging when there are problems, so this information is stored at a much better level of details in other places as well. 3. There is no obvious way this could be exploited. 4. In general it is supposed that the clients can trust the server. 5. If you already violated Redis in order to read such info (not accessible via APIs), you can collect a lot more. So based on initial thoughts I don't think this is going to be ever a security problem.
- jonny_eh 7y ago
  Also, the client needs to opt-in.
inlined 7y ago
It doesn’t seem to be a major vulnerability unless you have the ability to guess keys you don’t have access to via hash and get their invalidation notice. You still would have to force a hash collision, won’t know which key caused the invalidation (unless you can guarantee that there is just your key and their key on the hash), and won’t get new data. All in all it seems pretty minimal, especially since it’s an insider attack where micro services don’t trust each other.
banachtarski 7y ago
This question doesn't make any sense. If your users can access the ip/port of your redis instance, you're already hosed regardless of whether the redis clients cache requests or not. The only hypothetical surface area opened up is if an attacker manages to install a virus on your server to snoop memory via sidechannels. But in this case, your data is already vulnerable using normal queries (the data must reside in memory eventually), again, regardless of whether data is being cached client side or not. Most applications most likely already cache data, at least in a variable or something for the duration of a particular function.

jhgg 7y ago

No more risk than using MONITOR.

Deimorz 7y ago
MONITOR can only be used through redis-cli or telnet, you already need a very high level of access to the server for that. I'm thinking about more subtle methods of using this info, where a client might be able to get info about the activity of other clients (or other users of the same client through something like a web application). If someone already has full access to the redis server, then yeah, I can't imagine how this would expose anything more than what's already available.
- jhgg 7y ago
  What? MONITOR is a command like all other commands - you can run it from a client, or really, anything that can establish a TCP a connection to the Redis server. (Eg telnet.).
  - Deimorz 7y ago
    Right, but if someone has the ability to run arbitrary commands on your redis server, they can already look at or do whatever they want with your data. We're agreeing: if someone can already run MONITOR, this won't make anything worse.
    - jhgg 7y ago
      Yes, and my point is, if the client is connecting to a redis server, it can just run MONITOR to see all the "sensitive" data you are talking about, and thus, this new feature poses no additional privacy risk. If you cannot trust your client to talk to your database, this isn't a problem with the database, but a problem with the client. In your specific example, your client is also probably the one issuing the commands to store and retrieve the private messages in Redis - meaning, it already has access to all the data required for a breach. If you have an unrelated workload that is accessing a shared redis, but it does not need access to the sensitive data, perhaps, use an ACL to limit clients from the alternate workload to a different redis DB (which provides some level of isolation), or simply use a different redis entirely, and don't allow clients running the alternate workload to connect to the database that contains sensitive data.

antirez 7y ago

Everything could be a risk, but in the specific case of a software device holding data, I believe that the main problem is the exposure of the data itself, so in the specific case of Redis the fact that the database stores informations about which key was retrieved by which client should not be an issue AFAIK. A few random arguments: 1. The database anyway sees such connections and there is a continue stream of activity about clients, so there is also an instantaneous state that discloses who does what, at any time. 2. Companies trace everything in order to have data to do debugging when there are problems, so this information is stored at a much better level of details in other places as well. 3. There is no obvious way this could be exploited. 4. In general it is supposed that the clients can trust the server. 5. If you already violated Redis in order to read such info (not accessible via APIs), you can collect a lot more. So based on initial thoughts I don't think this is going to be ever a security problem.

jonny_eh 7y ago
Also, the client needs to opt-in.

inlined 7y ago

It doesn’t seem to be a major vulnerability unless you have the ability to guess keys you don’t have access to via hash and get their invalidation notice. You still would have to force a hash collision, won’t know which key caused the invalidation (unless you can guarantee that there is just your key and their key on the hash), and won’t get new data. All in all it seems pretty minimal, especially since it’s an insider attack where micro services don’t trust each other.

banachtarski 7y ago

This question doesn't make any sense. If your users can access the ip/port of your redis instance, you're already hosed regardless of whether the redis clients cache requests or not. The only hypothetical surface area opened up is if an attacker manages to install a virus on your server to snoop memory via sidechannels. But in this case, your data is already vulnerable using normal queries (the data must reside in memory eventually), again, regardless of whether data is being cached client side or not. Most applications most likely already cache data, at least in a variable or something for the duration of a particular function.