Basic Info

If you found a Local File Inclusion even if you don't have a session and session.auto_start is Off. If session.upload_progress.enabled is On and you provide the PHP_SESSION_UPLOAD_PROGRESS in multipart POST data, PHP will enable the session for you.
$ curl -H 'Cookie: PHPSESSID=iamorange'
$ ls -a /var/lib/php/sessions/
. ..
$ curl -H 'Cookie: PHPSESSID=iamorange' -d 'PHP_SESSION_UPLOAD_PROGRESS=blahblahblah'
$ ls -a /var/lib/php/sessions/
. ..
$ curl -H 'Cookie: PHPSESSID=iamorange' -F 'PHP_SESSION_UPLOAD_PROGRESS=blahblahblah' -F 'file=@/etc/passwd'
$ ls -a /var/lib/php/sessions/
. .. sess_iamorange
In the last example the session will contain the string blahblahblah
Note that with PHP_SESSION_UPLOAD_PROGRESS you can control data inside the session, so if you includes your session file you can include a part you control (a php shellcode for example).
Although most tutorials on the Internet recommends you to set session.upload_progress.cleanup to Off for debugging purpose. The default session.upload_progress.cleanup in PHP is still On. It means your upload progress in the session will be cleaned as soon as possible. So this will be Race Condition.


In the original CTF where this technique is commented, it wasn't enough to exploit the Race Condition but the content loaded needed to start also with the string @<?php.
Due to the default setting of session.upload_progress.prefix, our SESSION file will start with a annoying prefix upload_progress_ Such as: upload_progress_controlledcontentbyattacker
The trick to remove the initial prefix was to base64encode the payload 3 times and then decode it via convert.base64-decode filters, this is because when base64 decoding PHP will remove the weird characters, so after 3 times only the payload sent by the attacker will remain (and then the attacker can control the initial part).