-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
runtime: unexpected behavior of setuid/setgid binaries [CVE-2023-29403] #60272
Comments
This is not a private issues, btw. :-) |
PRIVATE refers to the Go Security policy track for this issue. |
@gopherbot please open backport issues. |
Backport issue(s) opened: #60517 (for 1.19), #60518 (for 1.20). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases. |
Change https://go.dev/cl/501215 mentions this issue: |
Change https://go.dev/cl/501219 mentions this issue: |
Change https://go.dev/cl/501223 mentions this issue: |
Change https://go.dev/cl/501227 mentions this issue: |
Change https://go.dev/cl/501228 mentions this issue: |
On Unix platforms, the runtime previously did nothing special when a program was run with either the SUID or SGID bits set. This can be dangerous in certain cases, such as when dumping memory state, or assuming the status of standard i/o file descriptors. Taking cues from glibc, this change implements a set of protections when a binary is run with SUID or SGID bits set (or is SUID/SGID-like). On Linux, whether to enable these protections is determined by whether the AT_SECURE flag is passed in the auxiliary vector. On platforms which have the issetugid syscall (the BSDs, darwin, and Solaris/Illumos), that is used. On the remaining platforms (currently only AIX) we check !(getuid() == geteuid() && getgid == getegid()). Currently when we determine a binary is "tainted" (using the glibc terminology), we implement two specific protections: 1. we check if the file descriptors 0, 1, and 2 are open, and if they are not, we open them, pointing at /dev/null (or fail). 2. we force GOTRACKBACK=none, and generally prevent dumping of trackbacks and registers when a program panics/aborts. In the future we may add additional protections. This change requires implementing issetugid on the platforms which support it, and implementing getuid, geteuid, getgid, and getegid on AIX. Thanks to Vincent Dehors from Synacktiv for reporting this issue. Updates #60272 Fixes #60517 Fixes CVE-2023-29403 Change-Id: I057fa7153d29cf26515e7f49fed86e4f8bedd0f0 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1878434 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-by: Russ Cox <rsc@google.com> (cherry picked from commit 87065663ea6d89cd54f65a515d8f2ed0ef285c19) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1902231 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1904340 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/501228 Auto-Submit: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: David Chase <drchase@google.com>
On Unix platforms, the runtime previously did nothing special when a program was run with either the SUID or SGID bits set. This can be dangerous in certain cases, such as when dumping memory state, or assuming the status of standard i/o file descriptors. Taking cues from glibc, this change implements a set of protections when a binary is run with SUID or SGID bits set (or is SUID/SGID-like). On Linux, whether to enable these protections is determined by whether the AT_SECURE flag is passed in the auxiliary vector. On platforms which have the issetugid syscall (the BSDs, darwin, and Solaris/Illumos), that is used. On the remaining platforms (currently only AIX) we check !(getuid() == geteuid() && getgid == getegid()). Currently when we determine a binary is "tainted" (using the glibc terminology), we implement two specific protections: 1. we check if the file descriptors 0, 1, and 2 are open, and if they are not, we open them, pointing at /dev/null (or fail). 2. we force GOTRACKBACK=none, and generally prevent dumping of trackbacks and registers when a program panics/aborts. In the future we may add additional protections. This change requires implementing issetugid on the platforms which support it, and implementing getuid, geteuid, getgid, and getegid on AIX. Thanks to Vincent Dehors from Synacktiv for reporting this issue. Updates #60272 Fixes #60518 Fixes CVE-2023-29403 Change-Id: Icb620f3f8755791d51b02b5c07fb24f40e19cb80 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1878434 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-by: Russ Cox <rsc@google.com> (cherry picked from commit 87065663ea6d89cd54f65a515d8f2ed0ef285c19) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1902232 TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com> Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1904344 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/501227 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: David Chase <drchase@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
The Go runtime didn't act any differently when a binary had the setuid/setgid
bit set. On Unix platforms, if a setuid/setgid binary was executed with standard
I/O file descriptors closed, opening any files could result in unexpected
content being read/written with elevated prilieges. Similarly if a setuid/setgid
program was terminated, either via panic or signal, it could leak the contents
of its registers.
Thanks to Vincent Dehors from Synacktiv for reporting this issue.
This is a PRIVATE issue for CVE-2023-29403, tracked in http://b/280870635 and fixed by http://tg/1878434
/cc @golang/security and @golang/release
The text was updated successfully, but these errors were encountered: