IssueTracker

For the purposes of the security group, there was a question over whether this issue deserves a CVE. The issue is already in the open so there isn't a need to embargo the content.

In the issue my instinctive reaction is that this isn't worth a CVE, although thinking it through I'm not entirely sure about that. To exploit this an attacker would need to find a function affected by this bug and find a way of calling it with a pointer to their destination. I think this would need to be an untested function as in most cases this bug would cause the program to crash or do something detectable.

In most programs I expect some other kind of successful attack to be mounted in order to get enough control over R0 to branch to where they want to go, otherwise if all they can do is call the function then they could have a denial of service attack.

The main question is whether this is CVE worthy? I think that would be possible if this introduces a significant new attack vector that didn't exist before. I'm on the fence with this as I think it would likely need another attack to gain enough control of R0. However as a leaf function this wouldn't be protected by most security mitigations so it could reveal a JOP attack that didn't exist before.

If a CVE is raised the description of programs potentially affected is wide, for example leaf functions that have more than one exit compiled with sufficient optimisation to enable shrink-wrapping, which would be pretty much every program compiled with O2 and above (including Os and Oz). A CVE for this would mean that the compiler would be unusable for some. This would also likely be a release blocking bug for LLVM 18.

I think that if a fix can be made and backported to the LLVM 18 release branch then I'm inclined to say no as most distros will pick up numbered releases.

Would like to hear other opinions.

Dear community,


I believe it is necessary to propose issuing a CVE for this problem.

The severity of the bug is significant, as it has the potential to expose users to security risks when utilizing the affected compiler.
This bug could result in the generation of vulnerable binary code, which may be exploited by malicious actors.

In general, such kind of vulnerability may be easily identified directly from binaries.

By assigning a CVE to this bug, we can ensure transparency and accountability in the handling of security vulnerabilities within the LLVM/Clang ecosystem.
This will enable affected users and organizations to promptly assess their exposure and implement necessary measures to mitigate the risk.

As I can see, a solution for this issue has already been prepared and committed.
After reviewing the fixed version of Clang, we can conclude that the issue has been resolved (at least on the "main" branch).
Issuing a CVE will facilitate communication and collaboration among security researchers, developers, and users, thereby strengthening the overall security posture of Clang compiler.

Your attention to this matter is greatly appreciated.

Thank you for your prompt review.


Best regards,
Victor Signaevskyi

IIUC, this compiler bug basically introduces potentially one more ROP gadget in the binary code for each shrink-wrapped function?
(I think this is a ROP gadget, rather than a JOP gadget, given that the attacker-controlled control flow change would be initiated by a return instruction going to an unintended location, rather than an indirect branch/jump?)

When security hardening features to harden against ROP exploits are not being used, there will be plenty of ROP gadgets in generated code. How would this one/few extra gadgets meaningfully change the ability of an attacker to exploit the binary?

Orthogonal to the above, I think there are 2 more observations that make it unclear if a CVE should be raised for this:
1) So far, we have not created CVEs for any issues from the LLVM security group. Maybe we should change that? But would this issue be an appropriate one to start the process with?
2) I have seen strong differences of opinion in the past about whether to raise CVEs for issues that requires other security issues to exist before they become exploitable. I'm assuming this strong difference of opinion would also apply here.

@krist...@arm.com

> I think this is a ROP gadget, rather than a JOP gadget, given that the attacker-controlled control flow change would be initiated by a return instruction

Let me note that this problem is more related to JOP rather than ROP.
Please check the generated code:
```
    add lr, r1, #8
    ...
    bx  lr
```

As it can be seen, finally it calls "bx" (branch/jump type instruction) and in general not for "lr" register but for "r1".

Please note, that in terms of control flow:
- JOP attacks rely on indirect jumps to gadgets. The attacker manipulates the program's data, such as function pointers or the return address on the stack, to point to the desired gadgets.
- ROP attacks primarily rely on return instructions. The attacker constructs a series of return addresses on the stack, each pointing to a different gadget, effectively chaining together a sequence of instructions to achieve their goal.


>
> How would this one/few extra gadgets meaningfully change the ability of an attacker to exploit the binary?
>

Very easy. Imagine a function argument that is officially controlled by the user input.

I still believe it's important to report this vulnerability using CVE.

It could really affect users and systems (in security terms).
If we issue a CVE, users will know about the problem and can understand the risks better and prevent them.
Imho, being honest about this is crucial for keeping users' trust.

Just think, if we don't report it and it gets used in a big attack later, we'll regret not doing it now.

So, I really think the LLVM/Clang team should publish a CVE.
It shows we care about security and our users' safety.

If no one disagrees, I can report the CVE myself (via CVE Numbering Authority).
If it's not a problem I think they will discard it by their side.

The LLVM security group is currently not set up to create CVEs, so we will not be creating a CVE for this issue.

That being said, we don't have strong objections for a CVE to be created by someone for this issue.

It does seem that the likelihood of this miscompile enabling an exploit remains very low, because the miscompile resulting in this JOP gadget is such that the function is most likely to crash on most valid inputs to the function. So, if this function is covered by any testing, the miscompile is most likely to be discovered before the binary is shipped to production.

[Empty comment from Monorail migration]

This issue was migrated from crbug.com/llvm/69?no_tracker_redirect=1

[Auto-CCs applied]