How is this CVE-2024-35329 affected?

[alittlesir]

https://nvd.nist.gov/vuln/detail/CVE-2024-35329

[frenzymadness]

It seems libyaml is affected. The reproducer provided in the CVE report works and leads to a memory leak so the issue is reproducible.

[perlpunk]

I never saw an issue about that here.
But I went to the link and looked at the code:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <yaml.h>

void poc() {
    yaml_document_t document;
    memset(&document, 0, sizeof(yaml_document_t));
    yaml_char_t *anchor = "rsslab";
    yaml_char_t *tag = "tag:yaml.org,2002:str";
    int style = YAML_ANY_SEQUENCE_STYLE;
    yaml_document_add_sequence(&document, tag, style);
}

int main(int argc, char *argv[])
{
    printf("heap-buffer-overflow on libyaml/src/api.c:1274:10\n");
    poc();
    return 0;
}

So yeah, if you do strange things, then strange things happen.
What is the purpose of this code?

It can be fixed like that:

    yaml_document_t document;
    memset(&document, 0, sizeof(yaml_document_t));
    if (!yaml_document_initialize(&document, NULL, NULL, NULL, 0, 0))
        return;
    yaml_char_t *anchor = "rsslab";
    yaml_char_t *tag = "tag:yaml.org,2002:str";
    int style = YAML_ANY_SEQUENCE_STYLE;
    yaml_document_add_sequence(&document, tag, style);

    yaml_document_delete(&document);

You have to call yaml_document_initialize, and you have to call yaml_document_delete at the end.

[perlpunk]

I am not sure how that is something to exploit. If you find code out there that does this then the code is broken and won't work anyway. I will reject the CVE.
This is costing me time. If there is a way to exploit, then please create a private security report and describe it in detail, I really can't see the problem here. pinging @idhyt because this is from them, see #297 and https://github.com/idhyt/pocs/tree/main/libyaml

[frenzymadness]

Thank you for the quick clarification! I don't have enough knowledge of the codebase here so if you say the reproducer is actually a broken piece of code, I trust you. The CVE has to be therefore rejected but you are the only one who can request that I guess.

[perlpunk]

I contacted Vuldb to reject it and also complained about a missing report before disclosure.

[perlpunk]

Vuldb replied that mitre.org is responsible for this one sigh so I filled out their contact form.
It seems to be easy to create a CVE, but it is made hard for maintainers to reject them.

[idhyt]

@perlpunk

I have responded to all in #297 about this series issue，and have terminated all remaining reports, you can reject them, sorry for the trouble :)

[perlpunk]

Some more detailed thoughts.
In order to call something a CVE, I would at least need to see a program that does something useful and works.
So let's look at a minimal program:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <yaml.h>

int main(int argc, char *argv[])
{
    yaml_emitter_t emitter;
    yaml_document_t document;
    memset(&document, 0, sizeof(yaml_document_t));
    if (!yaml_document_initialize(&document, NULL, NULL, NULL, 0, 0)) return;

    fprintf(stderr, "yaml_emitter_initialize\n");
    if (!yaml_emitter_initialize(&emitter)) return;

    fprintf(stderr, "yaml_document_add_sequence\n");
    yaml_char_t *tag = "tag:yaml.org,2002:str";
    int style = YAML_ANY_SEQUENCE_STYLE;
    yaml_document_add_sequence(&document, tag, style);

    fprintf(stderr, "yaml_emitter_set_output_file\n");
    yaml_emitter_set_output_file(&emitter, stdout);
    fprintf(stderr, "yaml_emitter_open\n");
    yaml_emitter_open(&emitter);
    fprintf(stderr, "yaml_emitter_dump\n");
    if (!yaml_emitter_dump(&emitter, &document)) return;
//    yaml_document_delete(&document);
}

Running this I get:

yaml_emitter_initialize
yaml_document_add_sequence
yaml_emitter_set_output_file
yaml_emitter_open
yaml_emitter_dump
--- !!str []
...

Now I remove the yaml_document_initialize:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <yaml.h>

int main(int argc, char *argv[])
{
    yaml_emitter_t emitter;
    yaml_document_t document;
    memset(&document, 0, sizeof(yaml_document_t));
//    if (!yaml_document_initialize(&document, NULL, NULL, NULL, 0, 0)) return;

    fprintf(stderr, "yaml_emitter_initialize\n");
    if (!yaml_emitter_initialize(&emitter)) return;

    fprintf(stderr, "yaml_document_add_sequence\n");
    yaml_char_t *tag = "tag:yaml.org,2002:str";
    int style = YAML_ANY_SEQUENCE_STYLE;
    yaml_document_add_sequence(&document, tag, style);

    fprintf(stderr, "yaml_emitter_set_output_file\n");
    yaml_emitter_set_output_file(&emitter, stdout);
    fprintf(stderr, "yaml_emitter_open\n");
    yaml_emitter_open(&emitter);
    fprintf(stderr, "yaml_emitter_dump\n");
    if (!yaml_emitter_dump(&emitter, &document)) return;
//    yaml_document_delete(&document);
}

