CVE-2024-3205

[hasufell]

Mandatory information:

• Package : https://hackage.haskell.org/package/libyaml-clib
• cvss: 3.1
• affected versions: all up to 0.2.5

Upstream discussion: yaml/libyaml#289

[frasertweedale]

@hasufell thank you for the report. I'll create a PR soon.

[hasufell]

There's no fix at the moment. At least none that is reviewed by the vendor.

[frasertweedale]

Oh I just mean the PR to the advisory DB, not the affected package itself 🙃

[hasufell]

Oh I just mean the PR to the advisory DB, not the affected package itself 🙃

Yes I know... just saying.

What do we tell people/maintainers now?

Afais, without an upstream patch, the only way to avoid it is to reject yaml flow style before passing it to the C parser. I doubt any library user can reasonably do that.

[frasertweedale]

It would help to see a plausible POC or example malicious payload, i.e. what are the characteristics of a malicious payload? That would assist in developing advice on possible mitigations.

[perlpunk]

Afais, without an upstream patch, the only way to avoid it is to reject yaml flow style before passing it to the C parser. I doubt any library user can reasonably do that.

It's not about the parser. I also don't know how to reproduce, but at least it seems clear that this is about the emitter when using the document loader / dumper.
The parser is safe here.

[hasufell]

To expand... from what I understand @perlpunk is still investigating whether this is a libyaml issue at all: yaml/libyaml#258

[perlpunk]

It is a libyaml issue, but yaml/libyaml#290 should mitigate it.
And the POP from the empty stack only happened when using canonical mode in the emitter, which is very rare.

[frasertweedale]

@hasufell revisiting this and requesting your input on what you want us to do.

We can file an advisory, to the effect of "there seems to be an issue, we don't know exactly how bad it is or how to exploit it, and the clib upstream is unresponsive, so we have no idea if/when it would be fixed". And, we will have a stab at the CVSS score. The advisory would not be particularly informative or actionable, except for dependent packages to migrate away (and there's a lot of those).

Or, because there does not seem to be a known plausible way to exploit it, we can wait and see until the situation becomes clearer. When the issue is clearer or the (presumed) fix is available and adopted, we can issue the advisory then.

Finally, if you want to integrate the fix into the bundled code yourself, we can publish the advisory with the fix version. Carrying downstream modifications is an unpleasant situation. But when upstream is unresponsive, it is a reasonable course. In this case we'd be happy to issue the advisory and indicate the fix version, but the CVSS and info about the vuln would still be mostly guesswork.

Whatever you prefer, SRT will do.

[hasufell]

the clib upstream is unresponsive

Upstream has reproduced the issue. They've also created a PR to fix it:

• Find heap buffer overflow by running fuzz test yaml/libyaml#258 (comment)
• Fix emitter states handling when write_indicator fails yaml/libyaml#290

So this seems to be legit.

[perlpunk]

I had a closer look at the libyaml and the fuzzer code and think there is nothing to exploit. see my comment here:
yaml/libyaml#258 (comment)

[perlpunk]

FYI: I'm currently trying to get the CVE rejected. Hopefully I contacted the right people.

[TristanCacqueray]

@perlpunk thank you for the updates.

[perlpunk]

The CVE is now rejected: https://www.cve.org/CVERecord?id=CVE-2024-3205

[TristanCacqueray]

Thanks for the followup. Please re-open if this is still relevant.

[frasertweedale]

@hasufell just want to confirm whether you are ok with this outcome?

[hasufell]

Sure