v3: panic "attempted to parse unknown event (please report): none"

[bradleyjkemp]

Hi folks 👋🏻 Found this panic (along with #665) while fuzzing my own project.

Minimal example of the panic (https://play.golang.org/p/gLM_eHzcrgz):

package main

import (
	"gopkg.in/yaml.v3"
)

func main() {
	var t interface{}
	yaml.Unmarshal([]byte("0: [:!00 \xef"), &t)
}

Output:

panic: internal error: attempted to parse unknown event (please report): none [recovered]
	panic: internal error: attempted to parse unknown event (please report): none

goroutine 1 [running]:
gopkg.in/yaml%2ev3.handleErr(0xc000043f60)
	/tmp/gopath818249317/pkg/mod/gopkg.in/[email protected]/yaml.go:294 +0x85
panic(0x50f120, 0xc000010330)
	/usr/local/go-faketime/src/runtime/panic.go:969 +0x1b9
gopkg.in/yaml%2ev3.(*parser).parse(0xc000036c00, 0x0)
	/tmp/gopath818249317/pkg/mod/gopkg.in/[email protected]/decode.go:163 +0x277
gopkg.in/yaml%2ev3.(*parser).parseChild(...)
	/tmp/gopath818249317/pkg/mod/gopkg.in/[email protected]/decode.go:194
gopkg.in/yaml%2ev3.(*parser).sequence(0xc000036c00, 0xc00000e007)
	/tmp/gopath818249317/pkg/mod/gopkg.in/[email protected]/decode.go:259 +0xff
gopkg.in/yaml%2ev3.(*parser).parse(0xc000036c00, 0x0)
	/tmp/gopath818249317/pkg/mod/gopkg.in/[email protected]/decode.go:154 +0xe7
gopkg.in/yaml%2ev3.(*parser).parseChild(0xc000036c00, 0xc00007e3c0, 0xc00007e460)
	/tmp/gopath818249317/pkg/mod/gopkg.in/[email protected]/decode.go:194 +0x2f
gopkg.in/yaml%2ev3.(*parser).mapping(0xc000036c00, 0x9)
	/tmp/gopath818249317/pkg/mod/gopkg.in/[email protected]/decode.go:285 +0x1ad
gopkg.in/yaml%2ev3.(*parser).parse(0xc000036c00, 0xc000000003)
	/tmp/gopath818249317/pkg/mod/gopkg.in/[email protected]/decode.go:152 +0x10d
gopkg.in/yaml%2ev3.(*parser).parseChild(...)
	/tmp/gopath818249317/pkg/mod/gopkg.in/[email protected]/decode.go:194
gopkg.in/yaml%2ev3.(*parser).document(0xc000036c00, 0x3)
	/tmp/gopath818249317/pkg/mod/gopkg.in/[email protected]/decode.go:203 +0x8b
gopkg.in/yaml%2ev3.(*parser).parse(0xc000036c00, 0x0)
	/tmp/gopath818249317/pkg/mod/gopkg.in/[email protected]/decode.go:156 +0x87
gopkg.in/yaml%2ev3.unmarshal(0xc00002c590, 0xa, 0xa, 0x50a080, 0xc000010320, 0x0, 0x0, 0x0)
	/tmp/gopath818249317/pkg/mod/gopkg.in/[email protected]/yaml.go:161 +0x26a
gopkg.in/yaml%2ev3.Unmarshal(...)
	/tmp/gopath818249317/pkg/mod/gopkg.in/[email protected]/yaml.go:89
main.main()
	/tmp/sandbox604520862/prog.go:9 +0x99

[niemeyer]

Thanks for the report, I'll look into it.

[hasheddan]

As another data point, I found this occurs on invalid YAML that includes {{, which is common in manifests that are deployed with helm, such as this one.

[howardjohn]

repro.txt

Same issue with YAML above ^

[stevebeattie]

This issue was assigned CVE-2022-28948

[crenshaw-dev]

Issue 666. 😈

[crenshaw-dev]

For people who land here from Snyk: they incorrectly marked the vulnerability as being in v2. I've been unable to reproduce the issue in v2, and can only reproduce it in v3. I've notified Snyk of the error.

UPDATE: They fixed it!

UPDATE 2: For people who land here from the GitHub security advisory: they incorrectly marked the vulnerability as being in v2. Trying to find an appropriate version range to suggest...

[niemeyer]

Sorry for being slow. The post mortem is that long ago I was thrown off by an awkward API in the underlying library: it returns success (true) in error cases in that particular function call, while in general it does not. Instead of fixing the underlying API, we'll continue to tolerate it for the time being and handle the issue on the high-level decoder, so that it remains somewhat easy to compare the original libyaml logic to what remains of it in go-yaml.

[CityOfLight77]

@niemeyer @stevebeattie why this crash worth a CVE, and no severity?

[crenshaw-dev]

@CityOfLight77 it’s a CVE because a lot of apps use go-yaml. If a malicious user sends one of these payloads to such an app, they can shut down the app (Denial of Service).

Snyk assigned a severity of 7.5. The severity really depends on how your app uses go-yaml. If an unauthenticated user can send a malicious payload, then the severity is higher than it would be if they must be authenticated.

[CityOfLight77]

@CityOfLight77 it’s a CVE because a lot of apps use go-yaml. If a malicious user sends one of these payloads to such an app, they can shut down the app (Denial of Service).

Snyk assigned a severity of 7.5. The severity really depends on how your app uses go-yaml. If an unauthenticated user can send a malicious payload, then the severity is higher than it would be if they must be authenticated.

Thanks for the explanation

[benjifin]

@crenshaw-dev thanks for the heads up - we (Snyk) have updated our advisory now to only show versions of yaml v3 as vulnerable, and also included the fix advice released in v3.0.0. That should be live in an hour or so 🙏

[niemeyer]

Thanks all.

[codyoss]

For people who land here from Snyk: they incorrectly marked the vulnerability as being in v2. I've been unable to reproduce the issue in v2, and can only reproduce it in v3. I've notified Snyk of the error.

This seems to be correct from my testing too, maybe the OP could be edited to say there is no issue in v2 at the top. The GH advisory that came out on this is misleading people to upgrade I believe.

[crenshaw-dev]

@codyoss which GH SA? I'm not seeing one on this repo.

[ZiViZiViZ]

Issue 666 😈

[birobotond20]

Hi @crenshaw-dev, @niemeyer,
Is there any update on this, when can we expect a fix?

[ahrycej]

Could somebody help here: if go yaml version in use is v2.4.0 does it mean it is v2?
and v3.0.0 or v.3.0.1 is v3?

Getting above cve against v2.4.0 :/

[atc0005]

@ahrycej:

Could somebody help here: if go yaml version in use is v2.4.0 does it mean it is v2?
and v3.0.0 or v.3.0.1 is v3?

I believe the answer to your question is "yes".

Regarding how the versions map to which branches/series, see these pages for additional details:

• https://gopkg.in/yaml.v2
• https://labix.org/gopkg.in