My understanding of these functions from the docs is that they are supposed to fail gracefully on invalid input and don't require any prior validation.
Based on the stack trace in the PoC, the issue seems to be that the processing done in jws/message.go:UnmarshalJSON() assumes that if a signature field is present, then a protected field is also present. If this is not the case, then the subsequent call to getB64Value(sig.protected) will dereference sig.protected, which is nil.
$ go test
--- FAIL: TestPOC (0.00s)
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x40 pc=0x5fd618]
goroutine 6 [running]:
testing.tRunner.func1.2({0x628800, 0x831030})
/usr/local/go/src/testing/testing.go:1545 +0x238
testing.tRunner.func1()
/usr/local/go/src/testing/testing.go:1548 +0x397
panic({0x628800?, 0x831030?})
/usr/local/go/src/runtime/panic.go:914 +0x21f
github.com/lestrrat-go/jwx/v2/jws.getB64Value({0x0?, 0x0?})
/home/fredrik/go/pkg/mod/github.com/lestrrat-go/jwx/v2@v2.0.18/jws/jws.go:484 +0x18
github.com/lestrrat-go/jwx/v2/jws.(*Message).UnmarshalJSON(0xc0000a2140, {0xc0000ec000, 0x11, 0x200})
/home/fredrik/go/pkg/mod/github.com/lestrrat-go/jwx/v2@v2.0.18/jws/message.go:323 +0x4ad
encoding/json.(*decodeState).object(0xc0000ea028, {0x64fa60?, 0xc0000a2140?, 0x16?})
/usr/local/go/src/encoding/json/decode.go:604 +0x6cc
encoding/json.(*decodeState).value(0xc0000ea028, {0x64fa60?, 0xc0000a2140?, 0xc00006e630?})
/usr/local/go/src/encoding/json/decode.go:374 +0x3e
encoding/json.(*decodeState).unmarshal(0xc0000ea028, {0x64fa60?, 0xc0000a2140?})
/usr/local/go/src/encoding/json/decode.go:181 +0x133
encoding/json.(*Decoder).Decode(0xc0000ea000, {0x64fa60, 0xc0000a2140})
/usr/local/go/src/encoding/json/stream.go:73 +0x179
github.com/lestrrat-go/jwx/v2/internal/json.Unmarshal({0xc00001a288, 0x11, 0x11}, {0x64fa60, 0xc0000a2140})
/home/fredrik/go/pkg/mod/github.com/lestrrat-go/jwx/v2@v2.0.18/internal/json/json.go:26 +0x97
github.com/lestrrat-go/jwx/v2/jws.parseJSON({0xc00001a288, 0x11, 0x11})
/home/fredrik/go/pkg/mod/github.com/lestrrat-go/jwx/v2@v2.0.18/jws/jws.go:588 +0x50
github.com/lestrrat-go/jwx/v2/jws.Parse({0xc00001a288, 0x11, 0x11}, {0x0?, 0xc00006e760?, 0x48450f?})
/home/fredrik/go/pkg/mod/github.com/lestrrat-go/jwx/v2@v2.0.18/jws/jws.go:525 +0x89
poc.TestPOC(0x0?)
/home/fredrik/src/jwx_poc/poc_test.go:10 +0x57
testing.tRunner(0xc0000e4340, 0x68ef30)
/usr/local/go/src/testing/testing.go:1595 +0xff
created by testing.(*T).Run in goroutine 1
/usr/local/go/src/testing/testing.go:1648 +0x3ad
exit status 2
FAIL poc 0.005s
The vulnerability can be used to crash / DOS a system doing JWS verification.
Summary
Calling
jws.Parsewith a JSON serialized payload where thesignaturefield is present whileprotectedis absent can lead to a nil pointer dereference.Details
This seems to also affect other functions that calls
Parseinternally, likejws.Verify.My understanding of these functions from the docs is that they are supposed to fail gracefully on invalid input and don't require any prior validation.
Based on the stack trace in the PoC, the issue seems to be that the processing done in
jws/message.go:UnmarshalJSON()assumes that if asignaturefield is present, then aprotectedfield is also present. If this is not the case, then the subsequent call togetB64Value(sig.protected)will dereferencesig.protected, which isnil.PoC
Reproducer:
Result:
Impact
The vulnerability can be used to crash / DOS a system doing JWS verification.