-
Notifications
You must be signed in to change notification settings - Fork 314
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How is this CVE-2024-35329 affected? #298
Comments
It seems libyaml is affected. The reproducer provided in the CVE report works and leads to a memory leak so the issue is reproducible. |
I never saw an issue about that here.
So yeah, if you do strange things, then strange things happen. It can be fixed like that:
You have to call |
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. |
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. |
I contacted Vuldb to reject it and also complained about a missing report before disclosure. |
Vuldb replied that mitre.org is responsible for this one sigh so I filled out their contact form. |
This patch adds a new macro STACK_NULL to check if given stack was initialized, in order to fix yaml#298, which is CVE-2024-35329. The root cause is stack(document->nodes) was used before initialized, so check stack before push. According to the poc in [1], building it with `gcc poc.c -o poc -lyaml -fsanitize=address` Before this patch, the output is: [root@test yaml-0.2.5]# ./poc heap-buffer-overflow on libyaml/src/api.c:1274:10 ================================================================= ==3867981==ERROR: LeakSanitizer: detected memory leaks Direct leak of 64 byte(s) in 1 object(s) allocated from: #0 0x7f571f6af1a7 in __interceptor_malloc (/usr/lib64/libasan.so.6+0xaf1a7) yaml#1 0x7f5720127ac9 in yaml_document_add_sequence /root/libxml/yaml-0.2.5/src/api.c:1271 Direct leak of 22 byte(s) in 1 object(s) allocated from: #0 0x7f571f659707 in strdup (/usr/lib64/libasan.so.6+0x59707) yaml#1 0x7f5720127ab7 in yaml_document_add_sequence /root/libxml/yaml-0.2.5/src/api.c:1268 Direct leak of 1 byte(s) in 1 object(s) allocated from: #0 0x7f571f6af1a7 in __interceptor_malloc (/usr/lib64/libasan.so.6+0xaf1a7) yaml#1 0x7f5720125762 in yaml_stack_extend /root/libxml/yaml-0.2.5/src/api.c:126 SUMMARY: AddressSanitizer: 87 byte(s) leaked in 3 allocation(s). After this patch, there are no memory leaks warnnings. [1] https://drive.google.com/file/d/1xgQ9hJ7Sn5RVEsdMGvIy0s3b_bg3Wyk-/view?usp=sharing Signed-off-by: Zhao Mengmeng <[email protected]>
Some more detailed thoughts.
Running this I get:
Now I remove the
and I get:
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. |
This patch adds a new macro STACK_NULL to check if given stack was initialized, in order to fix yaml#298, which is CVE-2024-35329. The root cause is stack(document->nodes) was used before initialized, so check stack before push. According to the poc in [1], building it with `gcc poc.c -o poc -lyaml -fsanitize=address` Before this patch, the output is: [root@test yaml-0.2.5]# ./poc heap-buffer-overflow on libyaml/src/api.c:1274:10 ================================================================= ==3867981==ERROR: LeakSanitizer: detected memory leaks Direct leak of 64 byte(s) in 1 object(s) allocated from: #0 0x7f571f6af1a7 in __interceptor_malloc (/usr/lib64/libasan.so.6+0xaf1a7) yaml#1 0x7f5720127ac9 in yaml_document_add_sequence /root/libxml/yaml-0.2.5/src/api.c:1271 Direct leak of 22 byte(s) in 1 object(s) allocated from: #0 0x7f571f659707 in strdup (/usr/lib64/libasan.so.6+0x59707) yaml#1 0x7f5720127ab7 in yaml_document_add_sequence /root/libxml/yaml-0.2.5/src/api.c:1268 Direct leak of 1 byte(s) in 1 object(s) allocated from: #0 0x7f571f6af1a7 in __interceptor_malloc (/usr/lib64/libasan.so.6+0xaf1a7) yaml#1 0x7f5720125762 in yaml_stack_extend /root/libxml/yaml-0.2.5/src/api.c:126 SUMMARY: AddressSanitizer: 87 byte(s) leaked in 3 allocation(s). After this patch, there are no memory leaks warnnings. [1] https://drive.google.com/file/d/1xgQ9hJ7Sn5RVEsdMGvIy0s3b_bg3Wyk-/view?usp=sharing Signed-off-by: Zhao Mengmeng <[email protected]>
Hmm, it seems somebody focused on libyaml and filled 3 more CVEs:
Do you want to open new issues for them so we can tackle them individually? |
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? |
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. |
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. |
@perlpunk 我不希望再占用公共资源,关于这几个问题我最后做一次解释:
|
Translation via DeepL:
|
Adding translation:
@idhyt you reported the issues but the maintainer was unresponsive. In that case disclosure is the proper thing to do. All is well with that. From POV of Haskell Advisory Database, without a PoC or a clear way to exploit the issue, or an patch to the upstream that resolves the issue, it is debatable whether issuing an advisory actually helps. We are thankful that bugs (whether expoitable or not) get reported and discussed, and hope that widely used libraries are actively and sustainable maintained. If the upstream fixes the issue, we can issue an advisory, with the effect that users of versions containing the bug should be encouraged to upgrade. |
no, no, no. |
I misunderstood, and did not intend to spread wrong information. Let's get back to the issues in the code - whether they be considered vulnerabilities or not. What is the next step? Will there be an unstream release to fix those issues? |
I'm still not sure if a fix is needed, because without initializing the structure the program can't work anyway. #299 is a start for one of the three issues, but I was playing with it and there seem to be more functions that would need the check. #297 instead is something that can happen in an otherwise valid program, but I'm not sure what to do about that without changing the struct. And also there is no known exploit yet. |
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: 6fc627e32f03139530253845737d41fbfcb42cb9) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: 5d4ded9df654c8ba1f1a78f7a9d5ac69137b4f6a) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: 56758973faf04dfb302ae083baade0c9c497d223) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: ae03fed5cec40f491d67710a9c2175a2d7a32ac2) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: ae03fed5cec40f491d67710a9c2175a2d7a32ac2) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: ae03fed5cec40f491d67710a9c2175a2d7a32ac2) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: ae03fed5cec40f491d67710a9c2175a2d7a32ac2) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: ae03fed5cec40f491d67710a9c2175a2d7a32ac2) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: ae03fed5cec40f491d67710a9c2175a2d7a32ac2) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: 0632d739fd6bae33f9e58681e117b906a947a307) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: 0632d739fd6bae33f9e58681e117b906a947a307) Signed-off-by: Peter Marko <peter.markosiemens.com> Signed-off-by: Richard Purdie <richard.purdielinuxfoundation.org>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: 0632d739fd6bae33f9e58681e117b906a947a307) Signed-off-by: Peter Marko <peter.markosiemens.com> Signed-off-by: Richard Purdie <richard.purdielinuxfoundation.org>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: 63445474e797967578f5e9dc9eff3642ebe44712) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: 45bc0e87a6c7fb030480b9350413436e3bd14ccf) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: 63445474e797967578f5e9dc9eff3642ebe44712) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: 18e011245dd978985eecc368c503822f61d52f21) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: 2b6391599a621e59d48da213f18bbef9b44bec58) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: 18e011245dd978985eecc368c503822f61d52f21) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: 2b6391599a621e59d48da213f18bbef9b44bec58) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: 0632d739fd6bae33f9e58681e117b906a947a307) Signed-off-by: Peter Marko <peter.markosiemens.com> Signed-off-by: Richard Purdie <richard.purdielinuxfoundation.org>
Source: poky MR: 158530, 154823, 158408 Type: Security Fix Disposition: Merged from poky ChangeID: b84f6ed Description: This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: 2b6391599a621e59d48da213f18bbef9b44bec58) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Steve Sakoman <[email protected]> Signed-off-by: Jeremy A. Puhlman <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: 18e011245dd978985eecc368c503822f61d52f21) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: 18e011245dd978985eecc368c503822f61d52f21) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: 18e011245dd978985eecc368c503822f61d52f21) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
This is the same problem as already ignored CVE-2024-35328. See laso this comment in addition: yaml/libyaml#298 (comment) (From OE-Core rev: 18e011245dd978985eecc368c503822f61d52f21) Signed-off-by: Peter Marko <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
https://nvd.nist.gov/vuln/detail/CVE-2024-35329
The text was updated successfully, but these errors were encountered: