On Tue, Dec 6, 2022 at 11:46 PM Tim <ignored_mailbox@xxxxxxxxxxxx> wrote: > > On Tue, 2022-12-06 at 19:30 -0500, Jeffrey Walton wrote: > > The keyword is "known". Developers don't work on 5 or 10 year old > > software. Existing bugs don't get uncovered and fixed. They don't > > become "known", so they don't get backported and fixed. > > > > That's exactly the point Greg HK makes at > > https://thenewstack.io/design-system-can-update-greg-kroah-hartman-linux-security/ > > . No one is working on old kernels. Problems in old kernels are going > > to remain latent and unfixed. Kernel developers and Red Hat may > > backport an occasional fix, but they are not fixing all the problems. > > Odd. On my CentOS 7 system, my last kernel update was mid-November, > the prior the month before, another a month before that, another a > month before that. Hardly not being worked on. The kernel is an on- > going thing, and various distros backport what they can. You are not getting all the fixes. From Greg's talk: Kroah-Hartman gave a good example of how a benign looking bug can turn into something nasty. Some three years ago a TTY1 layer bug was fixed. Back then it looked like a normal, harmless bug. The kernel community fixed it, pushed it in the new release and was done with it. Three years later someone was found it to be a security bug. Now companies freaked out. They didn’t bother to use the patches back then, and now even companies like SUSE and Red Hat had to go back and fix all their old stuff. Here's one I have first hand knowledge of from 2021. It should have gotten a CVE, but Mitre's website would not accept my report/request: https://github.com/weidai11/cryptopp/issues/1072 . Here's another one from 2018: https://github.com/weidai11/cryptopp/issues/602 . I'm fairly certain an attacker can exploit both of those. Neither got CVEs (though I tried). Neither was backported to earlier versions of the library. I've seen other projects do the same with memory errors. Some don't even bother trying to get a CVE because they consider it a security theatre. These bugs are more instances of the Greg's TTY1 layer bug. No one thinks it is important. Companies like Red Hat and SUSE will never know to pick-up the change because there's no signalling to them. > ... > > The same thing happens in userland. I help maintain several projects, > > and contribute to many others. None of those projects concern > > themselves with 5 or 10 year old software. The problems in old > > software remain unfixed. > > My experience with programmers is that they don't like having the rug > pulled out from under them mid-development. There are many programs > that spend years in development (pre- and post-release). That's harder > to do when you have to keep re-learning the quirks of systems. No one likes revisiting old code. It's just something you have to do, like going to the dentist. > Likewise with sysadmins. Many features upgrades are entirely unwanted, > bug fixes is all they're interested in. Ideally, you stay lock-step with technology you depend on, and the break/fix cycle is small as you keep pace with things. But put it off for several years, and you'll find you boxed yourself into a bad place. You will find you are carrying a lot of technological debt, and you are accepting a lot of risk. And the worst thing about it (to me) is: a company puts off the maintenance to keep profits up and shareholders happy. But they screw me, you, our families and friends when the data breach comes. And to add insult to injury, then they issue those repulsive statements like, "it was an advanced persistent threat" or "we care deeply about security." Hogwash. They made their choices, and it was to trade security and our online safety for profits. Jeff _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
