[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 3 Sep 2018 19:26:53 +1000
From: Wade Mealing <wmealing@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: Linux kernel: CVE-2018-14619 kernel: crash
(possible privesc) in kernel crypto subsystem.
> Are we seriously now going to be assigning cves to everything that
> syzbot finds?
It sure is, lets hope it drives up the quality of the code and ensures
that higher
quality code is accepted upstream. A man can dream right ?
You've had questions about why I bring up flaws regarding older code,
such as that tty
(http://seclists.org/oss-sec/2015/q2/560) exploit so I'm glad to have
this chance to spend
some time explaining you why I work in this way.
> If not, why this specific patch? What makes it special from the hundreds
> of other syzbot finds that have been fixed (and not fixed yet)? This
> seems like an odd choice, given:
This flaw does crash the system, its easy for the user to do so, and
it did crash
our build-servers during testing.
So, its not necessarily _this patch_ its patches that either affect
Red Hat as a product
or customers demand. I don't get a choice in what is a security flaw
and what is not, local denial of service
is something that admins care about. If it comes across my plate and
it fits the definition of a flaw then
it is something that I need to consider.
It would be easier for me if when patches were applied that the
developer would go through the security-flaw process
of getting a CVE number, posting to the relevant security list, etc,
maybe oss-security wont
Unfortunately its not fun, its not glorious and I end up explaining
why I'm fixing older code to you, all
of these justifications I'm sure you're aware of.
Having those who create the patches do some of the leg-work would make my job
easier and correctly reflect the state of the developers security
posture, changing other peoples process
and asking them to do additional work of classifying a flaw/problem is
likely not going to happen,
which is why we are in the state we are in.
> If RHEL is not exposed, why does Red Hat care about this? Who cares
> about it? Anyone running a 4.14.y kernel has had this fixed for a very
> long time ago, and anyone not running a 4.14.y kernel is not affected.
The kernel-alt is an alternative kernel based on 4.14 which Red Hat ships for
certain architectures (See
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/7.5_release_notes/index#chap-Red_Hat_Enterprise_Linux-7.5_Release_Notes-Architectures
). Its a very similar (but not identical) build config to standard
Red Hat Enterprise
Linux based on 4.14.
While not many customers do run this kernel it is something that Red
Hat ships. While the flaw/problem no longer affects
your kernel, that is okay! I often investigate upstream bugs that
don't affect the the Red Hat kernels and move on with my life.
These older releases though, is something that some users do care
about. I think it is worse if I silently ignore a local DOS.
Upstream maintainers may have no obligation or interest in doing the
legwork for requesting and classifying this but it is my job.
> Again, I'm really confused why this was chosen for a CVE here.
> Care to explain it a bit better?
I'd love to see upstream classify and get CVE's for their patches, we
both gotta work within reality though ;)
The obvious technical reason is because it allows a local user to
panic the system,
when a known security fix goes into a product it requires a CVE as
part of our process.
> Is it because you have to have a CVE for every
> bugfix in the RHEL kernel-alt package (something that I would love to
> see happen for various other reasons...)
CVE's are assigned for bugs that have an security impact (DOS,
information leak or privesc). Not every bug
is a security bug but it is clear that some bugs have a larger
financial or stability concern than others. I can only work
on issues that I'm made aware of, this is one of them.
Previous responses to my mails show that you dislike posts made by me
about older code
(beware as more are coming!, redirect to /dev/null if its too
upsetting), there is nothing that I can do about that.
The responsibility that I have is to customers and not to kernel
maintainers. The day that the kernel stops
having these classes of flaws is the day that I won't have a job and
you wont need to worry.
I'd be happy to talk about this further, my job requirements however
are not flexible.
Thanks,
Wade Mealing
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