and I get:

yaml_emitter_initialize
yaml_document_add_sequence
yaml_emitter_set_output_file
yaml_emitter_open
yaml_emitter_dump
malloc(): corrupted top size
[1]    12219 IOT instruction (core dumped)  ./tests/run-emitter-test-suite

So this program is not working at all, so I doubt any app out there has code like this running that one could somehow exploit.
If the code can be improved to avoid the buffer overflow and return an error instead, like #299 (which seems to be a proof of concept), then sure, that should be considered. But the V in CVE stands for vulnerability.

[frenzymadness]

Hmm, it seems somebody focused on libyaml and filled 3 more CVEs:

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-35325 with PoC: https://github.com/idhyt/pocs/blob/main/libyaml/CVE-2024-35325.c
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-35326 with PoC: https://github.com/idhyt/pocs/blob/main/libyaml/CVE-2024-35326.c
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-35328 with PoC: https://github.com/idhyt/pocs/blob/main/libyaml/CVE-2024-35328.c

Do you want to open new issues for them so we can tackle them individually?

[hasufell]

There's something seriously wrong with the CVE process if maintainers are not contacted prior to disclosure.

@frasertweedale do you know who to contact for breaches of process?

[perlpunk]

I guess I got @idhyt wrong, so I have to reject all four :(

So CVE-2024-35326 , CVE-2024-35328 and this one here are very similar in that they all skip the call to initialize a struct.
This means that the memory will just contain garbage, and in a full program any operations on them will likely result in an error like malloc(): corrupted top size. So a program like this just doesn't work, and the contrived examples are doing nothing useful, so there shouldn't be anything out there that can be exploited.

[frasertweedale]

There's something seriously wrong with the CVE process if maintainers are not contacted prior to disclosure.

@frasertweedale do you know who to contact for breaches of process?

CVE is just a numbering system. Blocks of IDs are assigned to CVE Numbering Authorities (CNAs) - typically large software vendors or security research orgs. Each CNA has their own procedures and expectations.

These CVEs were assigned by MITRE, a "CNA of last resort". Anyone can request a CVE and they will assign it. A reference to a public POC or evidence of the issue is sufficient to make the details public. Disclosing without first contacting the vendor/maintainer is poor form, but it happens a lot and there is no real means of recourse.

[idhyt]

@perlpunk
@hasufell
@frasertweedale
@frenzymadness
@zhuofeng6
@mmz-zmm
@...

我不希望再占用公共资源，关于这几个问题我最后做一次解释：

1. 发现这些问题的过程，就像在#297中所说，我在使用rust进行开发时候，需要解析yaml文件，因此我引入了 serde_yaml 库，当我进行编译时候，发现了该库依赖了unsafe-libyaml，在rust中使用 unsafe 需要非常谨慎，因此我最终找到了这个项目，我对这个项目的API和部分实现代码进行了大致阅读，发现了其实现过程中存在多处缺陷，并且在rust中复现了这些问题，见 poc。

2. 关于披露流程问题，起初我在这个项目中提了issue(double-free on yaml_event_delete api #297)，两周过去了没有任何人进行回复，随后我在问题下边也说明了，我将公开所有问题。 同时，我在评估了风险以后（最新的一个版本已经过去4年），放弃了 serde_yaml 并使用了serde_toml 进行替代，并将已经编写4的poc公开，随后作者回复了我的issue，由于公开时间我无法控制，因此存在了关于#297问题下的争议，此时，我已经终止提交了所有未公开的问题，不会再有新的披露了。 在#297下 @Martchus 提醒了我，不应该向开源维护者施压，这个确实是我没有考虑的问题，我为此表示抱歉，我确实希望这些问题能够尽快的得到回应（我在开发过程中确实需要这个库）。

3. 关于漏洞与否的争议，我想说的是，漏洞能否被利用是一个非常主观的事情，依赖于个人的技术水平和使用环境，历史上有很多非常典型的案例，如CVE-2015-1805曾经一度认为无法利用的漏洞，在几年以后被用作通用的提权工具，站在不同的开发者的角度，对代码缺陷（或者漏洞）的容忍度不同，因此我保留我的观点，也尊重作者的意见，可以将已公开的4个poc拒绝掉。

4. 最后我想再多说一点，这些问题仅仅是我开发过程中的一次意外，如果是个人仓库(影响范围有限)，我可能不会反馈这些问题，或者换一个库来使用，但是，当我在 snyk 查询了这个项目的历史漏洞，发现其影响范围已经超出了我的预期，这个项目作为一个公共库，影响的开源组件和操作系统非常广泛（超过200+），
   其代码实现中的缺陷导致我不得不放弃yaml解析库，改用toml库，这些代码缺陷影响的不仅仅是我个人，yaml作为被广泛使用的文件类型，基本影响了大部分的开发者，请重视这些问题。

5. 我不会再对此问题作出回应，抱歉占用了公共资源，给大家带来的困扰我非常抱歉，如有其他问题，非常欢迎随时与我邮件进行沟通。