Permissions on files created inside /tmp/.dotnet are too open

[gorazdzagar]

Permissions on files created inside /tmp/.dotnet are too open

While executing the dotnet restore, temporary file permissions created under the session subfolders inside /tmp/.dotnet/shm/ are too open.

General

Dotnet SDK version: 3.1.302

While executing the dotnet restore, the build sessions subfolder is created under /tmp/.dotnet/shm/.

Example:

/tmp/.dotnet/shm/session5550# ls -la total 56 drwxrwxrwx 2 root root 4096 Aug 24 08:02 . drwxrwxrwx 4 root root 36864 Aug 24 08:02 .. -rw-rw-rw- 1 root root 4096 Aug 24 08:02 2467f586da4947fd99b79661ba0330fe -rw-rw-rw- 1 root root 4096 Aug 24 08:02 f58babb546ad4d38a2a5afd2ed6511d1 -rw-rw-rw- 1 root root 4096 Aug 24 08:02 PiDh3VmOno5IZWwRHV_oNjZ+jcby9Rt5wuWKeDyQUJY.server

Folder as well as file permissions are too open. Group rw is unnecessary and might present a security risk.

Such files on a Linux system fail the CIS Ubuntu 16.04 LTS Hardening Requirements check no. 6.1.10 Ensure no world writable files exist (Scored) therefore we consider this type of file creation process a security threat.

The executed command dotnet restore does not respect the umask set (either system-wide or per current bash session).

Similar issue was reported last year (https://github.com/NuGet/Home/issues/7673) which resulted in the CVE being published for it.

[danmoseley]

@NikolaMilosavljevic do you know who creates this? Which repo should this transfer to.

[omajid]

Does this also impact https://github.com/dotnet/designs/pull/88 ? That also relies on globally writable files under /tmp/ (at least as a fallback).

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[danmoseley]

Can you help figure out where this should go?

cc @blowdart

[blowdart]

This should have been fixed as part of https://github.com/NuGet/Home/issues/7673 I would have thought.

So whoever owns dotnet restore needs to own this, I don't know who that is.

[marcpopMSFT]

@aortiz-msft @nkolev92 there's an internal report of something very similar to this still happening. Can ya'll engage with @dsplaisted who is on the chat about it?

[ckrueger1979]

Problem still exists and might be a huge security problem!

Why does pwsh/dotnet core create tmp file world readable? The PSReadLineHistoryFile can contain very sensitive information.

ls -lisa /tmp/.dotnet/shm/session635705/
total 4
8409348 0 drwxrwxrwx. 2 myuser domain users   45 Apr  9 15:10 .
4194564 0 drwxrwxrwx. 3 myuser domain users   27 Apr  9 15:10 ..
8409349 4 -rw-rw-rw-. 1 myuser domain users 4096 Apr  9 15:41 PSReadLineHistoryFile_257560920

[KalleOlaviNiemitalo]

@ckrueger1979 does that file actually contain any PSReadLine history, or is the file only used for synchronising access to a history file that resides somewhere else?

[ckrueger1979]

I'm not sure what the file exactly is

It seems to be a binary, first lines of the file:

00000000: 00000000 00000001 00000000 00000000 00000000 00000000  ......
00000006: 00000000 00000000 00000000 00000000 00000000 00000000  ......
0000000c: 00000000 00000000 00000000 00000000 00000000 00000000  ......
00000012: 00000000 00000000 00000000 00000000 00000000 00000000  ......
00000018: 10010001 00000000 00000000 00000000 00000000 00000000  ......
0000001e: 00000000 00000000 00000000 00000000 00000000 00000000  ......
00000024: 00000000 00000000 00000000 00000000 00000000 00000000  ......
0000002a: 00000000 00000000 00000000 00000000 00000000 00000000  ......
00000030: 11111111 11111111 11111111 11111111 00000000 00000000  ......
00000036: 00000000 00000000 11111111 11111111 11111111 11111111  ......
0000003c: 11111111 11111111 11111111 11111111 00000000 00000000  ......
00000042: 00000000 00000000 00000000 00000000 00000000 00000000  ......
00000048: 00000000 00000000 00000000 00000000 00000000 00000000  ......
0000004e: 00000000 00000000 00000000 00000000 00000000 00000000  ......
00000054: 00000000 00000000 00000000 00000000 00000000 00000000  ......

There is another file located in the home directory that contains the cleartext history ./.local/share/powershell/PSReadLine/ConsoleHost_history.txt

[KalleOlaviNiemitalo]

".dotnet/shm" is referenced here: https://github.com/dotnet/runtime/blob/22d12888e1c327e9edad74a090b265c11f48cd12/src/coreclr/pal/src/include/pal/sharedmemory.h#L31

"PSReadLineHistoryFile" is referenced here: https://github.com/PowerShell/PSReadLine/blob/4023f0607d917caffa4bfbf436bef124f874127d/PSReadLine/History.cs#L256-L266 https://github.com/PowerShell/PSReadLine/blob/4023f0607d917caffa4bfbf436bef124f874127d/PSReadLine/Options.cs#L129

It appears that PSReadLine creates a Mutex instance to synchronise access to the history file, and the .NET Runtime implementation of Mutex on non-Windows operating systems creates a file in ".dotnet/shm" and maps that to memory. I guess the reason for using a Mutex, rather than FileShare flags or FileStream.Lock, is that PSReadLine wants to wait for the other process to finish what it's doing, rather than give up immediately.

So I don't think malicious users can access your PSReadLine history, even if they can read and write the shm mutex file. Some sort of denial-of-service attack may be possible, but tightening the permissions on the directory would not fix that, because the malicious user could still create the directory before you and prevent you from using it.

A real fix might be to place the memory-mapped files of session-specific mutexes in the XDG_RUNTIME_DIR directory, which is specified to be accessible by one user only.

[nbennke]

Any plans on changes here? What about automatically adding sticky bits to the folders?