bug-guix
[Top][All Lists]
Advanced

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

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


From: Ludovic Courtès
Subject: bug#47584: Race condition in ‘copy-account-skeletons’: possible privilege escalation.
Date: Mon, 05 Apr 2021 21:54:56 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Hi Maxime,

Maxime Devos <maximedevos@telenet.be> skribis:

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

> Perhaps I should have written ‘possible’ instead of ‘not impossible’
> in the blog post.

Dunno, maybe it’s just me not paying enough attention.

> I agree with all other comments on this bug report.

OK.  It does mean that the bug is hardly exploitable in practice: you
have to be able to log in at all, 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, likewise for typing in your
password.)  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’.





reply via email to

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