
Linux Kernel Through 4.20.10 Found Vulnerable to Arbitrary Code Execution - robin0
https://coocoor.com/advisory/cve/CVE-2019-8912
======
ebiggers
AFAICS, this was exposed by the addition of sockfs_setattr() in v4.10. So it's
incorrect to claim that kernels older than that are vulnerable, even though
the code being fixed was older.

Also, note that there may not actually be a proof-of-concept exploit yet,
beyond a reproducer causing a KASAN splat. When people request a CVE for a
use-after-free bug they usually just assume that code execution may be
possible. (Exploits can be very creative.)

------
sargun
How does this use-after-free turn into an arbitrary code execution vuln? I
don't see any jmp to the pointer?

~~~
altmind
I urge the mods to correct the title. Maybe: Linux<4.20.10 af_alg_release use-
after-free vulnerability[CVE-2019-8912]

~~~
cmurf
[https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/crypto/af_alg.c?h=v4.20.11)

See line 126-127 and compared to the patch at the bottom of:
[http://patchwork.ozlabs.org/patch/1042902/](http://patchwork.ozlabs.org/patch/1042902/)

Patch is not yet merged into 5.0.0rc7 either. Whereas it is in linux-next.
[https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...](https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-
next.git/tree/crypto/af_alg.c?h=next-20190220)

Update: I expect all of the longterm kernels listed on kernel.org will get a
backport.

------
ptrincr
Looks like this is the fix:

[https://github.com/torvalds/linux/commit/9060cb719e61b685ec0...](https://github.com/torvalds/linux/commit/9060cb719e61b685ec0102574e10337fa5f445ea)

~~~
doctorpangloss
Is there a reason the kernel style doesn't always require curly braces after
"if" statements?

~~~
a-wu
"Do not unnecessarily use braces where a single statement will do."

[https://www.kernel.org/doc/html/v4.10/process/coding-
style.h...](https://www.kernel.org/doc/html/v4.10/process/coding-
style.html#placing-braces-and-spaces)

~~~
kgwxd
A rule that should be removed from every coding style doc for every c-like
language on the planet.

~~~
shawnz
Why? Because Apple had a critical vuln _one time_ which was made slightly
harder to spot because of it?

~~~
thaumaturgy
When drafting a style guide, one of your goals is to make the code as uniform
as possible. It removes ambiguity and makes it easier to enforce the rules of
the style guide, hopefully with automated tooling.

Mandatory bracing is a step towards more uniformity, and makes additional
statements in a conditional block always safe, and at the cost of just one
extra line in the code.

It also makes your commits just a little bit smaller; if you do add more lines
to a conditional block that was previously braceless, now you just get the new
lines in the diff, instead of new lines + opening brace + closing brace.

Cowboy coding of course scoffs at all this and people have different values
when making tradeoffs between readability and concision, but there are good
reasons for enforcing mandatory braces.

~~~
CapacitorSet
The uniformity argument becomes rather silly when applied to other constructs.

Would you ditch switch-cases in favor of if-else chains (leaving aside
fallthrough/Duff's/etc for a moment) because the latter is uniform with
existing constructs? Would you ditch "for (int i = 0; ..." in favor of "int i;
for (i = 0; ..."?

~~~
thaumaturgy
> _Would you ditch switch-cases in favor of if-else chains_

No. You're talking about applying style rules for if-else conditionals to
statements which aren't if-else, which isn't what I was talking about.

This is why the Linux kernel style guide, OpenBSD style, PSR, etc. all have
separate guidelines for switch-case along with guidelines for mandatory
bracing in if-else.

> Would you ditch "for (int i = 0; ..." in favor of "int i; for (i = 0; ..."?

There isn't a clear-cut rule about this convention in style guides. That's
probably in part because the behavior in your two examples is different: in
the first case (in C++), _i_ only exists within the scope of the for loop,
whereas in the latter case it will continue to exist outside the scope of the
for loop.

Whichever one is appropriate would probably depend on context that's outside
the scope of a style guide. They're called style guides, after all, not
Programming Rules of Law. :-)

------
shereadsthenews
FYI there has not ever been a Linux kernel that lacks an exploit available to,
at least, local users. There is every reason to believe that the current
kernel contains at least one such flaw.

~~~
vermilingua
This likely extends to NT, BSD, Darwin, and most other kernels. Kernels are
tricky beasts. You could just say “not ever been a kernel that lacks...”

~~~
userbinator
DOS. It has no privilege escalation exploits, because by design it has no
concept of different privileges.

Personally, I think as a regular user of a PC, it's the remote exploits that
you really need to worry about, the ones of the form "connect to the Internet
and get pwned without doing anything else", fortunately quite rare; and in
this era of user-hostile devices, local privilege escalation can even be
_friendly_ in terms of rooting and jailbreaks.

~~~
pdonis
_> DOS. It has no privilege escalation exploits, because by design it has no
concept of different privileges._

No, DOS has no _protection_ against exploits, because by design it has no
concept of different privileges. Anyone with access to a DOS system is
automatically root and can do anything. "No exploits" is not a good
description of that state of affairs.

~~~
pjmlp
In fact, exactly because of that, DOS and all the other home system OSes had
plenty of virus to choose from.

------
blattimwind
Better link:
[https://nvd.nist.gov/vuln/detail/CVE-2019-8912](https://nvd.nist.gov/vuln/detail/CVE-2019-8912)

------
pmoriarty
Where is crypto/af_alg.c actually used? In what use cases does this
vulnerability come in to play?

~~~
sigmaris
Not totally certain, but I believe it'd be used if a userspace program used
the Linux Kernel Crypto API, using a socket of type AF_ALG.

[https://www.kernel.org/doc/html/v4.11/crypto/userspace-
if.ht...](https://www.kernel.org/doc/html/v4.11/crypto/userspace-if.html)

------
cmurf
I'm not seeing the patch in 4.20.11's changelog or any of the longterm kernel
versions posted today.

~~~
tramtrist
I literally just compiled 4.20.11 for Slackware. I swear these things are
popping up more often. Or more likely since spectre I've just been paying more
attention

~~~
ebeip90
More people are fuzzing the kernel publicly, and with better tools.

syzkaller.appspot.com should give you an idea how many THOUSANDS of these
types of bugs exist in the current ToT kernel

~~~
Hackbraten
What is ToT? I’ve found that term mentioned several times on the Chromium bug
tracker but no definition.

~~~
sjburt
Tip of Tree / Top of Tree. I.e present as of the most recent commit on the
main development branch.

------
saagarjha
Hooray for KASAN!

~~~
ronjouch
Didn't know about KASAN (
[https://github.com/google/kasan/wiki](https://github.com/google/kasan/wiki)
). _" KernelAddressSanitizer (KASAN) is a dynamic memory error detector. It
provides a fast and comprehensive solution for finding use-after-free and out-
of-bounds bugs in Linux kernel. KASAN is available in the upstream Linux
kernel starting from 4.0. Can be enabled with CONFIG_KASAN=y."_

------
uvesten
Is this a remote exploit? The NIST page seems to say so.

~~~
orblivion
I'm waiting for the day where there's one reliable place in the world where
someone can look at info about a vulnerability and see very important and
basic information like this. I think the interesting technical discussions for
security experts get mixed in with the useful executive summary for the rest
of us.

Remember when Intel ME bugs started coming out and we all had to go to Hacker
News and trade rumors to figure out what was really going on?

~~~
ungamed
I do try to get it right or the Red Hat affected cve pages.

[https://access.redhat.com/security/cve/cve-2019-8912](https://access.redhat.com/security/cve/cve-2019-8912)

The problem is one can only really talk about CVE's within the context of the
product, perhaps a global CVE wiki /discussion page that can have
edits/discussion would be a useful resource.

~~~
orblivion
> Attack Vector: Local

Very good, gets right to the point. I'll try to remember this for next time,
thank you.

Still could be improved a lot. I was thinking of writing up a "requirements
doc" at some point for what exactly I think would be useful for such things.
I'm not sure I'd be so happy with a Wiki, unless it was curated by trusted
people. I wouldn't want (for example) malicious people editing a serious
report to say it's no big deal just to buy themselves more time to exfiltrate
more data.

------
birbie
I haven't seen any POC exploits at all yet. Will be looking around this
weekend.

~~~
tty7
how do you "look" for POC's?

~~~
PenguinCoder
Various websites, shady forums, tor sites, and 'hacker spaces'. Sometimes that
includes white/gray hat haunts for exploit code. Pastebin like sites,
github.com, etc. 'darkweb' and OSINT searches. If there is a know vuln, there
is someone out there eager to be 'first' to writing exploit code and showing
off.

~~~
gtirloni
Any place where a concrete list of such resources can be found?

~~~
jdeca568
Here is one: [https://www.exploit-db.com/](https://www.exploit-db.com/).

But this CVE doesn't appear to be referenced at the moment.

------
jaboutboul
Can someone please explain how exactly this is ACE?

~~~
saagarjha
It's a use-after-free, which can often be turned into arbitrary code execution
by massaging the allocator into letting you write over memory you shouldn't be
able to (like a function pointer) and using that to gain control over
execution.

------
skyde
is it something using a safer language like Rust would have prevented ?

~~~
apta
Yes.

------
SilasX
I really shouldn't comment on Linux kernel development, given mu lack of
knowledge, but since this is a use-after-free vuln, doesn't that strengthen
the case to moving to memory safe languages?

~~~
exabrial
You would take a massive hit in performance. But there are operating systems
(some commercial) like that

~~~
pjmlp
Including Android and ChromeOS, which while being based on the Linux kernel
don't expose its interfaces directly to userspace, and with Treble Android
Linux variant is a kind a pseudo micro-kernel with several services running on
their own processes and using Android IPC for data exchange.

------
EthanHeilman
Is this patched or is everything vulnerable?

~~~
0x0
Everything is vulnerable apparently: [https://security-
tracker.debian.org/tracker/CVE-2019-8912](https://security-
tracker.debian.org/tracker/CVE-2019-8912)

~~~
ungamed
All debian maybe.

------
Fnoord
Found by Huawei engineer Mao Wenan.

------
broknbottle
ahh looks like they have updated page to include 4.20.11. I was gonna say
after checking the source, both the latest and mainline are affected.

