Resource Consumption DOS on Edgemax v1.10.6

Resource consumption Denial of service. This was reported last year and has been fixed as of version 2.0.3 . It has been assigned CVE-2019-16889.

1: The request below shows that when you feed the cookie variable a payload of 250 characters or more, the web management portal will produce an error page showing full path disclosure and more as shown in screenshots error1.png and error2.png.

GET / HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1

Cache-Control: max-age=0



2: When providing a valid length payload of 249 characters or less it will be stored as a *.cache filename in the /var/run/beaker/container_file/ directory,this can easily be turned in to a denial of service by filling up the space of the device with unique requests. The web portal will display either a 500 error as shown here


or a python error screen as shown here.



Typically the web portal will stop functioning after the /run mount has reached 50% by sending requests using iterations of 1-15681 as a variable, however any length of payload can be used up to 249 characters. This can be recovered from by deleting all files within the /var/run/beaker/container_file/ directory.

Although once the /run mount can not accept any more files /var/log will start to fill up with complaints about not being able to write to /var/run/beaker/container_file/, then after /var/log fills up the device will stop responding all together until it has been power cycled.

3: This process can take upwards of 20 minutes, so it is a slow denial of service.


Any resources served by the edgemax device will be unavailable until the physical device has it’s power cycled, then it should function as normal. However it would be easy to just perform the attack again after it has been brought back online.