On Tue, Dec 6, 2022 at 11:46 PM Tim <ignored_mail...@yahoo.com.au> 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@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
