Race condition in ‘copy-account-skeletons’: possible privilege escalation.

OpenSubmitted by Maxime Devos.
Details
2 participants
  • Ludovic Courtès
  • Maxime Devos
Owner
unassigned
Severity
important
M
M
Maxime Devos wrote on 3 Apr 18:09 +0200
(address . bug-guix@gnu.org)
1a6ed722dfdd96dc8d53f939aa8e440ca7c29213.camel@telenet.be
A TOCTTOU (time-of-check to time-of-use) vulnerability has been foundin the activation code of user accounts, more specifically in thecode that copies the account skeletons.
* Vulnerability
The attack consists of the user being logged in after the accountskeletons have been copied to the home directory, but before theowner of the account skeletons have been set. The user then deletesa copied account skeleton (e.g. @file{$HOME/.gdbinit}) and replacesit with a symbolic link to a file not owned by the user, such as@file{/etc/shadow}.
The activation code then changes the ownershipof the file the symbolic link points to instead of the symboliclink itself. At that point, the user has read-write accessto the target file.
* Where in the code does this happen?
Module: (gnu build activation).Procedures: 'copy-account-skeletons' and 'activate-user-home'.
'copy-account-skeletons' creates the home directory, sets itowner, copies the account skeletons, and chowns the copied skeletons,in that order. The bug is that it dereferences symbolic links.
It is called from 'activate-user-home' if the home directory doesnot already exist.
* Fix
The fix consist of initially creating the home directory root-owned and onlychanging the owner of the home directory once all skeletons have been copiedand their owner has been set.
* Extra notes
A blog post, a news entry and a fix have been prepared and will be postedand hopefully merged soon. The following tests succeeded:
$ make check-system TESTS='switch-to-system upgrade-services install-bootloader basic'$ make check
-----BEGIN PGP SIGNATURE-----
iI0EABYIADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYGiTLBccbWF4aW1lZGV2b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7sOVAQDo/Y4CM3KbVCPqLFr/YOjdA6T2tOoO8lB90ciLuXdB+AEAtWcTB6Y5+G8r2Dbp6bl2HnFHILDSNQns1H/c80B67A0==xuhu-----END PGP SIGNATURE-----

