Package: release.debian.org Severity: normal Tags: buster User: release.debian....@packages.debian.org Usertags: pu X-Debbugs-Cc: jvalle...@mailbox.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 [ Reason ] A security issue was found and reported to the security team: https://security-tracker.debian.org/tracker/TEMP-0000000-3E4AC3 Since the impact is limited to specific use cases, they did not issue a DSA. A CVE has been requested but it still pending. Description: After entering the first run wizard secret, other web-sessions can continue the first run wizard without being asked for the first run wizard secret. [ Impact ] Users performing initial setup of FreedomBox on untrusted networks are impacted. The vulnerability can be exploited by an adversary without any tool or code. In a typical home server setup, an adversary in the home network, during the initial setup of FreedomBox (at the right time), can create an administrator account for themselves and gain full access. In case of FreedomBox cloud instances (unusual), an adversary can remotely exploit the vulnerability from public internet. [ Tests ] I manually tested by creating a fresh VM with buster from Debian installer. I installed freedombox_19.1+deb10u2_all.deb and accessed the web interface. I was prompted to type in a secret from /var/lib/plinth/firstboot-wizard-secret, which I did. This brought me to the initial user creation form. I then opened a private browsing window and accessed the web interface. I confirmed that I was prompted for the secret again, and could not create a user account without entering the secret. The issue was also fixed in freedombox 21.4.2, currently in unstable. Additional tests performed for this fix in unstable: https://salsa.debian.org/freedombox-team/freedombox/-/issues/2074#note_233860 [ Risks ] The code is fairly simple, makes use of Django session data, and one step added to a middleware, which checks several conditions. [ Checklist ] [X] *all* changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in stable [X] the issue is verified as fixed in unstable [ Changes ] When the secret is entered, the key 'firstboot_secret_provided' is set in the Django session (server-side). Then in the firstboot middleware, if the requested page is later in the firstboot process, it checks if the session variable is set, or if the user is an administrator (meaning the initial user has already been created). If neither is the case, the request is redirected back to the welcome page, which requires the secret to be entered before proceeding. -----BEGIN PGP SIGNATURE----- iQJKBAEBCgA0FiEEfWrbdQ+RCFWJSEvmd8DHXntlCAgFAmBlJr8WHGp2YWxsZXJv eUBtYWlsYm94Lm9yZwAKCRB3wMdee2UICE9XEACyjRu2Lx2Ee6ixxWUxYhibX8Dr CIIyIlR15JPGF9y9wLnj8SSuGXY2yDTGL5xe0YTMa4U9M+UED62lyoEzB3+Qj0uo jmdYBCwZtgsPskD7APalV1sQxNCjRjdq9EsZNsWxEUyxH6I/1IUTgBIC3hwCWHgg IEipqV/XwSTViMDhjccopvBjv2OMhjpVptzNGTara4uQwoB971/YmpalXAi/+dHr 1dx6gVuAx7bKxRwC4qDhJmGJx9DQRpUBjKR3Z1DBqvhfTn02lID5+rynysOo/7F5 8p+M25PfKzRzSWp6UZuYjXnWdYeB6Szvw8S6WGNqX53NMGPt3h34iiyjRv3PQjmR P/fAeMBZVREpEd+c47j7DLoGdcet/xfj8LSdtB06xbp7+bfP0KeqMG1wemaiyACc 9cFuIdsWjIp/L1igzPxSdYMEaYyk2eC8Fc0etMhe7WtWNIZQ2upILpHf0arKvG/M eOBIeNwdcLdN9MWTfHfK1csl6eTG2bVWL25GjXcHGR2Mt9yyXYIAAnkJJdMMrX7f P7X0MFMISR5MjDIqgH1TLqmsk00W9oSzjjqlTPirhkze4Mq4ymkSfpT5jsz186Dx 3nuX/Z96Yuft3HTjc4KqO8LXk94gJfc9kb1kU4woxfkYEIDys7vPCh6sQfcN4iav z9qnrpIt/LKEFlOitw== =iEkv -----END PGP SIGNATURE-----
diff -Nru plinth-19.1+deb10u1/debian/changelog plinth-19.1+deb10u2/debian/changelog --- plinth-19.1+deb10u1/debian/changelog 2020-09-21 21:40:22.000000000 -0400 +++ plinth-19.1+deb10u2/debian/changelog 2021-03-30 21:43:08.000000000 -0400 @@ -1,3 +1,10 @@ +plinth (19.1+deb10u2) buster; urgency=medium + + [ Kirill Schmidt ] + * first_boot: Use session to verify first boot welcome step + + -- James Valleroy <jvalle...@mailbox.org> Tue, 30 Mar 2021 21:43:08 -0400 + plinth (19.1+deb10u1) buster; urgency=medium * apache: Disable mod_status (CVE-2020-25073) diff -Nru plinth-19.1+deb10u1/plinth/modules/first_boot/middleware.py plinth-19.1+deb10u2/plinth/modules/first_boot/middleware.py --- plinth-19.1+deb10u1/plinth/modules/first_boot/middleware.py 2020-09-21 21:40:22.000000000 -0400 +++ plinth-19.1+deb10u2/plinth/modules/first_boot/middleware.py 2021-03-30 21:43:08.000000000 -0400 @@ -28,6 +28,7 @@ from django.utils.deprecation import MiddlewareMixin from plinth.modules import first_boot +from plinth.utils import is_user_admin LOGGER = logging.getLogger(__name__) @@ -52,6 +53,15 @@ firstboot_completed = first_boot.is_completed() user_requests_firstboot = first_boot.is_firstboot_url(request.path) + # If user requests a step other than the welcome step, verify that they + # indeed completed the secret verification by looking at the session. + if (user_requests_firstboot and + not request.path.startswith(reverse('first_boot:welcome')) and + first_boot.firstboot_wizard_secret_exists() and + not request.session.get('firstboot_secret_provided', False) and + not is_user_admin(request)): + return HttpResponseRedirect(reverse('first_boot:welcome')) + # Redirect to first boot if requesting normal page and first # boot is not complete. if not firstboot_completed and not user_requests_firstboot: diff -Nru plinth-19.1+deb10u1/plinth/modules/first_boot/views.py plinth-19.1+deb10u2/plinth/modules/first_boot/views.py --- plinth-19.1+deb10u1/plinth/modules/first_boot/views.py 2020-09-21 21:40:22.000000000 -0400 +++ plinth-19.1+deb10u2/plinth/modules/first_boot/views.py 2021-03-30 21:43:08.000000000 -0400 @@ -34,6 +34,7 @@ def form_valid(self, form): """If form is valid, mark this step as done and move to next step.""" + self.request.session['firstboot_secret_provided'] = True first_boot.mark_step_done('firstboot_welcome') return http.HttpResponseRedirect(reverse(first_boot.next_step()))