Local File Read through Improper Filename Validation in froxlor/froxlor
Reported on
Dec 29th 2022
Description
This vulnerability occur because there is no filename validation on logo_image_login and logo_image_header on import and export function. Attacker can use path traversal payload to leak local file such as /etc/passwd or froxlor config file.
Proof of Concept
- Go to import function on "Settings"
- Modify filename on logo_image_login or logo_image_header with path traversal payload , e.g "../../../../../etc/passwd?v=1672300384"
- After successfully imported, go to "Settings" and go to Export page
- Click Download/Export Settings, then leaked file will be on panel.logo_image_login.image_data key on json file in base64 encoded format
Impact
Attacker can read local file that contains sensitive information such as /etc/passwd or config files.
References
again, still 0.10.x which does not apply to our security policy for huntr.dev / reporting issues
I think when i clone the repo (main branch) , i found that there is SimExporter.php available in library directory
I cloned froxlor with version '2.0.0-beta1' and checked out that admin_settings.php still use SImExporter::import and SImExporter::export . Can you recheck/confirm it?
Of course it uses the same file, but it does not necessarily mean that the issue still exists, there were more than 540 commits since the last 0.10.x version
So if there is no commit regarding this security issue before i submit this vulnerability or there is no commit regarding the changes of import/export function, i can conclude that this one is valid?
Why dont you just clone the repo, install it, and test it?
Yeah , i actually clone the repo (main branch , like i said before) and having an issue while installing it. So i use the latest release (0.10.x) and it successfully installed. After finding a security issue i checked it manually on main branch (2.x and latest commit) and found that the function is used on 2.x , then i report the issue.
I just install the 2.x (2.0.0-beta1 , main branch) and i can confirm that it is vulnerable for local file read and RCE using the same payload like in 0.10.x , like i state on the affected version
Also the proof that you've been patched it after that
@Zen can you verify that the patch fixes the issue?
Is it possible for the maintainer to modify the N/A status to valid? Because i got penalty on it regarding my another finding on froxlor (RCE)