ovalutil: guard a test element with no object reference

[arpitjain099]

RPMDefsToVulns and DpkgDefsToVulns both do this:

objRefs := test.ObjectRef()
stateRefs := test.StateRef()
...
objRef := objRefs[0].ObjectRef

and then, a few lines further down, guard the sibling with if len(stateRefs) > 0. The comment above explains why the state reference is optional and the object reference is required, but "required by the schema" is not the same as "present in the document": goval-parser does not enforce it, so a test element with no <object> child parses fine and then indexes an empty slice.

panic: runtime error: index out of range [0] with length 0

That happens while unpacking criterions during an update, so a single malformed test element in a fetched OVAL feed takes down the updater rather than costing one vulnerability.

Both call sites now skip the criterion, which is what already happens when the object lookup itself fails. rpm.go logs at debug like the lookup failures around it; dpkg.go increments the existing stats.Obj counter, which is reported at the end of the run.

TestDefsToVulnsWithoutObjectRef parses a minimal OVAL document with the object reference omitted and runs both entry points over it. On the unmodified tree the rpminfo case panics and takes the test binary with it; with this change both return no vulnerabilities and no error. go test ./pkg/ovalutil/ passes.

[crozzy]

Thanks for the PR, curious; have you seen this in the wild?

[arpitjain099]

Honest answer: no, not from a production crash. I came at it from the other direction, reading the OVAL handling for places where a document shape that the spec permits is not one the code expects.

The specific shape is a <test> element with no <object> child. The OVAL definitions schema makes the object reference optional on some test types, so a feed can legally ship one, and ovalutil walks straight to the reference without checking. Nothing in Red Hat's or SUSE's current feeds looks like that as far as I can see, which is presumably why it has never bitten. It is more of a fail-safe against a malformed or truncated feed than a fix for something actively breaking.

So treat it as hardening rather than a bug report, and if that is not worth the diff I am fine with it being closed. The branch is behind main now, so tell me either way and I will rebase if you want it.

[crozzy]

Ahh, no I think it's good to include, just sometimes we see these PRs and have no context for how people are using claircore to produce the error.

I can also rebase.

[arpitjain099]

That makes sense, and it is a fair thing to ask. I have rebased it onto main so you do not have to.

For the record on how it turned up: I was reading the OVAL definitions schema for places where a document shape the spec permits is not one the code expects, rather than working back from a failure in a deployment. The specific shape is a <test> element with no <object> child, which the schema allows on some test types. So it is guarding against a malformed or truncated feed rather than something Red Hat or SUSE are shipping today.

go build ./... and go test ./pkg/ovalutil/... are clean on the rebased branch.