environment variables used by the pam module about pam-u2f

[a-dma]

Hey, thanks for the report.

The first part is expected behavior I would say. Since you specified required rather than requisite the authentication won't fail right away, but if you continue the process by typing in your password you will eventually get a failure.

The second part is indeed an issue. I've pushed some code to fix that.
There is now an additional check that makes sure that the authentication file is owned either by the target user or by root.

I believe this is the best solution. I'll be making a new release later this afternoon/tomorrow and will also publish a security advisory.

Comments are welcome.

A.

[keszybz]

I don't think this is the right solution.

You are still allowing the environment variable to cross the security boundary, between the unauthenticated user and the privileged authentication code (*). You're probably looking for secure_getenv(3), it is designed for such uses.

(*) It is relatively easy to construct scenarios where this check can be circumvented. For example, let's say that the root user creates an example file anywhere, owned by root. Then you can create the right directory structure, and symlink to this file in the right place, and set the variable. Now this file will be used to authenticate the root user. This also applies to backups, the user renaming a file to provide a new one, etc, etc. In each of those cases, this new check can be circumvented.

[a-dma]

The reason why I don't like secure_getenv is that it's GNU specific.

I'm not sure I follow your example with the symlink, the content of the file is still written by root, the pam module configuration file is written and owned by root. You would have to have a valid file, owned by root in a path where your user has write access. Probably I'm not getting your example correctly.
Anyway, symlink can be disabled.

A.

[keszybz]

The reason why I don't like secure_getenv is that it's GNU specific.

You can reimplement a fallback if it is not available. It's not terribly sophisticated.

I'm not sure I follow your example with the symlink

The way I understand the "promise" from the u2f pam module is that "the file /root/Yubico/u2f_keys" will be used to authenticate for the root user. If a user can convince the module to use any other file the promise is broken.

Specifically: root looses his dongle, moves /root/Yubico/u2f_keys → /root/Yubico/u2f_keys.bad, and creates new /root/Yubico/u2f_keys file. Eve finds the old dongle, can authenticate by specifying doing mkdir /tmp/Yubico && ln -s /root/Yubico/u2f_keys.bad /tmp/Yibico/u2f_keys && XDG_CONFIG_HOME=/tmp su -. A different example: user is allow to automount a cdrom. The cdrom is mounted nosuid so it shouldn't be usable for privilege escalation. Eve inserts a cdrom with root owned u2f_keys file and the right directory structure, repeat of story. You can try playing whack-a-mole with checking permissions but it's a lost cause.

[a-dma]

True about implementing a replacement.

As for the examples they look pretty crafted to me, it's like saying that Eve can login as root because she has found a readable file with the plain-text password.
On top of that it seems to me that stripping away the possibility of following symlinks handles these cases.
Mounting another file-system is something that only root is allowed to do, including automounts since root owns /etc/fstab.

I don't think this is a whack-a-mole game, but a matter of defining all the correct cases and addressing them.

And if at some point we can't find a reasonable solution to address the problem I think the better solution is to remove the functionality altogether.

[keszybz]

All modern desktops allow uses to mount filesystems from insertable media (usb keys, cdroms, phones, cards). At that point you don't need symlinks to mount an attack.

And if at some point we can't find a reasonable solution to address the problem I think the better solution is to remove the functionality altogether.

Certainly removing this feature is better than doing nothing.

[a-dma]

Pushed new code using secure_getenv where available and doing nothing otherwise.

As always comments are welcome.

[keszybz]

Bug seems to be resolved with the patches, $XDG_CONFIG_HOME is ignored.

Thanks.