Leak of az secrets in file system system calls

[freedge]

this is a spin off of Azure/login#27

when running

az login --service-principal -u $U --tenant $T -p $P

the secret is leaked on the command line as known, it is also leaked through a newfstatat system call.

This is undocumented but it's possible to use instead a "@" so that the password is read from a file, eg in this fashion

az login --service-principal -u $U --tenant $T -p @<(echo "$P")

which prevents the password leak on the command line (in some cases somewhat addressing #10241 and #27938), however it is still leaked in the newfstatat system call:

15547 newfstatat(AT_FDCWD, "W3x..., 0x7fffe0296410, 0) = -1 ENOENT (No such file or directory)

performed from

azure-cli/src/azure-cli-core/azure/cli/core/auth/identity.py

Lines 285 to 286 in 246725e

	user_expanded = os.path.expanduser(secret_or_certificate)
	if os.path.isfile(user_expanded):

this means the secret is leaked to the file system (if a network file system like NFS it is sent over the network) and relevant auditing tools (auditd, selinux, fapolicyd, etc.)

In addition w.r.t to the previous opened ticket, any documentation that mentions
az login --service-principal with a password provided on the command line is wrong and should be updated.

[MoChilia]

Hi frigo (@freedge), we recommend using OIDC or Managed Identity for login instead of using secrets to prevent leaks.

For measures you mentioned, unfortunately, azure-cli does not currently support using environment variables for authentication.

Jiashuo Li (@jiasli), could you please confirm if the following method helps prevent password leaks on the command line?

az login --service-principal -u $U --tenant $T -p @<(echo "$P")

[freedge]

we recommend using OIDC or Managed Identity for login instead of using secrets

indeed this is what is said on
https://learn.microsoft.com/en-us/cli/azure/azure-cli-sp-tutorial-2

it's however not mentioned https://learn.microsoft.com/en-us/cli/azure/authenticate-azure-cli-service-principal

to prevent leaks.

I don't think this reason is explained or mentioned in any documentation. The above link provides even an "important warning" supposedly improving security but still without any mention of it still leaking the password.

Could you put this recommendation (and its reasons) clearly in the documentation, to strongly discourage users to use service principal passwords? Could az login emit a warning everytime a user uses that feature since it's known to be insecure?

[MoChilia]

frigo (@freedge), as mentioned in https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#inputs

GitHub stores input parameters as environment variables.

Is it possible to retrieve the password in azure/login through a newfstatat system call?

The secret login method hasn't been proven to be insecure; it's just recommended to use the no-secret-login method, due to the risk of leaks when users manage their secrets.

[freedge]

for example if you cd into a directory mounted through nfs, and you run azure login -p, then the password will be sent in clear over the network, to the nfs server. So yes it is possible to retrieve the password.

The az login -p with a password is insecure since the password is visible to any user logged in on the system.

[MoChilia]

The GitHub-hosted runner is an ephemeral runner that exists only for the duration of a single job. Attacks of this appear to be invalid. This concern primarily pertains to self-hosted runners lacking proper management.

And it seems an issue for az login -p required to be solved in azure-cli. To address this issue, transferring it to azure-cli repo for now. If necessary, modifications to azure/login will be made accordingly.

[jiasli]

This is undocumented but it's possible to use instead a "@" so that the password is read from a file, eg in this fashion

We do have document for the @<file> convention: https://learn.microsoft.com/en-us/cli/azure/use-azure-cli-successfully#use-quotation-marks-in-parameters. Its implementation is at

azure-cli/src/azure-cli-core/azure/cli/core/commands/__init__.py

Lines 85 to 101 in c440784

	def _maybe_load_file(arg):
	ix = arg.find('@')
	if ix == -1: # no @ found
	return arg
	poss_file = arg[ix + 1:]
	if not poss_file: # if nothing after @ then it can't be a file
	return arg
	if ix == 0:
	try:
	return _load_file(poss_file)
	except IOError:
	logger.debug("Failed to load '%s', assume not a file", arg)
	return arg
	# if @ not at the start it can't be a file
	return arg

Not

azure-cli/src/azure-cli-core/azure/cli/core/auth/identity.py

Lines 285 to 286 in 246725e

	user_expanded = os.path.expanduser(secret_or_certificate)
	if os.path.isfile(user_expanded):

The logic here is for specifying a certificate file path, without @ prefix, such as

az login --service-principal -u $U --tenant $T -p /home/user1/mycert.pem

however it is still leaked in the newfstatat system call:

I am wondering why <(echo "$P") is logged in newfstatat - is it writing to or reading from the fd that results in the newfstatat system call? I think it is more about how Linux works internally, instead of Azure CLI's implementation. Can we repro this without Azrue CLI, such as

$ echo <(echo "aaa")
/dev/fd/63
$ cat <(echo "aaa")
aaa
$ python3 -c "import sys; print(sys.argv)" <(echo "aaa")
['-c', '/dev/fd/63']
$ python3 -c "import sys; print(open(sys.argv[1]).read(), end='')" <(echo "aaa")
aaa

frigo (@freedge), could you please share more details on how you captured this line?

15547 newfstatat(AT_FDCWD, "W3x..., 0x7fffe0296410, 0) = -1 ENOENT (No such file or directory)