4 ms·

Interesting that Google's syzbot found and publicized the flaw, possibly bringing it the awareness of bad actors. But at the time the flaw was not flagged as be

Interesting that Google's syzbot found and publicized the flaw, possibly bringing it the awareness of bad actors. But at the time the flaw was not flagged as being security related and was thus not backported as a security patch. If Google's syzbot had checked the kernel for the flaw before it was released instead of after, that also seems like it would have prevented the issue from going live in the first place. Why does the Linux kernel project continue to release code with flaws like this that can be found with automated tools?

fulafel 7y ago
It finds memory safety bugs, so it would be prudent to treat all findings as security bugs by default. The binder driver maintainers did get notified right away and it's a prominent part of android attack surface.
outworlder 7y ago
> Why does the Linux kernel project continue to release code with flaws like this that can be found with automated tools? Because they have no other option, it's a fuzzer. Therefore, it may take a long time(up to universe heat death) for it to finally exercise the path that causes the issue. And the kernel has a pretty enormous footprint. Fuzzers never really terminate, so it is not like you can plug it on a CI/CD system and wait for reports. > The process of reproducing one crash may take from a few minutes up to an hour depending on whether the crash is easily reproducible or non-reproducible at all. That's for one known crash. But otherwise it will be running 24/7 (across multiple VMs!) looking for issues. More details here: https://github.com/google/syzkaller https://github.com/google/syzkaller
- fulafel 7y ago
  Depending on what was meant by "like this", they do have the option of fixing this class of bugs (memory safety vulns), using mature tried and tested programming language practices and technology. It's a decades old debate between the C enthusiasts and the correctness/security enthusiasts. (Same problems and options are of course available Apple and Microsoft - it's not just Linux)
  - saagarjha 7y ago
    What technology would you have suggested be used here to catch this vulnerability early?
    - Thorrez 7y ago
      fulafel is not advocating catching the vulnerability, fulafel is advocating a more secure design. One possibility is Rust.
      - saagarjha 7y ago
        In the Linux kernel? Good luck…
      - fulafel 7y ago
        Well, Rust is not that mature, I agree today it would be an option worth considering. But people have been writing ring-0 code in safe languages for decades. And of course there are more dimensions to robust kernel design than chocie of programming language.
    - Crinus 7y ago
      This is just a longer worded version of Rewrite It In Rust :-P
panpanna 7y ago
> Why does the Linux kernel project continue to release code with flaws like this that can be found with automated tools? This was fixed by the next release. What happened here is 100% on Googles android team who don't follow mainline kernel releases & patches.

fulafel 7y ago

It finds memory safety bugs, so it would be prudent to treat all findings as security bugs by default. The binder driver maintainers did get notified right away and it's a prominent part of android attack surface.

outworlder 7y ago

> Why does the Linux kernel project continue to release code with flaws like this that can be found with automated tools? Because they have no other option, it's a fuzzer. Therefore, it may take a long time(up to universe heat death) for it to finally exercise the path that causes the issue. And the kernel has a pretty enormous footprint. Fuzzers never really terminate, so it is not like you can plug it on a CI/CD system and wait for reports. > The process of reproducing one crash may take from a few minutes up to an hour depending on whether the crash is easily reproducible or non-reproducible at all. That's for one known crash. But otherwise it will be running 24/7 (across multiple VMs!) looking for issues. More details here: https://github.com/google/syzkaller https://github.com/google/syzkaller

fulafel 7y ago
Depending on what was meant by "like this", they do have the option of fixing this class of bugs (memory safety vulns), using mature tried and tested programming language practices and technology. It's a decades old debate between the C enthusiasts and the correctness/security enthusiasts. (Same problems and options are of course available Apple and Microsoft - it's not just Linux)
- saagarjha 7y ago
  What technology would you have suggested be used here to catch this vulnerability early?
  - Thorrez 7y ago
    fulafel is not advocating catching the vulnerability, fulafel is advocating a more secure design. One possibility is Rust.
    - saagarjha 7y ago
      In the Linux kernel? Good luck…
    - fulafel 7y ago
      Well, Rust is not that mature, I agree today it would be an option worth considering. But people have been writing ring-0 code in safe languages for decades. And of course there are more dimensions to robust kernel design than chocie of programming language.
  - Crinus 7y ago
    This is just a longer worded version of Rewrite It In Rust :-P

panpanna 7y ago

> Why does the Linux kernel project continue to release code with flaws like this that can be found with automated tools? This was fixed by the next release. What happened here is 100% on Googles android team who don't follow mainline kernel releases & patches.