-
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
cmd/compile: depth limit reached in type formatting routine #29312
Comments
Change https://golang.org/cl/154583 mentions this issue: |
A recursive type where we currently fail: type T interface {
M(interface {
T
})
} (from #16369). |
The formatting routines for types use a depth limit as primitive mechanism to detect cycles. For now, increase the limit from 100 to 250 and file #29312 so we don't drop this on the floor. Also, adjust some fatal error messages elsewhere to use better formatting. Fixes #29264. Updates #29312. Change-Id: Idd529f6682d478e0dcd2d469cb802192190602f6 Reviewed-on: https://go-review.googlesource.com/c/154583 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
#32547 is a test case that fails due to the recursion limit, although the test itself does not use recursion. It just uses a very very very deep pointer type. |
An update on this bug: At Google CTF finals this year a team was able to exploit this behavior and obtain remote code execution without importing any package except for "fmt". The issue is that some code that was supposedly safe had a memory corruption due to a very deep type. Here you can find a write up of the challenge, and here is the exploit. When there is a very deep type (253 in this case) the compiler generates an incorrect program. In my opinion this should not be the case and it should instead reject the invalid code (after all, the generated program will not work anyways). /cc @mvdan @FiloSottile |
Marking as a release blocker for 1.14. I don't see a reason to block the beta release for this. |
Is there a threat model in which this attack is possible but https://research.swtch.com/gorace isn’t? |
This exploit doesn't require multiple threads, unlike Russ' example. |
This bug has been there for quite a while and the threat model requires a lot of control on the attacker side (almost arbitrary code). I don't know if this is exploitable by creating the type via reflection but even if it is it would still require the attacker to call arbitrary primitives, which is unlikely. It would be nice to have this fixed for the next release but I would not say this is a blocker for 1.14. |
This is a classic type confusion and definitely a mis-compilation (as well as an amazing CTF trick). It also introduces unsafety which can't be detected by looking for usages of However, I believe we (rightfully) gave up on this threat model with the removal of "safe" mode in Go 1.12 (5185744), so I agree that this is not a security issue. |
/cc @randall77 @griesemer Please let us know when there are updates on this issue, as this is currently marked a release blocker for 1.14. |
Change https://golang.org/cl/213517 mentions this issue: |
This avoids the security problem in #29312 where two very deep, but distinct, types are given the same name. They both make it to the linker which chooses one, and the use of the other is now type unsafe. Instead, give every very deep type its own name. This errs on the other side, in that very deep types that should be convertible to each other might now not be. But at least that's not a security hole. Update #29312. Change-Id: Iac0ebe73fdc50594fd6fbf7432eef65f9a053126 Reviewed-on: https://go-review.googlesource.com/c/go/+/213517 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Robert Griesemer <gri@golang.org>
The security hole aspects of this issue have been fixed. Removing release blocker and punting to 1.15. |
Change https://golang.org/cl/214239 mentions this issue: |
Place holder issue for cases of overly deep types or (invalid) recursive types. See #29264 for an example.
The text was updated successfully, but these errors were encountered: