6 ms·

I wonder how these vulnerabilities would be treated if the researchers didn't bother to find an exploit for them? The description of the exploit is so detailed

I wonder how these vulnerabilities would be treated if the researchers didn't bother to find an exploit for them? The description of the exploit is so detailed that it gives the impression that discovering the original vulnerability was fairly quick and simple, and the real work is in building a functioning exploit to wriggle through the discovered kernel flaw. If the researchers were to just stop once they discover the vulnerability, and immediately report it to the kernel security team, would it be treated with the same level of seriousness? Could a CVE with the same severity be issued, or would there be arguments over whether or not the bug is exploitable?

fulafel 5y ago
Nitpick: CVE's don't have severities, and it's somewhat arbitrary if a CVE ID number gets assigned for a bug or not. They are basically just handles so that if there is one, people can use it to differentiate which potential vulnerability they are talking about. There are some linked things (called CWE, CVSS, and probably more) that links to CVE IDs and there's some scoring but it's less widely used & more contested as a system.
saagarjha 5y ago
In general, to be safe you should treat all memory corruption bugs as leading to code execution. Now, it may be difficult to exploit the bug, but more often than not "probably unexploitable" bugs end up being exploitable; even bad primitives like one-byte overwrites or wild copies. Of course, without an exploit you can always just say "ok this is not exploitable, I'm going to ignore it", but such an outlook is generally frowned upon now.
fulafel 5y ago
Yep, this is a big problem. In general non experts are impressed by laboriously refined exploits, not vulnerability discoveries, and even on HN a lot of people get those 2 concepts and terms mixed upwhich muddies the issue even more.
superjan 5y ago
It should be at least as profitable (per hour) to find and fix kernel out of bound writes as writing full exploits. The risk is you’re doing legwork for bad actors. Of course the exploit is published after the fix, but not all devices are fixed by that time.
pjmlp 5y ago
It was, the first step to find out bugs in C (and C++) code always starts the same way "...inspired me to grep for memcpy() and memset() in the Netfilter code. This led me to some buggy code.".
- nine_k 5y ago
  Does C++ code even use memcpy these days? A honest question.
  - pjmlp 5y ago
    Surely. It is part of ISO C++, and not everyone agrees with C++ safe coding practices.
    - agent327 5y ago
      In practice it's much easier to use assignment or copy construction, thus avoiding the dangerous memcpy. Same goes for those memsets and bzero's beloved of C-programmers: just make the class do it for you; it always works, cannot be forgotten, cannot be done wrong, and is just much easier to begin with. Or, if you have a C-struct you need to interface with, just declare it as 'foo myfoo = {0};'. That also zero's out the whole thing, and the compiler won't get the size wrong.
      - pjmlp 5y ago
        I fully agree.
    - jeffbee 5y ago
      memcpy is the only defined way to type pun in C++. Anyone intentionally avoiding it probably has UB instead.
      - pjmlp 5y ago
        Starting with C++20, std::bit_cast is also an option. https://en.cppreference.com/w/cpp/numeric/bit_cast https://en.cppreference.com/w/cpp/numeric/bit_cast
nine_k 5y ago
So you think it's too much work for $10k? I won't write off just the desire to nail it beyond doubt to secure the bounty.
staticassertion 5y ago
The vulnerability would be buried. Greg is extremely, consistently reluctant to issue CVEs without security engineers bending over backwards.
- scottlamb 5y ago
  > The vulnerability would be buried. Greg is extremely, consistently reluctant to issue CVEs without security engineers bending over backwards. From https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/ https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-... I'd paraphrase his philosophy as kernel developers should fix bugs (without requiring they be security-related or worrying about CVE assignment), users should run a recent stable/long-term kernel.
  - staticassertion 5y ago
    LTS is a noble effort but leaves quite a lot to be desired, and doesn't really change the fact that Greg (and others) have multiple decades of history hiding vulns and pushing back on CVEs.
    - gnubison 5y ago
      Have you watched the talk? Greg talks a lot about the flaws with CVEs.
      - staticassertion 5y ago
        Yes, I have.

fulafel 5y ago

Nitpick: CVE's don't have severities, and it's somewhat arbitrary if a CVE ID number gets assigned for a bug or not. They are basically just handles so that if there is one, people can use it to differentiate which potential vulnerability they are talking about. There are some linked things (called CWE, CVSS, and probably more) that links to CVE IDs and there's some scoring but it's less widely used & more contested as a system.

saagarjha 5y ago

In general, to be safe you should treat all memory corruption bugs as leading to code execution. Now, it may be difficult to exploit the bug, but more often than not "probably unexploitable" bugs end up being exploitable; even bad primitives like one-byte overwrites or wild copies. Of course, without an exploit you can always just say "ok this is not exploitable, I'm going to ignore it", but such an outlook is generally frowned upon now.

fulafel 5y ago

Yep, this is a big problem. In general non experts are impressed by laboriously refined exploits, not vulnerability discoveries, and even on HN a lot of people get those 2 concepts and terms mixed upwhich muddies the issue even more.

superjan 5y ago

It should be at least as profitable (per hour) to find and fix kernel out of bound writes as writing full exploits. The risk is you’re doing legwork for bad actors. Of course the exploit is published after the fix, but not all devices are fixed by that time.

pjmlp 5y ago

It was, the first step to find out bugs in C (and C++) code always starts the same way "...inspired me to grep for memcpy() and memset() in the Netfilter code. This led me to some buggy code.".

nine_k 5y ago
Does C++ code even use memcpy these days? A honest question.
- pjmlp 5y ago
  Surely. It is part of ISO C++, and not everyone agrees with C++ safe coding practices.
  - agent327 5y ago
    In practice it's much easier to use assignment or copy construction, thus avoiding the dangerous memcpy. Same goes for those memsets and bzero's beloved of C-programmers: just make the class do it for you; it always works, cannot be forgotten, cannot be done wrong, and is just much easier to begin with. Or, if you have a C-struct you need to interface with, just declare it as 'foo myfoo = {0};'. That also zero's out the whole thing, and the compiler won't get the size wrong.
    - pjmlp 5y ago
      I fully agree.
  - jeffbee 5y ago
    memcpy is the only defined way to type pun in C++. Anyone intentionally avoiding it probably has UB instead.
    - pjmlp 5y ago
      Starting with C++20, std::bit_cast is also an option. https://en.cppreference.com/w/cpp/numeric/bit_cast https://en.cppreference.com/w/cpp/numeric/bit_cast

nine_k 5y ago

So you think it's too much work for $10k? I won't write off just the desire to nail it beyond doubt to secure the bounty.

staticassertion 5y ago

The vulnerability would be buried. Greg is extremely, consistently reluctant to issue CVEs without security engineers bending over backwards.

scottlamb 5y ago
> The vulnerability would be buried. Greg is extremely, consistently reluctant to issue CVEs without security engineers bending over backwards. From https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/ https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-... I'd paraphrase his philosophy as kernel developers should fix bugs (without requiring they be security-related or worrying about CVE assignment), users should run a recent stable/long-term kernel.
- staticassertion 5y ago
  LTS is a noble effort but leaves quite a lot to be desired, and doesn't really change the fact that Greg (and others) have multiple decades of history hiding vulns and pushing back on CVEs.
  - gnubison 5y ago
    Have you watched the talk? Greg talks a lot about the flaws with CVEs.
    - staticassertion 5y ago
      Yes, I have.