In the Linux kernel through 4.20.11, af_alg_release() in crypto/af_alg.c neglects to set a NULL value for a certain structure member, which leads to a use-after-free in sockfs_setattr.
diff --git a/crypto/af_alg.c b/crypto/af_alg.cindex 17eb09d222ff..ec78a04eb136 100644--- a/crypto/af_alg.c+++ b/crypto/af_alg.c@@ -122,8 +122,10 @@ static void alg_do_release(const struct af_alg_type *type, void *private) int af_alg_release(struct socket *sock) {- if (sock->sk)+ if (sock->sk) { sock_put(sock->sk);+ sock->sk = NULL;+ } return 0; } EXPORT_SYMBOL_GPL(af_alg_release);
git.kernel.org
nvd.nist.gov
OH NoNOnoNONo.... OHOHH NOOOONOONONO.... BAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAAHA
CVE-2019-8912
Other urls found in this thread:
securityfocus.com
elixir.bootlin.com
elixir.bootlin.com
elixir.bootlin.com
youtube.com
elixir.bootlin.com
cdn.kernel.org
git.kernel.org
git.kernel.org
twitter.com
securityfocus.com
LOOOOOOOOOOOOOOOOOOOOOL
so is this some bad remote exploit that can be used easily or just another shitpost
It's a use after free vuln
Already patched in git, just wait for long term to update and everything will be fine again.
if you're on long term you shouldn't be vulnerable anyway. CentOS isn't outside of kernel-alt.
The "every prior kernel unto 0.0 is vulnerable" listing is just someone not bothering to see when the use-after-free was introduced.
ah, so it's fucking nothing.
yes but its not very useful if you need a user account on the machine to exploit it. if you can do it without any kind of authentication then its really bad.
OH NoNOnoNONo.... OHOHH NOOOONOONONO.... BAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAAHA
m8, every Linux version 2.8 through 4.20 is vulnerable.
but i dont want to reboot my servers yet
the vuln's through sockfs_setattr. that was added in 4.10 and wasn't backported.
But remember guys, open source automatically means safer because total randoms are surely going to do a decent audit of your spaghetti out of good will.
nice. i use 4.9 on the things that i dont want to reboot
I wonder how much (((they))) paid...
Reminder that no one has found an actual exploit yet, for now it's just a benign use-after-free.
You literally have the diff of the fix in the OP, wtf?
true. Although I wonder if it shouldn't be made to sock_put instead.
it hasn't hit linux git repos yet.
why would MITRE say Attack Complexity: Low
without at least a good idea of a POC exploit?
The fix is in the git repo but there are no releases with this fix.
spotted the cniles
Where is it actually used after being freed?
This is not an inherrent problem in C, but it is a problem in programming etiquette.
The programmer should've either named the function `sock_put_free` or changed the declaration to require a double pointer parameter to a struct socket.
it's used after free in several places. there's a write after free in sockfs_setattr. It's a real short function, just look at it: elixir.bootlin.com
the contract is "if sock->sk is not NULL , then it's good to use", and that contract is broken in elixir.bootlin.com
also
in Rust the required amount of expertise and discipline is "don't use unsafe {}", because the borrow checker doesn't allow this problem at all.
C sets a high bar before the problem is "not a problem"; most other languages have the bar quite a bit lower. Problems can be problems even if the required expertise and discipline isn't actually superhuman.
SCORE ANOTHER POINT FOR C
LOOOOOOOOOOOOOL
What about all the other vulnerabilities though? In which files are those?
the only reason rust doesn't have these types of vulnerabilities is because nobody uses it and nobody cares to check anything that does because it's all irrelevant.
it's the same reason there's so few virus's on OSX and linux, not because there can't be, but because it's irrelevant to target.
nice damage control
#!/usr/bin/env stap%{#include %}function null_it (sock) %{ struct socket *sock; sock = (struct socket *) STAP_ARG_sock; sock->sk = NULL;%}probe kernel.function("af_alg_release").return { null_it($sock);}... something like that.
I know what you mean, but Linux is too complicated anyway. A single human being just can't understand it all. Terry was right when he said that a great programmer deletes code, instead of adding more. (I can't remember the exact quote)
Use Ada. if it's good enough for US army and Boeing, then it should be good enough for you. I used to think that Ada was a niggerlicious language, but I researched it a bit, and it really seems like a good and beautiful (and white) language. Its only problem is that it's a bit verbose, perhaps. But it doesn't really matter to me that much tbh.
It's still not an excuse for this embarrassing bug.
Where is `sock_put` defined? How is someone supposed to read that name and think that it would free the pointer in the parameter?
I admit that it is something an experienced programmer will notice quicker than a novice, but that doesn't eliminate the need for novices to learn these practices as fundamental.
Either by naming convention or by function design, it is courtesy that if others will contribute to some software that it should be intuitive and not require hours of reversing before work can be attempted.
Where in your butt does it hurt?
Hello, fellow (((white))) programmer. I see you post anime also.
javascript is objectively more secure than rust
/* Ungrab socket and destroy it, if it was the last reference. */static inline void sock_put(struct sock *sk){ if (refcount_dec_and_test(&sk->sk_refcnt)) sk_free(sk);}
Yeah, that definitely should take a pointer to a pointer and assign NULL when necessary.
pathetic
degenerate.
lol you have obvious braindamage
What the fuck did you just fucking say about me, you little bitch? I'll have you know I graduated top of my class in the Navy Seals, and I've been involved in numerous secret raids on Al-Quaeda, and I have over 300 confirmed kills. I am trained in guerrilla warfare and I'm the top sniper in the entire US armed forces. You are nothing to me but just another target. I will wipe you the fuck out with precision the likes of which has never been seen before on this Earth, mark my fucking words. You think you can get away with saying that shit to me over the Internet? Think again, fucker. As we speak I am contacting my secret network of spies across the USA and your IP is being traced right now so you better prepare for the storm, maggot. The storm that wipes out the pathetic little thing you call your life. You're fucking dead, kid. I can be anywhere, anytime, and I can kill you in over 700 ways, and that's just with my bare hands. Not only am I extensively trained in unarmed combat, but I have access to the entire arsenal of the United States Marine Corps and I will use it to its full extent to wipe your miserable ass off the face of the continent, you little shit. If only you could have known what unholy retribution your little "clever" comment was about to bring down upon you, maybe you would have held your fucking tongue. But you couldn't, you didn't, and now you're paying the price, you goddamn idiot. I will shit fury all over you and you will drown in it. You're fucking dead, kiddo.
yikes
post popular software written entirely in rust
relevant: youtube.com
I would literally email my bank account login info + my SSN to russian botnet masters before I willingly used a program written in rust
And french space rockets
Wow. This guy really shows how much a clusterfuck free software is when you don't have any kind of official standards and practices for contributing.
woah, if only they had rules against virtual *hugs* none of this would have happened
I am not talking about some queer CoC(k). I am talking about Standards and Practices. Do you know what those are?
Well it was an easy patch, really annoying because nothing uses the crypto api really. I wonder how hard it is to exploit with kaslr and gcc stack protectors.
Dude, the patch is broken itself. `sock_put` is supposed to check if the socket should be NULL or not. `sock_put` needs patched to actually make the socket NULL when it is necessary, and everything that calls it needs to be patched so assigning the socket to NULL outside of the function unnecessary and incorrect.
brb deleting /crypto
But seriously, are you telling me linus has it wrong? can you show me where the real fix work is happening?
Well you're not wrong, but it was designed by a French Jew. So it's a (((white))) language.
Read the function.
The comment clearly states that `sock_put` checks if the socket should be destroyed, which means that there could be some occurence where the socket doesn't need to be destroyed. By assigning the socket reference to NULL outside the function, the check is useless and ignored essentially.
I don't know who wrote the patch, but in my opinion, it is wrong.
...
damn, that's true. The patch should reimplement sock_puts, and only set its arg NULL when that check succeeds.
There might be some other guarantee of the check always succeeding, that led the patch submitter to not bother, but probably he just didn't think it through.
The “Benny Hill” chase music played in my head while I scrolled through your list user.
Protip: I didn't mention Rust. Stop building a strawman and admit that you are LARPers
did you tell that to them?
Anti-Rustfag OP can you please be more original?
inb4 thread derail as expected and t. Rustfag because I don't care about that programming language.
I (the OP) am the Rustfag. Gotcha, cniles! I will never stop haunting this board.
forgot my image how embarrassing
Remember the low IQ soldiers? It's like you're one of them.
Are you also the OP of ?
Nah. I made this one as a response though.
the reference counting is for multiple users of the socket. sock_put doesn't free until there are now users. regardless, the caller is no longer a user, so the patch is right: it should unconditionally set that field to NULL.
Why are Rustfags so fucking salty?
Yes. Clearly there is some serious Rust shilling going on here.
Go and check yourself into a retirement home, cnile.
The absolute state of Rustfags. This is like systemd shills strawmanning everyone else as SysV init fanboys.
That doesn't matter.
If the socket pointer is supposed to be NULL at a certain condition, and if that condition is tested in a separate function, then that separate function should assign NULL to that pointer, not externally after the call.
That's my point.
it matters to whether the patch is defective or not--if it doesn't introduce new problems, like sock->sk improperly getting set to NULL
The patch is not defective.
Would it be better to change sock_put ? I think so, yeah. Even if this means that many uses of sock_put will have an unnecessary assignment, in most those cases (sock_put(blah); /* blah isn't used before going out of scope */) it should be compiled away as dead code.
ex. elixir.bootlin.com
setting sk to NULL at the end of this function is totally pointless. It's not actually 'dead code' technically.
The absolute state of cniles. This is like systemd shills strawmanning everyone else as SysV init fanboys.
What performance gain do you lose from a literal xor call? Sure you might have to copy the address into a register, but I highly doubt it's going to add 1 ms of latency for the function to NULL the pointer when the condition is met.
I can't believe you actually thought this.
*shrug*
I am inclined to treat unnecessary writes as having weight independent of their instruction count.
But the write only occurs when the condition is met: refcount == 0.
Sure there are instances where the socket pointer is no longer used after it is freed, but that is not always, apparently so is the case in OP.
Why not take the performance hit and make contributions easier for everyone instead of forcing them to reverse a bunch of code they are new to?
no, the write needs to happen on every call to sock_put, because every caller of sock_put no longer has need of the pointer.
...
Then why the conditional in `sock_put` itself?
What we know `sock_put` does every call is that it will call a function to decrement refcount and check its value. It will then use the return of this function to determine whether to release the socket or not. We know that it does this every call.
Now, at this point, if the function returns anything but 0, the socket will be released.
What if that function doesn't return 0 however? How does assigning NULL for the pointer to the socket in that situation differ from normal, expected operation?
Valid statement. Everyone should get good.
If people working on the Linux kernel can't write reasonably safe C you sure as hell can't.
I want every single LARPer on this board to show me the C they write so I can tell them why they can't code for shit and need to shut up.
You're making a ton of assumptions here.
Besides, it is reasonably safe.
It's reasonably safe like playing guitar with a sword is reasonably safe.
Then you don't know what reasonable means.
No, you're just really fucking stupid.
Good argument.
This is a really fucking stupid analogy because even if writing C was somehow close to playing the guitar with a sword, the results would be so awesome you'd look like a massive faggot for yelling "JUST USE YOUR HANDS IDIOT" on the rare occasion he actually cuts a string.
[metal intensifies]
No you'd look like a massive faggot when you regularly slice yourself and keep insisting you're fine.
That's a bit misleading. Ada was designed by a team, and the french jew was part of that group.
However, the main reason why I mentioned US army was to prove that Ada isn't simply another meme language that nobody uses. Ada is backed by large entities and it's being actively developed (and the way it's being developed is actually sane! And the standards are available for free), so Ada is future-proofed and useful language.
...
if you're using C, you should use Ada instead, so it makes sense :^)
git.kernel.org
the accepted patch is just the NULL assignment after sock_put().
git.kernel.org
holy keks loonix is finished!!
YEAR OF THE LINUX DESKTOP