emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#47584: closed (Race condition in ‘copy-account-skeletons’: possible


From: GNU bug Tracking System
Subject: bug#47584: closed (Race condition in ‘copy-account-skeletons’: possible privilege escalation.)
Date: Fri, 06 Sep 2024 11:32:03 +0000

Your message dated Fri, 06 Sep 2024 11:49:46 +0200
with message-id <87jzfpyuv9.fsf_-_@gnu.org>
and subject line Re: bug#47584: Race condition in ‘copy-account-skeletons’: 
possible privilege escalation.
has caused the debbugs.gnu.org bug report #47584,
regarding Race condition in ‘copy-account-skeletons’: possible privilege 
escalation.
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
47584: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47584
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: Race condition in ‘copy-account-skeletons’: possible privilege escalation. Date: Sat, 03 Apr 2021 18:09:16 +0200 User-agent: Evolution 3.34.2
A TOCTTOU (time-of-check to time-of-use) vulnerability has been found
in the activation code of user accounts, more specifically in the
code that copies the account skeletons.

* 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. @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.

* 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 it
owner, 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 does
not already exist.

* Fix

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.

* Extra notes

A blog post, a news entry and a fix have been prepared and will be posted
and hopefully merged soon.  The following tests succeeded:

$ make check-system TESTS='switch-to-system upgrade-services install-bootloader 
basic'
$ make check

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
--- Begin Message --- Subject: Re: bug#47584: Race condition in ‘copy-account-skeletons’: possible privilege escalation. Date: Fri, 06 Sep 2024 11:49:46 +0200 User-agent: Gnus/5.13 (Gnus v5.13)
Hello,

Maxime Devos <maximedevos@telenet.be> skribis:

> I removed the 'Based upon mkdir-p from (guix build utils)'
> comment because it's quite a bit different now.
>
> * gnu/build/activation.scm (verify-not-symbolic): Delete.
> (mkdir-p/perms): Rewrite in terms of 'openat'.

Finally pushed as c1283e203995c8d84584e701b965efe086d1d666, now that
Guile 3.0.9 with the *at family of procedures is the default (and has
been for a while, actually).

Great work both in Guile upstream and in Guix here.

Ludo’.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]