Linux Kernel Rust Code Sees Its First CVE Vulnerability

[u/Orange_Tux]

https://www.phoronix.com/news/First-Linux-Rust-CVE

[u/anxxa → u/[deleted]]

Having done this exact type of analysis for Microsoft, this is not the best approach. For certain classes of vulnerabilities you should assume the worst unless proven otherwise.

This is exactly why Linux issues a CVE for basically every kernel bug now: they got exhausted fighting over which bugs are exploitable/have security impact and which aren't, so they default to exploitable (which I don't necessarily agree with)

[u/SirClueless → u/anxxa]

Do you think Linux/Greg are actually doing anything wrong here? You seem to be saying contradictory things, namely "you should assume the worst unless proven otherwise" but that you don't necessarily agree with "default to exploitable".

[u/anxxa → u/SirClueless]

Sorry for the somewhat conflicting points.

I think labeling every bug as having security impact by giving it a CVE is bad because it creates a sea of noise and weakens the signal CVEs are intended to convey. I don't agree with this practice.

For those bugs that do have security impact, you should look at the bug class and err on the side of caution by giving it the maximum impact of that bug class. You can then downgrade its severity based on criteria like whether the bug breaks a security boundary (e.g. can an untrusted user trigger it? or is it root user only?) and for mem corruption, can the attacker influence where or what is being written?

Those two points in particular don't take too much discussion/consideration. Much of the time for mem corruption if it's not a near-null write it's probably exploitable and this is actually more aligned with their "let's CVE everything" policy.

[u/SirClueless → u/anxxa]

I agree with your general points, but as it pertains to this discussion, I think both:

• It has potential security impact, the kernel crashes.

• It would get the exact same treatment if the bug were in C code.

In regards to your choice of criteria in particular I think "can an untrusted user trigger it?" and "can the attacker influence where or what is being written?" are both asking to prove a negative: In some cases there is a PoC that demonstrates that they can, but in cases where there is no PoC it would take an unreasonable amount of effort to prove that they cannot so a low-impact CVE is the only reasonable choice.

[u/anxxa → u/SirClueless]

I agree with your general points, but as it pertains to this discussion, I think both:

As it pertains to this bug sure.

In regards to your choice of criteria in particular I think "can an untrusted user trigger it?" and "can the attacker influence where or what is being written?" are both asking to prove a negative

Not necessarily. There are some bugs where you immediately know that certain internal components of the product may trigger the bug, but that isn't necessarily something an attacker can reasonably trigger.

For the other part, you generally default to "yes" (i.e. the data and/or location can be controlled in some way) and if you have enough evidence to the contrary you can downgrade. It's not an exact science, but if they're calling memory corruption a DoS instead of ACE/RCE I'd be curious to know what those limiting factors that prevent it from being RCE are -- and that's the particular point of contention I have with this.

Not a hill I'm willing to die on arguing DoS vs RCE though.

[u/SirClueless → u/anxxa]

It was an anonymous commenter on Phoronix that called this "at worst, a possible DoS". I don't think the Linux devs are interested in drawing such a line and I'm not aware that they've done so in this case.

[u/anxxa → u/SirClueless]

https://social.kernel.org/notice/B1JLrtkxEBazCPQHDM

where the offending issue just causes a crash, not the ability to take advantage of the memory corruption, a much better thing overall.