Description
In the service-streamer framework's RedisWorker component, there exists a critical deserialization vulnerability. The vulnerability is located at lines 413 in service_streamer.py, where RedisWorker directly uses pickle.loads() to deserialize messages received from Redis queues without any sanitization or validation.The RedisWorker communicates with a Redis broker that can be configured to listen on any network interface, potentially exposing the service to network-based attacks. Attackers can send malicious pickle-serialized data through the Redis queue, which gets deserialized and executed on the server side, resulting in remote code execution.
Proof of Concept
-
Step1:
The victim starts a service-streamer server with RedisWorker. Typically it needs to bind to a local Redis service, so you must start redis-server beforehand. The network interface redis-server binds to determines the scope of impact — for example, if it’s exposed to the public internet, network-wide attackers could execute arbitrary commands on the service-streamer server.
-
Step2:
The attacker can then send malicious pickle dump data via streamer (_RedisClient). We give an example to show how can an attacker execute “ls -l”:
We also give a demo video in the attachment, along with PoC. When you reproduce this issue, you should:
1.On the server side, start redis
2.On the server side, run server.py
3.On the client side (attacker), replace the modified service_streamer.py
4.On the client side (attacker), run client.py
Impact
Remote code execution in the victim's machine over network. Once the victim starts the server, an attacker on the network can gain arbitrary code execution by scanning and finding the victim’s service.
Mitigation
(1)Sanitize data before pickle.loads it (e.g., rewrite Unpickler.find_class to set a whitelist), or use more secure deserialization methods such as safetensor or msgpack to replace the insecure pickle.loads.
(2) If the service is intended for internal use only, accept connections/data solely from the internal network. If it must be exposed to the public internet, add authentication.
(3) When starting the service on a public network, print a warning to inform the user.
PoC.zip
Description
In the service-streamer framework's RedisWorker component, there exists a critical deserialization vulnerability. The vulnerability is located at lines 413 in service_streamer.py, where RedisWorker directly uses pickle.loads() to deserialize messages received from Redis queues without any sanitization or validation.The RedisWorker communicates with a Redis broker that can be configured to listen on any network interface, potentially exposing the service to network-based attacks. Attackers can send malicious pickle-serialized data through the Redis queue, which gets deserialized and executed on the server side, resulting in remote code execution.
Proof of Concept
Step1:
The victim starts a service-streamer server with RedisWorker. Typically it needs to bind to a local Redis service, so you must start redis-server beforehand. The network interface redis-server binds to determines the scope of impact — for example, if it’s exposed to the public internet, network-wide attackers could execute arbitrary commands on the service-streamer server.
Step2:
The attacker can then send malicious pickle dump data via streamer (_RedisClient). We give an example to show how can an attacker execute “ls -l”:
We also give a demo video in the attachment, along with PoC. When you reproduce this issue, you should:
1.On the server side, start redis
2.On the server side, run server.py
3.On the client side (attacker), replace the modified service_streamer.py
4.On the client side (attacker), run client.py
Impact
Remote code execution in the victim's machine over network. Once the victim starts the server, an attacker on the network can gain arbitrary code execution by scanning and finding the victim’s service.
Mitigation
(1)Sanitize data before pickle.loads it (e.g., rewrite Unpickler.find_class to set a whitelist), or use more secure deserialization methods such as safetensor or msgpack to replace the insecure pickle.loads.
(2) If the service is intended for internal use only, accept connections/data solely from the internal network. If it must be exposed to the public internet, add authentication.
(3) When starting the service on a public network, print a warning to inform the user.
PoC.zip