4 ms·

If the maintainers were unresponsive, sure -- but it seems slightly hard to buy that a responsible reporter trying to make a big splash and a good impression wo

by ori_b 6mo ago

If the maintainers were unresponsive, sure -- but it seems slightly hard to buy that a responsible reporter trying to make a big splash and a good impression wouldn't first check "did this make it out to the distros?" before making sysadmin's days real shitty, even if technically they could point fingers at other parties. At which point, if they're paying paying any attention at all to what they reported, they may have realized that a mistake was made.

john_strinlai 6mo ago
its an industry standard disclosure process. 90 days after reporting, or 30 days after the patch lands, the vuln is disclosed. the linux kernel team is in a 10000% better position to communicate to and coordinate their downstreams. it seems completely backwards to me to suggest that the reporter should be responsible for figuring out every possible downstream and opening up separate reports to each of them. the kernel team should have a process/channel to say "this is important! disclosure is in 30 days" that is received by distro security teams. because this is not the first or last time the kernel will have a local privilege escalation. hoping that every reporter, forever in the future, will take the onus on themselves is a recipe for disapointment.
- ori_b 6mo ago
  Yes, it's just incompetence from everyone involved, not malice. The company making the disclosure doesn't actually care, and the kernel processes are ineffective.
  - tptacek 6mo ago
    No, it's incompetence from everyone involved except the company making the disclosure, which, despite the fact that the existing norms are not in fact binding (like people downthread seem to believe), they followed.
    - ori_b 6mo ago
      Really? It seems very odd to not check in on the status of the fixes, even if it's technically possible to pass the blame to other people. Even if the only purpose of looking at the status to make yourself look good in marketing materials, it's surprising that it didn't happen.
      - Joker_vD 6mo ago
        One of the reasons this unavoidable deadline was invented, is that the alternative is that one company (or all of them) can simply decide to ignore the vuln report, and then the vulnerability will stay forever undisclosed and forever out there in the wild. And prisoner's dilemma suggests that most companies would chose "do nothing" in this scenario: they don't have to do anything, and if the vuln stays undisclosed, it probably won't be exploited anyhow. Win-win!
        ori_b 6mo ago
        I'm confused. Can you explain how this applies to the current situation, where no vuln reports were submitted to the groups responsible for distributing patches?
        john_strinlai 6mo ago
        >where no vuln reports were submitted to the groups responsible for distributing patches? the vulnerability report was submitted to the kernel security team and appropriate kernel maintainers. those are the people responsible for patching the kernel, which they did 30 days ago.
        ori_b 6mo ago
        I see, may the people who are responsible for the infrastructure you depend on be less concerned about shifting blame than you are.
        6mo ago
- bragr 6mo ago
  The problem is that if you make too big of a deal about a particular patch, then someone just reverse engineers the vuln from the fix and your responsible disclosure period doesn't exist anymore. Gentoo has to take some blame too for not keeping all the kernels they maintain patched in a timely way.
  - john_strinlai 6mo ago
    you minimize this with the curated contact list. the baddies are looking at every patch anyways.
  - tremon 6mo ago
    > Gentoo has to take some blame too for not keeping all the kernels they maintain patched in a timely way. How do you figure that? From what I could tell from the earlier post, the fix has only been backported to 6.18 and later, and as TFA indicates the distro's were not informed of the security implications of this fix. All distro's shipping a major kernel version from more than a year ago -- and that includes all LTS kernels -- are vulnerable, regardless of how "timely" their patch schedules follow upstream.
    - bragr 6mo ago
      >All distro's shipping a major kernel version from more than a year ago -- and that includes all LTS kernels -- are vulnerable, regardless of how "timely" their patch schedules follow upstream To be fair, I question the wisdom of managing kernels like that across all distros.

by ori_b 6mo ago

john_strinlai 6mo ago

its an industry standard disclosure process. 90 days after reporting, or 30 days after the patch lands, the vuln is disclosed. the linux kernel team is in a 10000% better position to communicate to and coordinate their downstreams. it seems completely backwards to me to suggest that the reporter should be responsible for figuring out every possible downstream and opening up separate reports to each of them. the kernel team should have a process/channel to say "this is important! disclosure is in 30 days" that is received by distro security teams. because this is not the first or last time the kernel will have a local privilege escalation. hoping that every reporter, forever in the future, will take the onus on themselves is a recipe for disapointment.

ori_b 6mo ago
Yes, it's just incompetence from everyone involved, not malice. The company making the disclosure doesn't actually care, and the kernel processes are ineffective.
- tptacek 6mo ago
  No, it's incompetence from everyone involved except the company making the disclosure, which, despite the fact that the existing norms are not in fact binding (like people downthread seem to believe), they followed.
  - ori_b 6mo ago
    Really? It seems very odd to not check in on the status of the fixes, even if it's technically possible to pass the blame to other people. Even if the only purpose of looking at the status to make yourself look good in marketing materials, it's surprising that it didn't happen.
    - Joker_vD 6mo ago
      One of the reasons this unavoidable deadline was invented, is that the alternative is that one company (or all of them) can simply decide to ignore the vuln report, and then the vulnerability will stay forever undisclosed and forever out there in the wild. And prisoner's dilemma suggests that most companies would chose "do nothing" in this scenario: they don't have to do anything, and if the vuln stays undisclosed, it probably won't be exploited anyhow. Win-win!
      - ori_b 6mo ago
        I'm confused. Can you explain how this applies to the current situation, where no vuln reports were submitted to the groups responsible for distributing patches?
        john_strinlai 6mo ago
        >where no vuln reports were submitted to the groups responsible for distributing patches? the vulnerability report was submitted to the kernel security team and appropriate kernel maintainers. those are the people responsible for patching the kernel, which they did 30 days ago.
        ori_b 6mo ago
        I see, may the people who are responsible for the infrastructure you depend on be less concerned about shifting blame than you are.
        6mo ago
bragr 6mo ago
The problem is that if you make too big of a deal about a particular patch, then someone just reverse engineers the vuln from the fix and your responsible disclosure period doesn't exist anymore. Gentoo has to take some blame too for not keeping all the kernels they maintain patched in a timely way.
- john_strinlai 6mo ago
  you minimize this with the curated contact list. the baddies are looking at every patch anyways.
- tremon 6mo ago
  > Gentoo has to take some blame too for not keeping all the kernels they maintain patched in a timely way. How do you figure that? From what I could tell from the earlier post, the fix has only been backported to 6.18 and later, and as TFA indicates the distro's were not informed of the security implications of this fix. All distro's shipping a major kernel version from more than a year ago -- and that includes all LTS kernels -- are vulnerable, regardless of how "timely" their patch schedules follow upstream.
  - bragr 6mo ago
    >All distro's shipping a major kernel version from more than a year ago -- and that includes all LTS kernels -- are vulnerable, regardless of how "timely" their patch schedules follow upstream To be fair, I question the wisdom of managing kernels like that across all distros.