M
M
Maxime Devos wrote on 3 Apr 18:22 +0200
(address . 47584@debbugs.gnu.org)
63fbd9e37cc3582daf265277e64f0a99b20e05ec.camel@telenet.be
Patch is attached.The committer will need to change the commit id appropriately.
From 9672bd37bf50db1e0989d0b84035c4788422bd31 Mon Sep 17 00:00:00 2001From: Maxime Devos <maximedevos@telenet.be>Date: Tue, 30 Mar 2021 22:36:14 +0200Subject: [PATCH 1/2] activation: Do not dereference symlinks in home directory creation.MIME-Version: 1.0Content-Type: text/plain; charset=UTF-8Content-Transfer-Encoding: 8bit
Fixes https://bugs.gnu.org/47584.
* gnu/build/activation.scm (copy-account-skeletons): Do not chown the home directory; leave this to 'activate-user-home'. (activate-user-home): Only chown the home directory after the account skeletons have been copied.
Co-authored-by: Ludovic Courtès <ludo@gnu.org>.--- gnu/build/activation.scm | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
Toggle diff (41 lines)diff --git a/gnu/build/activation.scm b/gnu/build/activation.scmindex 6cb6f8819b..43d973d3da 100644--- a/gnu/build/activation.scm+++ b/gnu/build/activation.scm@@ -107,7 +107,8 @@ Warning: this is currently suspect to a TOCTTOU race!" (directory %skeleton-directory) uid gid) "Copy the account skeletons from DIRECTORY to HOME. When UID is an integer,-make it the owner of all the files created; likewise for GID."+make it the owner of all the files created except the home directory; likewise+for GID." (define (set-owner file) (when (or uid gid) (chown file (or uid -1) (or gid -1))))@@ -115,7 +116,6 @@ make it the owner of all the files created; likewise for GID." (let ((files (scandir directory (negate dot-or-dot-dot?) string<?))) (mkdir-p home)- (set-owner home) (for-each (lambda (file) (let ((target (string-append home "/" file))) (copy-recursively (string-append directory "/" file)@@ -215,10 +215,14 @@ they already exist." (uid (passwd:uid pw)) (gid (passwd:gid pw))) (mkdir-p home)- (chown home uid gid) (chmod home #o700) (copy-account-skeletons home- #:uid uid #:gid gid))))))+ #:uid uid #:gid gid)+ ;; It is important 'chown' is called after 'copy-account-skeletons'+ ;; Otherwise, a malicious user with good timing could+ ;; create a symlink in HOME that would be dereferenced by+ ;; 'copy-account-skeletons'.+ (chown home uid gid)))))) (for-each ensure-user-home users)) -- 2.31.1
From d071ee3aff5be1a6d7876d7411e70f7283dce1fb Mon Sep 17 00:00:00 2001From: Maxime Devos <maximedevos@telenet.be>Date: Sat, 3 Apr 2021 12:19:10 +0200Subject: [PATCH 2/2] news: Add entry for user account activation vulnerability.
TODO for guix committer: correct the commit id appropriately.
* etc/news.scm: Add entry.--- etc/news.scm | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
Toggle diff (37 lines)diff --git a/etc/news.scm b/etc/news.scmindex deedc69f6e..0cc9c183a0 100644--- a/etc/news.scm+++ b/etc/news.scm@@ -12,6 +12,7 @@ ;; Copyright © 2020, 2021 Maxim Cournoyer <maxim.cournoyer@gmail.com> ;; Copyright © 2021 Leo Famulari <leo@famulari.name> ;; Copyright © 2021 Zhu Zihao <all_but_last@163.com>+;; Copyright © 2021 Maxime Devos <maximedevos@telenet.be> ;; ;; Copying and distribution of this file, with or without modification, are ;; permitted in any medium without royalty provided the copyright notice and@@ -20,6 +21,22 @@ (channel-news (version 0) + ;; XXX to guix committers: this commit likely needs to be changed.+ (entry (commit "9672bd37bf50db1e0989d0b84035c4788422bd31")+ (title+ (en "Risk of local privilege escalation by creation of new user accounts"))+ (body+ (en "A security vulnerability that can lead to local privilege+escalation has been found in the activation code of user accounts. The+system is only vulnerable during the activation of user accounts (including+system accounts) that do not already exist.++The attack consists of the user logging in after the user's home directory+has been created, but before the activation of the user has been completed,+by creating an appropriately named symbolic link in the home directory+pointing to a sensitive file, such as @file{/etc/shadow}.++See @uref{https://issues.guix.gnu.org/47584} for more information on this bug."))) (entry (commit "9ade2b720af91acecf76278b4d9b99ace406781e") (title (en "Update on previous @command{guix-daemon} local privilege escalation")-- 2.31.1
-----BEGIN PGP SIGNATURE-----
iI0EABYIADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYGiWNBccbWF4aW1lZGV2b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7q/qAQDT5qc+LRzX3U7kyva91ZSwtcAbQiyWn0hoKcCM7ADQLwEAttCr+4GQJnhmgUGMN3dBqaJLg6XXwxcOGFg03XJxhAU==Y7kQ-----END PGP SIGNATURE-----

M
M
Maxime Devos wrote on 3 Apr 18:26 +0200
(address . 47584@debbugs.gnu.org)
9c0c5f5906e45e83ecae84ae8858ddaf4ea78569.camel@telenet.be
A suggested blog post is attached.
From 7937b9f18085569e5d7cb8a3c4dc08e1088a94a9 Mon Sep 17 00:00:00 2001From: Maxime Devos <maximedevos@telenet.be>Date: Sat, 3 Apr 2021 18:02:05 +0200Subject: [PATCH] =?UTF-8?q?website:=20Add=20post=20about=20vulnerability?= =?UTF-8?q?=20in=20=E2=80=98copy-account-skeletons=E2=80=99.?=MIME-Version: 1.0Content-Type: text/plain; charset=UTF-8Content-Transfer-Encoding: 8bit
* website/posts/home-symlink.md: New post.--- website/posts/home-symlink.md | 103 ++++++++++++++++++++++++++++++++++ 1 file changed, 103 insertions(+) create mode 100644 website/posts/home-symlink.md
Toggle diff (111 lines)diff --git a/website/posts/home-symlink.md b/website/posts/home-symlink.mdnew file mode 100644index 0000000..9289870--- /dev/null+++ b/website/posts/home-symlink.md@@ -0,0 +1,103 @@+title: Risk of local privilege escalation in account creation+date: 2021-04-03 17:30+author: Maxime Devos+tags: Security Advisory+---++A security vulnerability that can lead to local privilege escalation+has been found in the activation code of user accounts (excluding+system accounts). It does not affect users on foreign distros+and is only exploitable during system reconfiguration.++This exploit is _not_ impossible on machines where the Linux [protected+symlinks](https://sysctl-explorer.net/fs/protected_symlinks/) feature+is enabled. It is believed the attack can also be performed using hard+links.++# Vulnerability++The attack consists of the user being logged in after the account+skeletons have been copied to the home directory, but before the+owner of the account skeletons have been set. The user then deletes+a copied account skeleton (e.g. `$HOME/.gdbinit`) and replaces+it with a symbolic link to a file not owned by the user, such as+`/etc/shadow`.++The activation code then changes the ownership of the file the symbolic+link points to instead of the symbolic link itself. At that point, the+user has read-write access to the target file.++# Fix++This [bug](https://issues.guix.gnu.org/47584) has been+<!-- XXX insert the commit id -->+[fixed](https://git.savannah.gnu.org/cgit/guix.git/commit/?id= XXX).+See below for upgrade instructions.++The fix consist of initially creating the home directory root-owned and only+changing the owner of the home directory once all skeletons have been copied+and their owner has been set.++# Upgrading++To upgrade the Guix System, run something like:++```+guix pull+sudo guix system reconfigure /run/current-system/configuration.scm+sudo reboot+```++As the user account activation code is run as a shepherd service,+the last step is required to make sure the fixed activation code+is run in the future.++To avoid the vulnerability while upgrading the system, only declare+new user accounts in the configuration file after the Guix System+has been upgraded.++# Conclusions++The activation code in Guix System originally was written with the+assumption that no other code was running at the same time in mind.+However, this is not a reasonable assumption in practice, as this+vulnerability demonstrates. Thus, it may be worthwhile to look+over other activation code for similar issues.++While investigating how to fix the issue, it became apparent GNU Guile,+the implementation of the Algorithmic Language Scheme GNU Guix is+written in, is lacking in primitives that usually are used to avoid+these kind of issues, such `openat` and `O_NOFOLLOW`.++While these primitives turned out not to be necessary to fix the+issue and a [patch series](<https://lists.gnu.org/archive/html/guile-devel/2021-03/msg00026.html>)+to GNU Guile has been submitted that adds these primitives, this does+serve as a remainder that GNU Guile is a critical component of+Guix System and working around missing primitives will not always be possible.++This issue is tracked as+[bugĀ #47584](https://issues.guix.gnu.org/47584); you can read the thread+for more information.++Please report any issues you may have to+[`guix-devel@gnu.org`](https://guix.gnu.org/en/contact/). See the+[security web page](https://guix.gnu.org/en/security/) for information+on how to report security issues.++#### About GNU Guix++[GNU Guix](https://guix.gnu.org) is a transactional package manager and+an advanced distribution of the GNU system that [respects user+freedom](https://www.gnu.org/distros/free-system-distribution-guidelines.html).+Guix can be used on top of any system running the Hurd or the Linux+kernel, or it can be used as a standalone operating system distribution+for i686, x86_64, ARMv7, and AArch64 machines.++In addition to standard package management features, Guix supports+transactional upgrades and roll-backs, unprivileged package management,+per-user profiles, and garbage collection. When used as a standalone+GNU/Linux distribution, Guix offers a declarative, stateless approach to+operating system configuration management. Guix is highly customizable+and hackable through [Guile](https://www.gnu.org/software/guile)+programming interfaces and extensions to the+[Scheme](http://schemers.org) language.-- 2.31.1
-----BEGIN PGP SIGNATURE-----
iI0EABYIADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYGiXTRccbWF4aW1lZGV2b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7oxTAQCeeZXcTeSkip96gSft8n+eq6/BiZoD91S8vYW1vc4PwAEAku2n5CPJ5b9ZcEXXD8sFCxIHTLEwK7vAJdDShW6F9gU==6RhR-----END PGP SIGNATURE-----

M
M
Maxime Devos wrote on 3 Apr 18:32 +0200
(address . 47584@debbugs.gnu.org)
67e04c1c532d4553c5456ebf581d7d3d3d59733c.camel@telenet.be
On Sat, 2021-04-03 at 18:22 +0200, Maxime Devos wrote:
Toggle quote (5 lines)> + ;; It is important 'chown' is called after 'copy-account-skeletons'> + ;; Otherwise, a malicious user with good timing could> + ;; create a symlink in HOME that would be dereferenced by> + ;; 'copy-account-skeletons'.
Oops please add a period after 'copy-account-skeletons';
M
M
Maxime Devos wrote on 3 Apr 18:38 +0200
(address . control@debbugs.gnu.org)
dd6295e1baa2b7e12b5518dc3c024813fa32f498.camel@telenet.be
tags 47584 + security patchseverity 47584 importantthanks
L
L
Ludovic Courtès wrote on 3 Apr 22:15 +0200
Re: bug#47584: Race condition in ‘copy-account- skeletons’: possible privilege escalation.
(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 47584@debbugs.gnu.org)
87y2dzw2dq.fsf@gnu.org
Hi Maxime,
Maxime Devos <maximedevos@telenet.be> skribis:
Toggle quote (19 lines)> From 9672bd37bf50db1e0989d0b84035c4788422bd31 Mon Sep 17 00:00:00 2001> From: Maxime Devos <maximedevos@telenet.be>> Date: Tue, 30 Mar 2021 22:36:14 +0200> Subject: [PATCH 1/2] activation: Do not dereference symlinks in home directory> creation.> MIME-Version: 1.0> Content-Type: text/plain; charset=UTF-8> Content-Transfer-Encoding: 8bit>> Fixes <https://bugs.gnu.org/47584>.>> * gnu/build/activation.scm> (copy-account-skeletons): Do not chown the home directory; leave this> to 'activate-user-home'.> (activate-user-home): Only chown the home directory after the account> skeletons have been copied.>> Co-authored-by: Ludovic Courtès <ludo@gnu.org>.
Toggle quote (10 lines)> From d071ee3aff5be1a6d7876d7411e70f7283dce1fb Mon Sep 17 00:00:00 2001> From: Maxime Devos <maximedevos@telenet.be>> Date: Sat, 3 Apr 2021 12:19:10 +0200> Subject: [PATCH 2/2] news: Add entry for user account activation> vulnerability.>> TODO for guix committer: correct the commit id appropriately.>> * etc/news.scm: Add entry.
I tweaked it to (1) make it clear upfront that only Guix System isaffected, (2) to explicitly recommend an upgrade on Guix System, and (3)to clarify when the attack can happen.
Thanks for finding the issue, for reporting it at guix-security, and forpreparing these patches!
Ludo’.
L
L
Ludovic Courtès wrote on 3 Apr 22:27 +0200
(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 47584@debbugs.gnu.org)
87sg47w1uc.fsf@gnu.org
Note that this issue is about Guix System; users of Guix on otherdistros are unaffected.
Maxime Devos <maximedevos@telenet.be> skribis:
Toggle quote (12 lines)> The attack consists of the user being logged in after the account> skeletons have been copied to the home directory, but before the> owner of the account skeletons have been set. The user then deletes> a copied account skeleton (e.g. @file{$HOME/.gdbinit}) and replaces> it with a symbolic link to a file not owned by the user, such as> @file{/etc/shadow}.>> The activation code then changes the ownership> of the file the symbolic link points to instead of the symbolic> link itself. At that point, the user has read-write access> to the target file.
To give a bit more context, account creation on Guix System happenswhile ‘guix system reconfigure’ is running.
The user whose account is being created thus needs to be able to log inright during the time window described above.
Users whose password is uninitialized (i.e., the ‘password’ field of<user-account> is left unspecified¹) cannot log in at that point, unlesspossibly if the OpenSSH configuration specifies an authorized key forthe user account.
Ludo’.
¹ https://guix.gnu.org/manual/en/html_node/User-Accounts.html² https://guix.gnu.org/manual/en/html_node/Networking-Services.html#index-openssh_002dservice_002dtype
L
L
Ludovic Courtès wrote on 3 Apr 22:33 +0200
(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 47584@debbugs.gnu.org)
87mtufw1kh.fsf@gnu.org
Maxime Devos <maximedevos@telenet.be> skribis:
Toggle quote (12 lines)> The attack consists of the user being logged in after the account> skeletons have been copied to the home directory, but before the> owner of the account skeletons have been set. The user then deletes> a copied account skeleton (e.g. @file{$HOME/.gdbinit}) and replaces> it with a symbolic link to a file not owned by the user, such as> @file{/etc/shadow}.>> The activation code then changes the ownership> of the file the symbolic link points to instead of the symbolic> link itself. At that point, the user has read-write access> to the target file.
In the draft blog post, you mention that the attack cannot be carriedout when protected symlinks are enabled. This is now the case bydefault on Guix System¹, so in that case, a system upgraded from acommit after March 16th is unaffected.
Ludo’.
¹ https://issues.guix.gnu.org/47013#13
L
L
Ludovic Courtès wrote on 3 Apr 22:45 +0200
(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 47584@debbugs.gnu.org)
87czvbw0zk.fsf@gnu.org
Maxime Devos <maximedevos@telenet.be> skribis:
Toggle quote (11 lines)> From 7937b9f18085569e5d7cb8a3c4dc08e1088a94a9 Mon Sep 17 00:00:00 2001> From: Maxime Devos <maximedevos@telenet.be>> Date: Sat, 3 Apr 2021 18:02:05 +0200> Subject: [PATCH] =?UTF-8?q?website:=20Add=20post=20about=20vulnerability?=> =?UTF-8?q?=20in=20=E2=80=98copy-account-skeletons=E2=80=99.?=> MIME-Version: 1.0> Content-Type: text/plain; charset=UTF-8> Content-Transfer-Encoding: 8bit>> * website/posts/home-symlink.md: New post.
It’s unfortunate that this is going out during a week-end, and athree-day week-end on top of that in some regions of the world, withmany people not seeing the message and not being able to act upon it forthree days.
Toggle quote (11 lines)> +title: Risk of local privilege escalation in account creation> +date: 2021-04-03 17:30> +author: Maxime Devos> +tags: Security Advisory> +---> +> +A security vulnerability that can lead to local privilege escalation> +has been found in the activation code of user accounts (excluding> +system accounts). It does not affect users on foreign distros> +and is only exploitable during system reconfiguration.
How about this, taken from the news.scm entry I tweaked:
A security vulnerability that can lead to local privilege escalation has been found in the code that creates user accounts on Guix System—Guix on other distros is unaffected. The system is only vulnerable during the activation of non-system user accounts that do not already exist.
(This is more upfront about who’s affected and avoids the technical term“activation code” which makes no sense outside the circle of Guix Systemand NixOS hackers.)
Toggle quote (5 lines)> +This exploit is _not_ impossible on machines where the Linux [protected> +symlinks](https://sysctl-explorer.net/fs/protected_symlinks/) feature> +is enabled. It is believed the attack can also be performed using hard> +links.
Please mention that protected symlinks are enabled by default on GuixSystem since a March 16th commit, with a link tohttps://issues.guix.gnu.org/47013#13.
Toggle quote (8 lines)> +# Conclusions> +> +The activation code in Guix System originally was written with the> +assumption that no other code was running at the same time in mind.> +However, this is not a reasonable assumption in practice, as this> +vulnerability demonstrates. Thus, it may be worthwhile to look> +over other activation code for similar issues.
That’s an interesting conclusion for us developers, but not necessarilyfor the users this is targeting. It also sounds unnecessarily scary andcasual.
Toggle quote (11 lines)> +While investigating how to fix the issue, it became apparent GNU Guile,> +the implementation of the Algorithmic Language Scheme GNU Guix is> +written in, is lacking in primitives that usually are used to avoid> +these kind of issues, such `openat` and `O_NOFOLLOW`.> +> +While these primitives turned out not to be necessary to fix the> +issue and a [patch series](<https://lists.gnu.org/archive/html/guile-devel/2021-03/msg00026.html>)> +to GNU Guile has been submitted that adds these primitives, this does> +serve as a remainder that GNU Guile is a critical component of> +Guix System and working around missing primitives will not always be possible.
All this is true but also probably too detailed (or not enough,depending on the reader). How about just mentioning that work isongoing to support the `openat` family of POSIX functions in Guile,which, when used, while help address this class of vulnerability?
Otherwise LGTM, thanks!
Ludo’.
L
L
Ludovic Courtès wrote on 3 Apr 22:49 +0200
(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 47584@debbugs.gnu.org)
878s5zw0tn.fsf@gnu.org
Maxime Devos <maximedevos@telenet.be> skribis:
Toggle quote (7 lines)> +The attack consists of the user being logged in after the account> +skeletons have been copied to the home directory, but before the> +owner of the account skeletons have been set. The user then deletes> +a copied account skeleton (e.g. `$HOME/.gdbinit`) and replaces> +it with a symbolic link to a file not owned by the user, such as> +`/etc/shadow`.
Also… in this paragraph, it’s not entirely clear which user we’retalking about it. In news.scm, I reworded it like so:
The attack can happen when @command{guix system reconfigure} is running. Running @command{guix system reconfigure} can trigger the creation of new user accounts if the configuration specifies new accounts. If a user whose account is being created manages to log in after the account has been created but before ``skeleton files'' copied to its home directory have the right ownership, they may, by creating an appropriately-named symbolic link in the home directory pointing to a sensitive file, such as @file{/etc/shadow}, get root privileges.
It may also be worth mentioning that the user is likely unable to log inat all at that point, as I wrote here:
https://issues.guix.gnu.org/47584#6
WDYT?
Ludo’.
M
M
Maxime Devos wrote on 4 Apr 09:36 +0200
Re: bug#47584: Race condition in ‘copy-account-skeletons’: possible privilege escalation.
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 47584@debbugs.gnu.org)
7ab30aad812e5de1216c95b3becb784e3363e615.camel@telenet.be
On Sat, 2021-04-03 at 22:33 +0200, Ludovic Courtès wrote:
Toggle quote (17 lines)> Maxime Devos <maximedevos@telenet.be> skribis:> > > The attack consists of the user being logged in after the account> > skeletons have been copied to the home directory, but before the> > owner of the account skeletons have been set. The user then deletes> > a copied account skeleton (e.g. @file{$HOME/.gdbinit}) and replaces> > it with a symbolic link to a file not owned by the user, such as> > @file{/etc/shadow}.> > > > The activation code then changes the ownership> > of the file the symbolic link points to instead of the symbolic> > link itself. At that point, the user has read-write access> > to the target file.> > In the draft blog post, you mention that the attack cannot be carried> out when protected symlinks are enabled.
In the blog post, I thought I wrote the attack can be carried out*even if* protected symlinks are enabled. Looking at
https://sysctl-explorer.net/fs/protected_symlinks/,
I don't think the Linux protected symlink feature helps, as homedirectories are never sticky and word-writable.
Perhaps I should have written ‘possible’ instead of ‘not impossible’in the blog post.
Toggle quote (3 lines)> Please mention that protected symlinks are enabled by default on Guix> System since a March 16th commit, with a link to [...]
See my response above.
I agree with all other comments on this bug report.
Greetings,Maxime.
-----BEGIN PGP SIGNATURE-----
iI0EABYIADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYGlsZRccbWF4aW1lZGV2b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7nfCAQDK+Ax9TJ45aL/KI0IrAe7ViBORCchmjv3U/Nfrr73cggEA6DKXJYvn8dc+pKJy8XosAFkl/GwWjcnHHtqH08zp/QM==UX7H-----END PGP SIGNATURE-----

M
M
Maxime Devos wrote on 4 Apr 15:29 +0200
(address . 47584@debbugs.gnu.org)
06e348e862e473525b9a6d7fbeb9a142bb6a1ddd.camel@telenet.be
On Sat, 2021-04-03 at 18:26 +0200, Maxime Devos wrote:
Toggle quote (1 lines)> A suggested blog post is attached.
A revised blog post is attached.
The following points are currently _not_ addressed:
Ludovic Courtès wrote:
Toggle quote (14 lines)> Also… in this paragraph, it’s not entirely clear which user we’re> talking about it. In news.scm, I reworded it like so:> The attack can happen when @command{guix system reconfigure} is running.> Running @command{guix system reconfigure} can trigger the creation of new user> accounts if the configuration specifies new accounts. If a user whose account> is being created manages to log in after the account has been created but> before ``skeleton files'' copied to its home directory have the right> ownership, they may, by creating an appropriately-named symbolic link in the> home directory pointing to a sensitive file, such as @file{/etc/shadow}, get> root privileges.>> It may also be worth mentioning that the user is likely unable to log in> at all at that point, as I wrote here:
I can't think of something along these lines to write at the moment ...
Greetings,Maxime.
From 10b4528aac6cd9c0c341634b9f163f0a38ec4c6b Mon Sep 17 00:00:00 2001From: Maxime Devos <maximedevos@telenet.be>Date: Sat, 3 Apr 2021 18:02:05 +0200Subject: [PATCH] =?UTF-8?q?website:=20Add=20post=20about=20vulnerability?= =?UTF-8?q?=20in=20=E2=80=98copy-account-skeletons=E2=80=99.?=MIME-Version: 1.0Content-Type: text/plain; charset=UTF-8Content-Transfer-Encoding: 8bit
* website/posts/home-symlink.md: New post.
Co-authored-by: Ludovic Courtès <ludo@gnu.org>--- website/posts/home-symlink.md | 86 +++++++++++++++++++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 website/posts/home-symlink.md
Toggle diff (94 lines)diff --git a/website/posts/home-symlink.md b/website/posts/home-symlink.mdnew file mode 100644index 0000000..67f3053--- /dev/null+++ b/website/posts/home-symlink.md@@ -0,0 +1,86 @@+title: Risk of local privilege escalation in account creation+date: 2021-04-04 15:30+author: Maxime Devos, Ludovic Courtès+tags: Security Advisory+---++A security vulnerability that can lead to local privilege+escalation has been found in the code that creates user accounts on Guix+System—Guix on other distros is unaffected. The system is only vulnerable+during the activation of non-system user accounts that do not already exist.++This exploit is _not_ prevented by the Linux [protected+symlinks](https://sysctl-explorer.net/fs/protected_symlinks/) feature.++# Vulnerability++The attack consists of the user being logged in after the account+skeletons have been copied to the home directory, but before the+owner of the account skeletons have been set. The user then deletes+a copied account skeleton (e.g. `$HOME/.gdbinit`) and replaces+it with a symbolic link to a file not owned by the user, such as+`/etc/shadow`.++The activation code then changes the ownership of the file the symbolic+link points to instead of the symbolic link itself. At that point, the+user has read-write access to the target file.++# Fix++This [bug](https://issues.guix.gnu.org/47584) has been+[fixed](https://git.savannah.gnu.org/cgit/guix.git/commit/?id=2161820ebbbab62a5ce76c9101ebaec54dc61586).+See below for upgrade instructions.++The fix consist of initially creating the home directory root-owned and only+changing the owner of the home directory once all skeletons have been copied+and their owner has been set.++# Upgrading++To upgrade the Guix System, run something like:++```+guix pull+sudo guix system reconfigure /run/current-system/configuration.scm+sudo reboot+```++As the user account activation code is run as a shepherd service,+the last step is required to make sure the fixed activation code+is run in the future.++To avoid the vulnerability while upgrading the system, only declare+new user accounts in the configuration file after the Guix System+has been upgraded.++# Conclusions++Work is ongoing to support the `openat` family of POSIX functions in+Guile, which, when used, help address this class of vulnerabilities.++This issue is tracked as+[bugĀ #47584](https://issues.guix.gnu.org/47584); you can read the thread+for more information.++Please report any issues you may have to+[`guix-devel@gnu.org`](https://guix.gnu.org/en/contact/). See the+[security web page](https://guix.gnu.org/en/security/) for information+on how to report security issues.++#### About GNU Guix++[GNU Guix](https://guix.gnu.org) is a transactional package manager and+an advanced distribution of the GNU system that [respects user+freedom](https://www.gnu.org/distros/free-system-distribution-guidelines.html).+Guix can be used on top of any system running the Hurd or the Linux+kernel, or it can be used as a standalone operating system distribution+for i686, x86_64, ARMv7, and AArch64 machines.++In addition to standard package management features, Guix supports+transactional upgrades and roll-backs, unprivileged package management,+per-user profiles, and garbage collection. When used as a standalone+GNU/Linux distribution, Guix offers a declarative, stateless approach to+operating system configuration management. Guix is highly customizable+and hackable through [Guile](https://www.gnu.org/software/guile)+programming interfaces and extensions to the+[Scheme](http://schemers.org) language.-- 2.31.1
-----BEGIN PGP SIGNATURE-----
iI0EABYIADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYGm/HhccbWF4aW1lZGV2b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7gOuAP4tiShMw0wcPnXaQOEAsH2ZF8+KfWgrX6P5rFS+2lysTgEAtFETSQvqwdujktK3lf2czEe0XVj+ioF2hjoccFbxCQ4==7Hri-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 5 Apr 21:54 +0200
Re: bug#47584: Race condition in ‘copy-account- skeletons’: possible privilege escalation.
(name . Maxime Devos)(address . maximedevos@telenet.be)
87zgycqzfz.fsf@gnu.org
Hi Maxime,
Maxime Devos <maximedevos@telenet.be> skribis:
Toggle quote (26 lines)> On Sat, 2021-04-03 at 22:33 +0200, Ludovic Courtès wrote:>> Maxime Devos <maximedevos@telenet.be> skribis:>> >> > The attack consists of the user being logged in after the account>> > skeletons have been copied to the home directory, but before the>> > owner of the account skeletons have been set. The user then deletes>> > a copied account skeleton (e.g. @file{$HOME/.gdbinit}) and replaces>> > it with a symbolic link to a file not owned by the user, such as>> > @file{/etc/shadow}.>> > >> > The activation code then changes the ownership>> > of the file the symbolic link points to instead of the symbolic>> > link itself. At that point, the user has read-write access>> > to the target file.>> >> In the draft blog post, you mention that the attack cannot be carried>> out when protected symlinks are enabled.>> In the blog post, I thought I wrote the attack can be carried out> *even if* protected symlinks are enabled. Looking at>> https://sysctl-explorer.net/fs/protected_symlinks/,>> I don't think the Linux protected symlink feature helps, as home> directories are never sticky and word-writable.
Oh right, my bad, I overlooked this.
Toggle quote (3 lines)> Perhaps I should have written ‘possible’ instead of ‘not impossible’> in the blog post.
Dunno, maybe it’s just me not paying enough attention.
Toggle quote (2 lines)> I agree with all other comments on this bug report.
OK. It does mean that the bug is hardly exploitable in practice: youhave to be able to log in at all, and if you’re able to log in, you haveto log in precisely within the 1s (or less) that follows accountcreation, which sounds challenging (TCP + SSH connection establishmentis likely to take as much time or more, likewise for typing in yourpassword.) It’s also one-time chance.
Do I get it right?
Does it warrant as strong messaging as for the recent daemon‘--keep-failed’ vulnerability?
Thanks,Ludo’.
M
M
Maxime Devos wrote on 6 Apr 11:56 +0200
Re: bug#47584: Race condition in ‘copy-account-skeletons’: possible privilege escalation.
(name . Ludovic Courtès)(address . ludo@gnu.org)
00621260aa43f1918aaf0f0bb2318bf359b826c3.camel@telenet.be
On Mon, 2021-04-05 at 21:54 +0200, Ludovic Courtès wrote:
Toggle quote (4 lines)> [...]> > OK. It does mean that the bug is hardly exploitable in practice: you> have to be able to log in at all,
Yes.
Toggle quote (5 lines)> and if you’re able to log in, you have> to log in precisely within the 1s (or less) that follows account> creation, which sounds challenging (TCP + SSH connection establishment> is likely to take as much time or more,
Is logging in possible when the home directory doesn't exist?It isn't possible from the console. I guess it isn't possible from SSHeither.
If it is possible,then the window would be somewhat larger I think. Account creation is doneat activation time, while creating home directories is done as a shepherdservice (see account-service-type in gnu/system/shadow.scm).
Toggle quote (1 lines)> likewise for typing in your password.)
An attacker could copy and paste, or have used a single-character password,to save some time.
Toggle quote (2 lines)> It’s also one-time chance.
Yes.
Toggle quote (2 lines)> Do I get it right?
I think so, except the window might be larger (but still a one-time chance).
Toggle quote (3 lines)> Does it warrant as strong messaging as for the recent daemon> ‘--keep-failed’ vulnerability?
As it is a one-time chance, with a limited window, and only under specificcircumstances (creating a new user account), I don't think so. But I wouldstill recommend to upgrade. Does the blog post have ‘too strong messaging’?
Greetings,Maxime
-----BEGIN PGP SIGNATURE-----
iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYGwwRxccbWF4aW1lZGV2b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7rX2AP0ak8CCNXY2v2apFETUInxpt8UZ6E0vkWhJvLARcgTkHwEAnnHFIqZOe+EvFa3Ex3qOefhHRIiwFKE8xB0gCdpZsQQ==oG1p-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 6 Apr 13:57 +0200
Re: bug#47584: Race condition in ‘copy-account- skeletons’: possible privilege escalation.
(name . Maxime Devos)(address . maximedevos@telenet.be)
87v98zmxrf.fsf@gnu.org
Hi Maxime,
Maxime Devos <maximedevos@telenet.be> skribis:
Toggle quote (14 lines)> On Mon, 2021-04-05 at 21:54 +0200, Ludovic Courtès wrote:>> [...]>> >> OK. It does mean that the bug is hardly exploitable in practice: you>> have to be able to log in at all,> Yes.>>> and if you’re able to log in, you have>> to log in precisely within the 1s (or less) that follows account>> creation, which sounds challenging (TCP + SSH connection establishment>> is likely to take as much time or more,>> Is logging in possible when the home directory doesn't exist?
I think so.
Toggle quote (3 lines)> An attacker could copy and paste, or have used a single-character password,> to save some time.
Hmm yes. It’s a bit a far-fetched though: the attacker would havepassed the sysadmin the output of the ‘crypt’ procedure, such that thesysadmin cannot know the password length.
Toggle quote (7 lines)>> Does it warrant as strong messaging as for the recent daemon>> ‘--keep-failed’ vulnerability?>> As it is a one-time chance, with a limited window, and only under specific> circumstances (creating a new user account), I don't think so. But I would> still recommend to upgrade. Does the blog post have ‘too strong messaging’?
The blog post and info-guix messages are the highest levels ofvisibility we can give, roughly. So I think we have to think twicebefore doing that or truly important issues will eventually gounnoticed.
The risk with this issue seems much lower than that of the keep-failedissue, it even looks super low.
WDYT?
Ludo’.
M
M
Maxime Devos wrote on 7 Apr 20:28 +0200
Re: bug#47584: Race condition in ‘copy-account-skeletons’: possible privilege escalation.
(name . Ludovic Courtès)(address . ludo@gnu.org)
a53422e3ee586dcd4709c2cc6f3d926a4906f674.camel@telenet.be
On Tue, 2021-04-06 at 13:57 +0200, Ludovic Courtès wrote:
Toggle quote (12 lines)> [...]> > The blog post and info-guix messages are the highest levels of> visibility we can give, roughly. So I think we have to think twice> before doing that or truly important issues will eventually go> unnoticed.> > The risk with this issue seems much lower than that of the keep-failed> issue, it even looks super low.> > WDYT?
That is a good point, but I still wonder if there's *somewhere* thiscan be posted.
I was going to start a thread at guix-devel aboutblog posts in general (categories, what can be posted as a ‘official’blog post on guix.gnu.org, any maximal frequencies ...) but I ended upbeing busy with other things.
Greetings,Maxime.
-----BEGIN PGP SIGNATURE-----
iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYG35shccbWF4aW1lZGV2b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7mywAP9WT/4fcsut/kfKl1AGtJClAHcrhqxh/JDbDLfjIFoMZQEAl3CncOdeiCIhTTK9caA/P3zWJIb0URWoVNqPDJgrrw4==o7S+-----END PGP SIGNATURE-----

?