Bug 13886 (CVE-2025-34311)

Summary: /cgi-bin/logs.cgi/calamaris.dat Multiple Parameters Command Injection
Product: IPFire Reporter: Wade Sparks <wsparks>
Component: ---Assignee: Adolf Belka <adolf.belka>
Status: MODIFIED --- QA Contact:
Severity: Security    
Priority: Will affect all users CC: adolf.belka, arne.fitzenreiter, michael.tremer, nobody, stefan.schantl
Version: 2Keywords: Security
Hardware: x86_64   
OS: Unspecified   
Bug Depends on: 13885    
Bug Blocks: 13887    
Attachments: Researcher Report

Description Wade Sparks 2025-09-23 22:53:58 UTC
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.
Comment 2 Michael Tremer 2025-09-25 15:47:08 UTC
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.
Comment 3 Wade Sparks 2025-10-14 17:29:03 UTC
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.
Comment 4 Michael Tremer 2025-10-27 15:25:58 UTC
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
Comment 5 Michael Tremer 2025-10-27 16:33:37 UTC
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