Created attachment 1673 [details] Researcher Report +++ This bug was initially created as a clone of Bug #13885 +++ I am a vulnerability analyst at VulnCheck responsible for managing our coordinated vulnerability disclosure (CVD) process. A researcher reported this vulnerability affecting IPFire, and VulnCheck is acting as the intermediary and coordinator. We have tentatively reserved CVE-2025-34217, which have been shared with the researcher but will remain private until public disclosure: Please be aware that none of this information is public at this moment and all participants are considered under embargo. VulnCheck follows a 120-day disclosure policy, meaning we allow vendors/maintainers up to 120 days from the time of receiving the report to address the issues before publishing our advisory. For this vulnerability, that 120-day deadline falls on January 21, 2025. --- When a user creates a Proxy report, an HTTP POST request is sent to the Request-URI "/cgi-bin/logs.cgi/calamaris.dat". When this request is received, the values of the parameters DAY_BEGIN, MONTH_BEGIN, YEAR_BEGIN, DAY_END, MONTH_END, YEAR_END, NUM_DOMAINS, PERF_INTERVAL, NUM_CONTENT, HIST_LEVEL, NUM_HOSTS, NUM_URLS, and BYTE_UNIT are read and used in the following command (some parameters are optional, this is assuming all of the options are selected): /var/ipfire/proxy/calamaris/bin/mkreport <DAY_BEGIN> <MONTH_BEGIN> <YEAR_BEGIN> <DAY_END> <MONTH_END> <YEAR_END> -d <NUM_DOMAINS> -P <PERF_INTERVAL> -t <NUM_CONTENT> -D <HIST_LEVEL> -r <NUM_HOSTS> -R <NUM_URLS> -U <BYTE_UNIT> where <DAY_BEGIN>, <MONTH_BEGIN>, <YEAR_BEGIN>, <DAY_END>, <MONTH_END>, <YEAR_END>, <NUM_DOMAINS>, <PERF_INTERVAL>, <NUM_CONTENT>, <HIST_LEVEL>, <NUM_HOSTS>, <NUM_URLS>, and <BYTE_UNIT> are equal to the values of the parameters DAY_BEGIN, MONTH_BEGIN, YEAR_BEGIN, DAY_END, MONTH_END, YEAR_END, NUM_DOMAINS, PERF_INTERVAL, NUM_CONTENT, HIST_LEVEL, NUM_HOSTS, NUM_URLS, and BYTE_UNIT, respectively. The values of the parameters DAY_BEGIN, MONTH_BEGIN, YEAR_BEGIN, DAY_END, MONTH_END, YEAR_END, NUM_DOMAINS, PERF_INTERVAL, NUM_CONTENT, HIST_LEVEL, NUM_HOSTS, NUM_URLS, and BYTE_UNIT are never sanitized for command injection-related characters. This can result in remote code execution in the context of the user nobody. --- The attachment contains additional technical details, the affected pathway, and proof of concept.
Patch set submitted https://lists.ipfire.org/development/20250925111252.11893-1-adolf.belka@ipfire.org/T/#t https://patchwork.ipfire.org/project/ipfire/list/?series=5215
Thank you very much everyone who has been working on this. The IPFire team has carefully reviewed this and the other reports and we have submitted a number of patches for you to review. They are all linked above. They have also already been merged to the development tree and therefore in line to be released with the next update: > https://git.ipfire.org/?p=ipfire-2.x.git;a=shortlog;h=refs/heads/next Please review the patches and confirm if they are fixing all problems that have been reported. We are very grateful for your time and effort that you have brought towards these findings and for your contribution to make IPFire an even more secure firewall. Please feel free to report any future findings and if you have anything else to share with us, please contact security@ipfire.org. I have made this bug report public again since patches are now available.
In reviewing the fixes, the researcher noticed a discrepancy with the patch he recommended and the patch that was added. - The added patch would cause the request to always die early as before the patch, the string "< /dev/null > /dev/null 2>&1" and potentially " &" are added to the end of the value of the commandline string. This would then cause the new if check in the patch to always be true and the request would die. The patch should probably be moved to be before the "< /dev/null > /dev/null 2>&1" string concatenation to prevent this. Please let us know your thoughts on this observation.
Good catch! I fixed this problem by moving the check as suggested: > https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=5fff4e12e51746d65e5ee3621e0a81d471910265
The CVE numbers in the individual reports have been mixed up with some other projects. Here is an updated list: #13876 - CVE-2025-34301 #13877 - CVE-2025-34302 #13878 - CVE-2025-34303 #13879 - CVE-2025-34304 #13880 - CVE-2025-34305 #13881 - CVE-2025-34306 #13882 - CVE-2025-34307 #13883 - CVE-2025-34308 #13884 - CVE-2025-34309 #13885 - CVE-2025-34310 #13886 - CVE-2025-34311 #13887 - CVE-2025-34312 #13888 - CVE-2025-34313 #13889 - CVE-2025-34314 #13890 - CVE-2025-34315 #13891 - CVE-2025-34316 #13892 - CVE-2025-34317 #13893 - CVE-2025-34318