Bug#986224: buster-pu: package plinth/19.1+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian.org@packages.debian.org
Usertags: pu
X-Debbugs-Cc: jvalleroy@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 <jvalleroy@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()))
Reply to: