[–]▶ No.1033687>>1033773 [Watch Thread][Show All Posts]
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.c
index 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);
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9060cb719e61b685ec0102574e10337fa5f445ea
https://nvd.nist.gov/vuln/detail/CVE-2019-8912
OH NoNOnoNONo.... OHOHH NOOOONOONONO.... BAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAAHA
▶ No.1033715>>1033719 >>1033733
so is this some bad remote exploit that can be used easily or just another shitpost
▶ No.1033719>>1033725 >>1033733 >>1033749
>>1033715
It's a use after free vuln
<wat dat?
>Use-After-Free vulnerabilities are a type of memory corruption flaw that can be leveraged by hackers to execute arbitrary code.
>Use After Free specifically refers to the attempt to access memory after it has been freed, which can cause a program to crash or, in the case of a Use-After-Free flaw, can potentially result in the execution of arbitrary code or even enable full remote code execution capabilities.
▶ No.1033721>>1033723
Already patched in git, just wait for long term to update and everything will be fine again.
▶ No.1033723>>1033724 >>1033734
>>1033721
>wait for long term to update
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.
▶ No.1033724
>>1033723
ah, so it's fucking nothing.
▶ No.1033725>>1033733
>>1033719
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.
▶ No.1033733>>1033735
>>1033715
>>1033719
>>1033725
>Attack Vector (AV): Network
>Attack Complexity (AC): Low
>Privileges Required (PR): None
>User Interaction (UI): None
>Scope (S): Unchanged
>Confidentiality (C): High
>Integrity (I): High
>Availability (A): High
OH NoNOnoNONo.... OHOHH NOOOONOONONO.... BAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAAHA
▶ No.1033734>>1033738
>>1033723
m8, every Linux version 2.8 through 4.20 is vulnerable.
▶ No.1033735
>>1033733
but i dont want to reboot my servers yet
▶ No.1033738>>1033743
>>1033734
the vuln's through sockfs_setattr. that was added in 4.10 and wasn't backported.
▶ No.1033742>>1033749 >>1033798
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.
▶ No.1033743
>>1033738
nice. i use 4.9 on the things that i dont want to reboot
▶ No.1033747>>1033750
>discovered 3 days ago
>still not fixed
I wonder how much (((they))) paid...
▶ No.1033749>>1033753 >>1033755
>>1033742
>implying there aren't worse vulns in windows that only the cia knows about.
>>1033719
>can potentially
Reminder that no one has found an actual exploit yet, for now it's just a benign use-after-free.
▶ No.1033750>>1033751 >>1033755 >>1033798
>>1033747
You literally have the diff of the fix in the OP, wtf?
▶ No.1033751
>>1033750
>fix is available
true. Although I wonder if it shouldn't be made to sock_put instead.
>problem is actually fixed
it hasn't hit linux git repos yet.
▶ No.1033753>>1033755
>>1033749
why would MITRE say Attack Complexity: Low
without at least a good idea of a POC exploit?
▶ No.1033755
>>1033750
The fix is in the git repo but there are no releases with this fix.
>>1033749
>>1033753
>there isn't a POC yet so that means everything is fine
spotted the cniles
▶ No.1033773>>1033774 >>1033775 >>1033780 >>1033798
>>1033687 (OP)
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.
▶ No.1033774>>1033799
>>1033773
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: https://elixir.bootlin.com/linux/v4.20.11/source/net/socket.c#L513
the contract is "if sock->sk is not NULL , then it's good to use", and that contract is broken in https://elixir.bootlin.com/linux/v4.20.11/source/crypto/af_alg.c#L123
▶ No.1033775>>1033792 >>1033798 >>1033799 >>1033881
>>1033773
also
>not a problem
>... given sufficient expertise and discipline
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.
▶ No.1033776>>1033792 >>1033798
SCORE ANOTHER POINT FOR C
▶ No.1033780>>1033792 >>1033798 >>1033799
>>1033773
>This is not an inherrent problem in C
>This is not an inherrent problem in C
>This is not an inherrent problem in C
>This is not an inherrent problem in C
>This is not an inherrent problem in C
>This is not an inherrent problem in C
LOOOOOOOOOOOOOL
▶ No.1033785>>1033791 >>1033797 >>1033798
>open up /usr/src/linux
>add a single line to crypto/af_alg.c (see diff in op)
>fixed gg ez
▶ No.1033791
>>1033785
What about all the other vulnerabilities though? In which files are those?
▶ No.1033792>>1033796 >>1033798 >>1033881
>>1033780
>>1033776
>>1033775
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.
▶ No.1033796>>1033804
>>1033792
>other languages are just as unsafe
nice damage control
▶ No.1033797
>>1033785
#!/usr/bin/env stap
%{
#include <linux/net/sock.h>
%}
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.
▶ No.1033798>>1033799 >>1033820 >>1033881 >>1033902 >>1034028
>>1033742
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)
>>1033773
>>1033775
>>1033776
>>1033780
>>1033792
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.
>>1033750
>>1033785
>fixed gg ez
It's still not an excuse for this embarrassing bug.
▶ No.1033799>>1033800
>>1033774
>ctl+f "sock_put"
>nothing found
Where is `sock_put` defined? How is someone supposed to read that name and think that it would free the pointer in the parameter?
>>1033775
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.
>>1033780
Where in your butt does it hurt?
>>1033798
>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.
Hello, fellow (((white))) programmer. I see you post anime also.
▶ No.1033800>>1033806 >>1033903
▶ No.1033804>>1033820
>>1033796
>damage control is required to defend against an irrelevant meme language.
javascript is objectively more secure than rust
▶ No.1033806>>1033903
>>1033800
/* 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.
▶ No.1033820>>1033823 >>1033826 >>1033863 >>1033875
>>1033798
>thread about c
>ada shill shows up
>>1033804
>more damage control
pathetic
▶ No.1033823>>1033824
>>1033821
>treating a girl like a trap just because her breasts aren't DD
degenerate.
>>1033820
>thread about a class of flaw in a C program
>less-buggy languages are discussed
>this is bad
▶ No.1033824>>1033863
>>1033823
lol you have obvious braindamage
▶ No.1033826>>1033829
>>1033820
>ada shill shows up
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.
▶ No.1033829
▶ No.1033863>>1033944
>>1033820
>>1033824
post popular software written entirely in rust
▶ No.1033873>>1033887
▶ No.1033875>>1033944
>>1033820
I would literally email my bank account login info + my SSN to russian botnet masters before I willingly used a program written in rust
▶ No.1033881>>1033908
>>1033792
>>1033775
>be sjw
>blame your responsibilities on others
>be dev
>blame your bad code on the software
>>1033798
>it's good enough for US army and Boeing
And french space rockets
▶ No.1033887>>1033889
>>1033873
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.
▶ No.1033889>>1033893
>>1033887
woah, if only they had rules against virtual *hugs* none of this would have happened
▶ No.1033893
>>1033889
I am not talking about some queer CoC(k). I am talking about Standards and Practices. Do you know what those are?
▶ No.1033894>>1033896
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.
▶ No.1033896>>1033901
>>1033894
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.
▶ No.1033901>>1033903
>>1033896
brb deleting /crypto
But seriously, are you telling me linus has it wrong? can you show me where the real fix work is happening?
▶ No.1033902>>1034517
>>1033798
>good and beautiful (and white) language
Well you're not wrong, but it was designed by a French Jew. So it's a (((white))) language.
▶ No.1033903>>1033917 >>1034008 >>1034048
>>1033901
Read the function.
>>1033806
>>1033800
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.
▶ No.1033908
>>1033881
>be in medieval hacker's guilde
>everyone uses bent hammers
>one day a journeyman shows off his invention: non-bent hammer
>he's able to build better stuff, with fewer personal injuries!
>the whole guild comes together
>the whole guild beats him black and blue, and makes him apologize to his bent hammer
>the medieval hackers guilde does not blame its tools for self-injury!
▶ No.1033917>>1034048
>>1033903
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.
▶ No.1033934
>>1033689
The “Benny Hill” chase music played in my head while I scrolled through your list anon.
▶ No.1033944
>>1033863
>>1033875
>muh rust
Protip: I didn't mention Rust. Stop building a strawman and admit that you are LARPers
▶ No.1034008
>>1033903
did you tell that to them?
▶ No.1034021>>1034024
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.
▶ No.1034024>>1034025 >>1034033
>>1034021
>Anti-Rustfag OP
I (the OP) am the Rustfag. Gotcha, cniles! I will never stop haunting this board.
▶ No.1034025
>>1034024
forgot my image how embarrassing
▶ No.1034028>>1034517
>>1033798
>US army
Remember the low IQ soldiers? It's like you're one of them.
▶ No.1034033>>1034036
>>1034024
Are you also the OP of >>1026649 ?
▶ No.1034036
>>1034033
Nah. I made this one >>1027067 as a response though.
▶ No.1034048>>1034157
>>1033903
>>1033917
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.
▶ No.1034055>>1034148
>someone makes a thread about Rust vulnerabilities
>Rustniggers are so butthurt they copy OP's image and use his post as a template whenever a C program has a vulnerability
>spend most of the thread shilling Rust yet the moment someone mentions Ada they dogpile him
Why are Rustfags so fucking salty?
▶ No.1034148>>1034150
>>1034055
>one post mentions Rust positively
>8 shit on it
Yes. Clearly there is some serious Rust shilling going on here.
Go and check yourself into a retirement home, cnile.
▶ No.1034150>>1034175
>>1034148
>anyone who doesn't like Rust is a C programmer
The absolute state of Rustfags. This is like systemd shills strawmanning everyone else as SysV init fanboys.
▶ No.1034157>>1034162
>>1034048
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.
▶ No.1034162>>1034166 >>1034176
>>1034157
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.
▶ No.1034166>>1034176
>>1034162
ex. https://elixir.bootlin.com/linux/v4.20.11/source/crypto/af_alg.c#L131
setting sk to NULL at the end of this function is totally pointless. It's not actually 'dead code' technically.
▶ No.1034175>>1034180 >>1034248
>>1034150
>anyone who doesn't like C is a Rust programmer
The absolute state of cniles. This is like systemd shills strawmanning everyone else as SysV init fanboys.
▶ No.1034176>>1034181
>>1034162
>>1034166
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.
▶ No.1034180
>>1034175
>if I switch Rustfag for my super special forced meme this insult will have exactly the same effect
I can't believe you actually thought this.
▶ No.1034181>>1034216
>>1034176
*shrug*
I am inclined to treat unnecessary writes as having weight independent of their instruction count.
▶ No.1034216>>1034240
>>1034181
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.1034240>>1034252
>>1034216
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.
▶ No.1034248>>1034517
>>1034175
>implyin you aren't a SysVinit fanboy
▶ No.1034252
>>1034240
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?
▶ No.1034257>>1034258
>Hurr just like, write good code lmao
▶ No.1034258>>1034259
>>1034257
Valid statement. Everyone should get good.
▶ No.1034259>>1034260
>>1034258
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.
▶ No.1034260>>1034261
>>1034259
You're making a ton of assumptions here.
Besides, it is reasonably safe.
▶ No.1034261>>1034262 >>1034265 >>1034267
>>1034260
It's reasonably safe like playing guitar with a sword is reasonably safe.
▶ No.1034262>>1034263
>>1034261
Then you don't know what reasonable means.
▶ No.1034263>>1034264 >>1034265
>>1034262
No, you're just really fucking stupid.
▶ No.1034264
▶ No.1034265>>1034267 >>1034440
>>1034261
>>1034263
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.
▶ No.1034267
>>1034261
>>1034265
[metal intensifies]
▶ No.1034440
>>1034265
No you'd look like a massive faggot when you regularly slice yourself and keep insisting you're fine.
▶ No.1034464>>1034529
▶ No.1034517>>1034525
>>1033902
>but it was designed by a French Jew
That's a bit misleading. Ada was designed by a team, and the french jew was part of that group.
>>1034028
>implying US army wouldn't care about safety and high availability/fault tolerance
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.
>>1034248
>the only init systems in the existence are SysV and SystemD
▶ No.1034525>>1034527
>>1034517
>shilling Ada in a C thread
▶ No.1034527
>>1034525
if you're using C, you should use Ada instead, so it makes sense :^)
▶ No.1034529
▶ No.1034693
holy keks loonix is finished!!
▶ No.1034948
YEAR OF THE LINUX DESKTOP