On Tue, Jan 12, 2021 at 11:28:40PM +0100, Pavel Machek wrote: > > This thread suggested that kernel is _not_ supposed to be robust > against corrupt filesystems (because fsck is not integrated in > kernel). Which was news to me (and I'm not the person that needs > warning in execve documentation). Define "supposed to be". In the ideal world, the kernel should be robust against corrupt file systems. In the ideal world, hard drives would never die, and memory bits would never get flipped due to cosmic rays, and so Intel would be correct that consumers don't need ECC memory. In the ideal world, drivers would never make mistakes, and so seat belts would be completely unnecessasry. Unfortunately, we live in the real world. And so there is risk associated with using various technologies, and that risk is not a binary 0% vs 100%. In my mind, assuming that file systems are robust against maliciously created images is much like driving around without a seat belt. There are plenty of people who drive without seat belts for years, and they haven't been killed yet. But it's not something *I* would do. But hey, I also spent extra money to buy a personal desktop computer with ECC memory, and I don't go bicycling without a helment, either. You're free to decide what *you* want to do. But I wouldn't take a random file system image from the Net and mount it without running fsck on the darned thing first. As far as secure boot is concerned, do you know how many zero days are out there with Windows machines? I'm pretty sure there are vast numbers. There are even more systems where the system adminsitrators haven't bothered to install latest updates, as well. > And if we have filesystems where corrupt image is known to allow > arbitrary code execution, we need to Define *known*. If you look at the syzbot dashboard, there are hundreds of reproducers where root is able to crash a Linux server. Some number of them will almost certainly be exploitable. The problem is it takes a huge amount of time to analyze them, and Syzbot's file system fuzzers are positively developer-hostile to root cause. So usually I find and fix ext4 file system fuzzing reports via reports from other fuzzers, and then eventually syzbot realizes that the reproducer no longer works, and it gets closed out. I'd certainly be willing to bet a beer or two that there are vulnerabilities in VFAT, but do I *know* that to be the case? No, because I don't have the time to take a syzbot report relating to a file system and root cause it. The time to extract out the image, and then figure out how to get a simple reproducer (as opposed to the mess that a syzbot reproducer that might be randomly toggling a network bridge interface on one thread while messing with a file system image on another) is easily 10-20 times the effort to actually *fix* the bug once we're able to come up with a trivial reproducer with a file system image which is a separate file so we can analyze it using file system debugging tools. I'm also *quite* confident that the NSA, KGB, and other state intelligence agencies have dozens of zero days for Windows, Linux, etc. We just don't know in what subsystem they are in, so we can't just "disable them when secure boot is enabled". - Ted
