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

cmd/compile: depth limit reached in type formatting routine #29312

Open
griesemer opened this issue Dec 17, 2018 · 9 comments
Open

cmd/compile: depth limit reached in type formatting routine #29312

griesemer opened this issue Dec 17, 2018 · 9 comments
Assignees
Milestone

Comments

@griesemer
Copy link
Contributor

@griesemer griesemer commented Dec 17, 2018

Place holder issue for cases of overly deep types or (invalid) recursive types. See #29264 for an example.

@griesemer griesemer added this to the Unplanned milestone Dec 17, 2018
@griesemer griesemer self-assigned this Dec 17, 2018
@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Dec 17, 2018

Change https://golang.org/cl/154583 mentions this issue: cmd/compile: increase nesting depth limit for type descriptors

@griesemer griesemer modified the milestones: Unplanned, Go1.13 Dec 17, 2018
@griesemer

This comment has been minimized.

Copy link
Contributor Author

@griesemer griesemer commented Dec 17, 2018

A recursive type where we currently fail:

type T interface {
	M(interface {
		T
	})
}

(from #16369).

gopherbot pushed a commit that referenced this issue Dec 18, 2018
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>
@griesemer griesemer modified the milestones: Go1.13, Go1.14 May 6, 2019
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jun 11, 2019

#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.

@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
@empijei

This comment has been minimized.

Copy link
Contributor

@empijei empijei commented Dec 10, 2019

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

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Dec 10, 2019

Marking as a release blocker for 1.14.

I don't see a reason to block the beta release for this.

@josharian

This comment has been minimized.

Copy link
Contributor

@josharian josharian commented Dec 10, 2019

Is there a threat model in which this attack is possible but https://research.swtch.com/gorace isn’t?

@randall77

This comment has been minimized.

Copy link
Contributor

@randall77 randall77 commented Dec 10, 2019

This exploit doesn't require multiple threads, unlike Russ' example.
We've tried to keep Go strongly type safe in the absence of unsafe and data races. This exploit breaks that idea.

@empijei

This comment has been minimized.

Copy link
Contributor

@empijei empijei commented Dec 11, 2019

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.

@FiloSottile

This comment has been minimized.

Copy link
Member

@FiloSottile FiloSottile commented Dec 11, 2019

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 unsafe or by the race detector. It sounds like something we should fix.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.