Le mardi 27 juin 2023, 18:46:25 UTC Tobias Frost a écrit : > Hi, > > time for an small update: > > Please note that the packages offered below are WIP status and are intended > for testing only. > > php-cas > ======= > > I've verified my patched version of php-cas against the apereo CAS > implementation and it looks as if it would work :) > > The package is availble from here: > https://people.debian.org/~tobi/php-cas/
Lack a debian new. > > Packaging Repository: https://salsa.debian.org/lts-team/packages/php-cas > > *I recommend using this package to develop patches for software not in Debian > but still affected by the php-cas AOI changes.* > > > fusiondirectory > =============== > > I've backported upstream patches for php-cas with the new API from upstram > and tested them locally (again using the apereo CAS server). > > Packages are available at: > https://people.debian.org/~tobi/fusiondirectory > > Packaging Repository: > https://salsa.debian.org/lts-team/packages/fusiondirectory > > If CAS is enabled in Fusiondirectory, it will *NOT* continue to work without > user > interaction. Please see this NEWS file for details: > https://salsa.debian.org/lts-team/packages/fusiondirectory/-/blob/debian/buster/debian/NEWS Nice with me this part > > Abhijith is working on other CVE to fixed in fusiondirectory, and I will > coordinate > with them accordingly. > > Outlook > ======== > > I will start working on php-cas for ELTS(stretch) and continue working > on fixing the reverse dependnices (LTS and ELTS). > > Once those are ready, to avoid breaking dist-upgrades, I'll > also take a look into bullseye and will coordinate the uploads with the > security team Does Yadd answered ? Bastien > > > Hi, > > > > (Adding yadd as suggested on IRC, solicating yadd's input as well) > > > > Some updates on php-cas: > > > > I've continued to work on php-cas to better assess > > the situation: I've also received information to better > > assess the serverity of the CVE and now I think this issue > > should be fixed. > > (However, I'd like also to hear the opinion of the security team ;-)) > > > > <TL;DR:> > > > > The test suite make me think my patch is working. I'd appreciate other > > people > > testing them too, though. (On my TODO list is to try with an real CAS > > Server) > > > > The reverse dependencies for buster src:fusiondirectory and > > src:ocsinventory-server can be fixed quite easily, by adding > > configuration options and telling the users what to do. > > > > For customers using non-packaged software using php-cas, > > they *will* need to update it: > > The phpCAS client initializer needs an additional $service_base_url > > parameter: > > > > - static function client($server_version, $server_hostname, $server_port, > > $server_uri, $changeSessionID = true) > > + static function client($server_version, $server_hostname, $server_port, > > $server_uri, $service_base_url, $changeSessionID = true) > > > > from upstream uppgrading guide: > > PhpCAS now requires an additional service base URL argument when > > constructing > > the client class, similar to other CAS client's serverName config. It > > accepts > > any argument of: > > > > 1. A service base URL string. The service URL discovery will always use > > this > > server name (protocol, hostname and port number) without using any > > external > > host names. > > 2. An array of service base URL strings. The service URL discovery will > > check > > against this list before using the auto discovered base URL. If there > > is no > > match, the first base URL in the array will be used as the default. This > > option is helpful if your PHP website is accessible through multiple > > domains > > without a canonical name, or through both HTTP and HTTPS. > > 3. A class that implements CAS_ServiceBaseUrl_Interface. If you need to > > customize the base URL discovery behavior, you can pass in a class that > > implements the interface. > > > > </TL;DR> > > > > > > > > My more detailed notes: > > > > Upstream Test suite: > > #################### > > > > The test suite for 1.3.6 is not packaged in the debian package, > > but I made a branch including it: > > https://salsa.debian.org/lts-team/packages/php-cas/-/tree/debian/buster-with-testsuite > > > > The test suite is patched as required for CVE-2022-29369, as the CAS_Client > > class > > needs an additional "service" parameter (this is the API breakage) > > > > Before the patch for the CVE: > > $ phpunit TestSuite.php > > OK, but incomplete, skipped, or risky tests! > > Tests: 79, Assertions: 412, Incomplete: 4, Risky: 2. > > > > After patch for the CVE: (The patch adds some tests.) > > $ phpunit TestSuite.php > > OK, but incomplete, skipped, or risky tests! > > Tests: 92, Assertions: 425, Incomplete: 4, Risky: 2. > > > > (When removing the additional tests (file: > > test/CAS/Tests/ServiceBaseUrlTest.php): > > $ phpunit TestSuite.php > > OK, but incomplete, skipped, or risky tests! > > Tests: 79, Assertions: 412, Incomplete: 4, Risky: 2.) > > > > > > Reverse Dependencies for buster: > > ################################ > > > > php-cas > > Reverse Depends: fusiondirectory (1.0.19-1+deb9u1) > > Reverse Depends: ocsinventory-reports (2.5+dfsg1-1) > > > > fusiondirectory > > --------------- > > > > - Use of php-cas is optional, (get_cfg_value('casActivated')) > > - Uses php-cas in core/html/index.php, likely only change required > > is to add the new $service_base_url parameter after > > core/html/index.php:128 > > (upstream has refactored in the meantime, upstream has change at [a], > > but > > it seems that we don't have the CasClientServiceName config entry in > > buster, > > probably can be backported.) > > - Possibly users will need to run fusiondirectory-insert-schema and > > possibly > > reconfigure fusiondirectory and possibly a Debian.NEWS should tell > > them so. > > (needs to be evaluated once I have patches) > > > > ocsinventory-reports > > -------------------- > > ( yadd is Maintainer of this package and probably can better comment > > on it) > > - Use of php-cas is optional, ($affich_method == 'CAS') > > - not default > > - seems that /usr/share/ocsinventory-reports/backend/AUTH/auth.php > > needs to be > > edited to make it work. (which is not a conffile.) > > - 3 locations initializes php-cas and will needs updating with > > $service_base_url > > ocsreports/backend/AUTH/methode/cas.php:$cas = new phpCas(); > > ocsreports/update.php: $cas = new phpCas(); > > ocsreports/require/header.php: $cas = new phpCas(); > > - As the auth method is not a conffile, every update will reset user > > configuration, > > defaulting back to HTML-Form authenticication. > > - Cas confiuration is done in > > /usr/share/ocsinventory-reports/backend/require/cas.config.php: > > This is a central point where $service_base_url can be configured > > (it also not a conffile…) > > (- ocsinventory-server is on limited security support, reason given: > > Details: Only supported behind an authenticated HTTP zone) > > > > > > > > [a] > > https://github.com/fusiondirectory/fusiondirectory/blob/919b407cdf5c409b20c500e6eadecf0c62270aac/include/login/class_LoginCAS.inc#L48C16-L48C16 > > > > On Tue, Jun 20, 2023 at 04:14:42PM +0200, Tobias Frost wrote: > > > (As suggested, I'm moving the discussion to debian-lts@lists.debian.org, > > > CC'ing > > > the security team) > > > > > > > On 19/06/2023 18:17, Tobias Frost wrote: > > > > > Hey, > > > > > > > > > > As I am currently preparing a fix for php-cas to tackle > > > > > CVE-2022-39369 [1], and > > > > > as the changes required are breaking changes, I'd like to discuss > > > > > whether the > > > > > vulnerability justifies a breaking change, or if the issue should be > > > > > ignored instead. > > > > > (Maybe feedback from interested customers can be collected, so that > > > > > they can assess > > > > > the impact on their side already.) > > > > > > > > > > I've packaged my backport of the patch and uploaded it to [3] as an > > > > > (untested) preview. > > > > > > > > > > The breaking change: users of php-cas needs to perform additional > > > > > steps when > > > > > using the php module, as described in docs/updating of the upstream > > > > > pull > > > > > request fixing the issue: [2] > > > > > > > > > > phpCAS now requires an additional service base URL argument when > > > > > constructing the client class, similar to other CAS client's > > > > > serverName config. > > > > > > > > > > Upstream asses the situation as [4] > > > > > > > > > > This vulnerability may allow an attacker to gain access to a > > > > > victim's account > > > > > on a vulnerable CASified service without victim's knowledge, > > > > > when the victim > > > > > visits attacker's website while being logged in to the same CAS > > > > > server. > > > > > > > > > > > > > > The patch applied to the package is this commit: > > > https://salsa.debian.org/lts-team/packages/php-cas/-/commit/2c2b5f73da55f5c6d9f69e1ac11b3a1ee565d435 > > > (also debdiff attached.) > > > > > > > > > >
signature.asc
Description: This is a digitally signed message part.
