os: windows processes started with foreign token inherit the wrong environment [CVE-2019-11888] #32000
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
OS-Windows
Security
Comments
|
Change https://golang.org/cl/176619 mentions this issue: |
bradfitz
added
NeedsInvestigation
|
Should probably backport this. |
|
@gopherbot Please open a backport to 1.12. |
|
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. |
|
Change https://golang.org/cl/177538 mentions this issue: |
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>
|
Change https://golang.org/cl/220587 mentions this issue: |
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>
|
Change https://golang.org/cl/226280 mentions this issue: |
|
Change https://golang.org/cl/226281 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Mar 29, 2020
…oken when present 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(). For #35314 Fixes #37471 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> (cherry picked from commit e0c3ded) Reviewed-on: https://go-review.googlesource.com/c/go/+/226281
gopherbot
pushed a commit
that referenced
this issue
Mar 29, 2020
…oken when present 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(). For #35314 Fixes #37433 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> Reviewed-on: https://go-review.googlesource.com/c/go/+/226280
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Passing a nil environment but a non-nil token to
os.CreateProcessresults 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.The text was updated successfully, but these errors were encountered: