As per bug 35970, security experts advise that you shouldn't publicly publish the version number of your software. Currently, in the "<meta name="generator"> tag, we publish "Koha XX.YY". We should just show "Koha".
Note that this is an incomplete fix overall, but I hope that it gets us moving on this one.
NOTE: Apparently in the staff interface we only show the generator metadata to logged in users: [% IF logged_in_user %]<meta name="generator" content="Koha [% Koha.Version.maintenance | html %]" />[% END %] Since we show it on the about.pl page and at the bottom of the staff interface pages, that seems all right to me. In theory, we probably shouldn't show it at all, but at least it's not publicly visible.
(In reply to David Cook from comment #2) > NOTE: Apparently in the staff interface we only show the generator metadata > to logged in users: > > [% IF logged_in_user %]<meta name="generator" content="Koha [% > Koha.Version.maintenance | html %]" />[% END %] > > Since we show it on the about.pl page and at the bottom of the staff > interface pages, that seems all right to me. > > In theory, we probably shouldn't show it at all, but at least it's not > publicly visible. Of course, the version is still shown on the public staff interface via the JS/CSS files, but I figure we can use bug 35970 more for that.
Created attachment 170689 [details] [review] Bug 37724: Remove Koha version number from OPAC This change removes the Koha version number from the OPAC generator metadata. Test plan: 0. Apply patch 1. Enable syspref SelfCheckInModule 2. Visit /cgi-bin/koha/opac-main.pl and confirm meta tag doesn't include version number 3. Visit /cgi-bin/koha/sci/sci-main.pl and confirm meta tag doesn't include version number 4. Visit /cgi-bin/koha/sco/sco-main.pl) and confirm meta tag doesn't include version number 5. Click "Help" and confirm meta tag doesn't include version number
Created attachment 172374 [details] [review] Bug 37724: Remove Koha version number from OPAC This change removes the Koha version number from the OPAC generator metadata. Test plan: 0. Apply patch 1. Enable syspref SelfCheckInModule 2. Visit /cgi-bin/koha/opac-main.pl and confirm meta tag doesn't include version number 3. Visit /cgi-bin/koha/sci/sci-main.pl and confirm meta tag doesn't include version number 4. Visit /cgi-bin/koha/sco/sco-main.pl) and confirm meta tag doesn't include version number 5. Click "Help" and confirm meta tag doesn't include version number Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
It works! :)
In bug 35970 there is question of: > What about hiding the last digits to not show the full version? > Safer to say that you are on 22.11 than 22.11.xxx? > Might be the difference between fully patched or not.. [...] > reducing down to feature release versions only isn't a bad compromise So that question comes back to here. Fingerprinting major version from the HTML/CSS/JS content will always be feasible but at least it's a bit tedious. So there is that gain vs the value of the convenience of looking at a Koha instance and knowing it's version.
There is absolutely no gain IMO, it's security by obscurantism. It takes 5 main to write a script with the version-md5 mapping.
There is absolutely no gain IMO, it's security by obscurantism. It takes 5 main to write a script to get the version-md5 mapping for all versions of Koha.
(In reply to Jonathan Druart from comment #9) > There is absolutely no gain IMO, it's security by obscurantism. > It takes 5 main to write a script to get the version-md5 mapping for all > versions of Koha. If there is no gain for security reasons why not leave the version for convenience reasons?
(In reply to Lucas Gass from comment #10) > (In reply to Jonathan Druart from comment #9) > > There is absolutely no gain IMO, it's security by obscurantism. > > It takes 5 main to write a script to get the version-md5 mapping for all > > versions of Koha. > > If there is no gain for security reasons why not leave the version for > convenience reasons? If we can't come to a conclusion here, maybe it needs to be made configurable. I have also been asked by our IT security person to remove this information from source code. Currently it makes it very easy to check for open CVE reports. This can lead to wrong or false warnings, especially since we lack a good workflow for handling CVE right now indicating the versions a bug has been fixed in.
Perhaps it is possible to generate a 10 character random string where the seed is the version number.. that string will be unique but cannot be back-tracked..
(In reply to Jonathan Druart from comment #9) > There is absolutely no gain IMO, it's security by obscurantism. > It takes 5 main to write a script to get the version-md5 mapping for all > versions of Koha. (In reply to Katrin Fischer from comment #11) > If we can't come to a conclusion here, maybe it needs to be made > configurable. I have also been asked by our IT security person to remove > this information from source code. > > Currently it makes it very easy to check for open CVE reports. This can lead > to wrong or false warnings, especially since we lack a good workflow for > handling CVE right now indicating the versions a bug has been fixed in. While the security aspect is debateable, removing the version is a frequent request from IT security personnel. So I think having an option to remove it/replace it would be great.
(In reply to Ola Andersson from comment #12) > Perhaps it is possible to generate a 10 character random string where the > seed is the version number.. that string will be unique but cannot be > back-tracked.. Depends on what you mean. If the version is the seed but a new random string is generated on each load, then there's no point, because we'll cache bust too much. We'll want the non-identifiable string to tie to the version, so that a new version yields a new non-identifiable string, so that the browser cache is busted and new static files are downloaded.
Oops thought I was commenting on bug 35970
I thought that too, please disregard my previous comment
(In reply to David Cook from comment #13) > (In reply to Jonathan Druart from comment #9) > > There is absolutely no gain IMO, it's security by obscurantism. > > It takes 5 main to write a script to get the version-md5 mapping for all > > versions of Koha. > > While the security aspect is debateable, removing the version is a frequent > request from IT security personnel. > > So I think having an option to remove it/replace it would be great. Even if this is security by obscurity, it still has some value to raise the bar against not very dedicated attackers. It's defense in depth. By adding one hurdle of having to unreliably (later on that) probe the version. If something easy raises the attack cost, let's go for it. Even for moderately dedicated attackers, it adds not being sure that an exploit doesn't work because it's wrongly executed or because the minor version is recent and patched. «The other benefit is that the version number will not be indexed by services like Shodan. This can be relevant where an automated attack is carried out for all instances of a particular version of a service (eg. where a 0-day has been discovered for that version). Hiding this from the banner, may actually prevent a given instance of the service from falling prey to that attack.» https://security.stackexchange.com/questions/2430/the-valid-role-of-obscurity Also, there are not systematically changes to public pages to be able to map down to all minor versions. Especially for oldoldstable and the LTS part of a cycle. --- What is the actual convenience reason? I feel like that I strongly want to be able to know the version when coming across an instance in the wild but not really for a useful reason ^^" I someone really wants to have the opt in major version, that could be another ticket though. Assuming 1st there is a not too hard solution found for bug 35970, otherwise there is no need to bother.
Created attachment 173872 [details] [review] Bug 37724: Remove Koha version number from OPAC This change removes the Koha version number from the OPAC generator metadata. Test plan: 0. Apply patch 1. Enable syspref SelfCheckInModule 2. Visit /cgi-bin/koha/opac-main.pl and confirm meta tag doesn't include version number 3. Visit /cgi-bin/koha/sci/sci-main.pl and confirm meta tag doesn't include version number 4. Visit /cgi-bin/koha/sco/sco-main.pl) and confirm meta tag doesn't include version number 5. Click "Help" and confirm meta tag doesn't include version number Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Applied to 23.05.x-security
Applied to 23.11.x-security for v23.11.10
I do agree that showing off the major version by default with the option to disable it would be a reasonable compromise. The major version is much easier to figure out by the assets and not having it there is sad for e.g. analytical purposes, it's really interesting to see what versions of Koha are deployed throughout the country, how actively do they follow the community updates etc. There is some merit to hiding it completely like mentioned around the Shodan scan, but I think if someone develops an exploit and tests privately that it works, they'll be more likely to just enlist all Koha instances out there in the wild and just attempt all anyway, it's not like there's that many of them either. At most I feel like they'd exclude the new ones rather than excluding the unknown ones. With that said, hiding only the minor version would at least definitely hide whether it's a security-patched version already or not yet there, so this might be a sensible default. If the default remains all hidden, community-maintained pages like this will lose a lot of their merit: https://pl.wiki.bibliotekaaik.pl/view/Koha