Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

os: windows processes started with foreign token inherit the wrong environment [CVE-2019-11888] #32000

Closed
zx2c4 opened this issue May 13, 2019 · 7 comments

Comments

@zx2c4
Copy link
Contributor

@zx2c4 zx2c4 commented May 13, 2019

Passing a nil environment but a non-nil token to os.CreateProcess results in the new potentially unprivileged process inheriting the parent potentially privileged environment, or results in the new potentially privileged process inheriting the parent potentially unprivileged environment. In the former case, it's an infoleak. In the latter case, it's a possible EoP, since things like PATH could be overwritten.

@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented May 13, 2019

Change https://golang.org/cl/176619 mentions this issue: os: pass correct environment when creating Windows processes

@bradfitz

This comment has been minimized.

Copy link
Contributor

@bradfitz bradfitz commented May 13, 2019

@gopherbot gopherbot closed this in 12279fa May 16, 2019
@zx2c4

This comment has been minimized.

Copy link
Contributor Author

@zx2c4 zx2c4 commented May 16, 2019

Should probably backport this.

@zx2c4

This comment has been minimized.

Copy link
Contributor Author

@zx2c4 zx2c4 commented May 16, 2019

@gopherbot Please open a backport to 1.12.

@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented May 16, 2019

Backport issue(s) opened: #32081 (for 1.12).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented May 16, 2019

Change https://golang.org/cl/177538 mentions this issue: [release-branch.go1.12] os: pass correct environment when creating Windows processes

gopherbot pushed a commit that referenced this issue May 17, 2019
…ndows processes

This is CVE-2019-11888.

Previously, passing a nil environment but a non-nil token would result
in the new potentially unprivileged process inheriting the parent
potentially privileged environment, or would result in the new
potentially privileged process inheriting the parent potentially
unprivileged environment. Either way, it's bad. In the former case, it's
an infoleak. In the latter case, it's a possible EoP, since things like
PATH could be overwritten.

Not specifying an environment currently means, "use the existing
environment". This commit amends the behavior to be, "use the existing
environment of the token the process is being created for." The behavior
therefore stays the same when creating processes without specifying a
token. And it does the correct thing when creating processes when
specifying a token.

Updates #32000
Fixes #32081

Change-Id: Ib4a90cfffb6ba866c855f66f1313372fdd34ce41
Reviewed-on: https://go-review.googlesource.com/c/go/+/177538
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
LiamHaworth added a commit to LiamHaworth/go that referenced this issue Feb 24, 2020
Builds upon the changes from golang#32000 which supported sourcing environment
variables for a new process from the environment of a Windows user token
when supplied.

But due to the logic of `os/exec`, the `Env` field of a process was
always non-nil when it reached that change.

This change moves the logic up to `os/exec`, specifically when
`os.ProcAttr` is being built for the `os.StartProcess` call, this
ensures that if a user token has been supplied and no `Env` slice has
been provided on the command it will be sourced from the user's
environment.

If no token is provided, or the program is compiled for any other
platform than Windows, the default environment will be sourced from
`syscall.Environ()`.

Fixes golang#35314
LiamHaworth added a commit to LiamHaworth/go that referenced this issue Feb 24, 2020
Builds upon the changes from golang#32000 which supported sourcing environment
variables for a new process from the environment of a Windows user token
when supplied.

But due to the logic of `os/exec`, the `Env` field of a process was
always non-nil when it reached that change.

This change moves the logic up to `os/exec`, specifically when
`os.ProcAttr` is being built for the `os.StartProcess` call, this
ensures that if a user token has been supplied and no `Env` slice has
been provided on the command it will be sourced from the user's
environment.

If no token is provided, or the program is compiled for any other
platform than Windows, the default environment will be sourced from
`syscall.Environ()`.

Fixes golang#35314
LiamHaworth added a commit to LiamHaworth/go that referenced this issue Feb 24, 2020
Builds upon the changes from golang#32000 which supported sourcing environment
variables for a new process from the environment of a Windows user token
when supplied.

But due to the logic of os/exec, the Env field of a process was
always non-nil when it reached that change.

This change moves the logic up to os/exec, specifically when
os.ProcAttr is being built for the os.StartProcess call, this
ensures that if a user token has been supplied and no Env slice has
been provided on the command it will be sourced from the user's
environment.

If no token is provided, or the program is compiled for any other
platform than Windows, the default environment will be sourced from
syscall.Environ().

Fixes golang#35314
@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Feb 24, 2020

Change https://golang.org/cl/220587 mentions this issue: os/exec: use environment variables for user token when present

LiamHaworth added a commit to LiamHaworth/go that referenced this issue Feb 25, 2020
Builds upon the changes from golang#32000 which supported sourcing environment
variables for a new process from the environment of a Windows user token
when supplied.

But due to the logic of os/exec, the Env field of a process was
always non-nil when it reached that change.

This change moves the logic up to os/exec, specifically when
os.ProcAttr is being built for the os.StartProcess call, this
ensures that if a user token has been supplied and no Env slice has
been provided on the command it will be sourced from the user's
environment.

If no token is provided, or the program is compiled for any other
platform than Windows, the default environment will be sourced from
syscall.Environ().

Fixes golang#35314
gopherbot pushed a commit that referenced this issue Feb 25, 2020
Builds upon the changes from #32000 which supported sourcing environment
variables for a new process from the environment of a Windows user token
when supplied.

But due to the logic of os/exec, the Env field of a process was
always non-nil when it reached that change.

This change moves the logic up to os/exec, specifically when
os.ProcAttr is being built for the os.StartProcess call, this
ensures that if a user token has been supplied and no Env slice has
been provided on the command it will be sourced from the user's
environment.

If no token is provided, or the program is compiled for any other
platform than Windows, the default environment will be sourced from
syscall.Environ().

Fixes #35314

Change-Id: I4c1722e90b91945eb6980d5c5928183269b50487
GitHub-Last-Rev: 32216b7
GitHub-Pull-Request: #37402
Reviewed-on: https://go-review.googlesource.com/c/go/+/220587
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.