Here's all 4 exploits for yesterday's 6.6 LTS kernel in one tweet
Posted by eggbart_forgetfulsea@reddit | linux | View on Reddit | 28 comments
Posted by eggbart_forgetfulsea@reddit | linux | View on Reddit | 28 comments
BinkReddit@reddit
I love Linux, but I run OpenBSD for more security critical tasks.
ranjop@reddit
… that gets 0.01% of the attention of Linux kernel…
Bubbly_Extreme4986@reddit
Trisquel still running kernel 5.5 libre…..
nmateofr@reddit
Does that mean 5.5 should be a safer bet than 6.X or 7.X ?
2rad0@reddit
safe from bugs introduced during a bad backport at least, because of how old it is they don't backport that far anymore.
Bubbly_Extreme4986@reddit
Not really this doesn’t mention exploits found in older kernels. 6.6 is already quite old
daHaus@reddit
It says tweet not found
natermer@reddit
Brad Spengler @spendergrsec Apr 3 says:
So people understand what this is... these are just syscalls. Typically done from C language, but they can be run from pretty much any language with lower level bindings. They are used to manipulate extended attributes on Linux file systems. Do "man fsetxattr" and other similar commands for the rest of them.
Extended attributes don't get a lot of attention because most of the time users don't interact with them directly. They are just ways to store extra metadata about files. Similar to alternative data streams on Windows NTFS or Resource Forks for older Apple HFS+. Apple uses extended attributes nowadays as well.
2rad0@reddit
My paranoid decision to always disable extended attributes continues to pay dividends.
They also enable file capabilities which is a way to gain root privileges without using normal method via the setuid bit.
mrtruthiness@reddit
Are you certain? Almost all recent sandboxing environments/tools depend on xattr to work correctly. e.g. You've broken some of the sandboxing that flatpak (really, bubblewrap) relies on.
2rad0@reddit
I wrote my own sandbox that relies only on setuid 0
mrtruthiness@reddit
Which many would consider a security issue. See the discussion around firejail and bubblewrap without usernamespace ... which both require setuid root.
2rad0@reddit
Elevating privileges in general is a security issue by itself and doesn't matter how you do it, only how you mitigate the potential disasters. User namespaces is another security issue that will never exist in any of my kernels.
I've been doing this for a long time well before flatpaks existed, I'm well aware of the potential issues and have spent many months developing the correct strategy to deal with it. The biggest hazard is not the capabilities, as long as you drop everything you don't need while doing a specific action (e.g. holding CAP_DAC_OVERRIDE is a REALLY easy way to shoot yourself in the foot). The dangerous part is your program logic and how it sets up the environment with bind mounts and whatever else you're going to be doing. Every argument against using setuid relies solely on CVE numbers, and pushes forward weird contraptions that are also security issues.
Megame50@reddit
This poster is an infamous tool.
mrtruthiness@reddit
You just don't like it when someone laughs at laughable Linux security issues.
natermer@reddit
Also: Killing the messenger isn't going to make the kernel more secure.
Megame50@reddit
He isn't the messenger. His whole shtick is not reporting vulnerabilities until they are rediscovered.
natermer@reddit
He is very literally the messenger.
The entire topic was started by his tweet.
eggbart_forgetfulsea@reddit (OP)
https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.133
Megame50@reddit
The revert mail on the mailing list has more context:
A tweet that doesn't identify the bug is hardly responsible disclosure, is it? This is basically the same thing he's been doing for years, but being a little less cryptic permits him the report credit I guess.
The tweet also has an error fwiw, fsetxattr call is missing the xattr name.
eggbart_forgetfulsea@reddit (OP)
It's the kernel. Bugs are bugs after all, and obfuscating security issues in cryptic commit messages is the norm.
Linux developers should use this as an opportunity to look at their own practices and improve. They don't need online defenders playing the man instead of the ball.
saltyjohnson@reddit
Huh?
cornmonger_@reddit
a fun little chat between him and linus
Infamous_Guard5295@reddit
honestly kernel exploits are scary but this drama is peak linux community lol. linus has zero patience for security researchers who act like they're doing us a favor by being condescending about it. like yeah the bugs suck but maybe don't be a dick about disclosure timing
vancha113@reddit
Not much use without further info?
eggbart_forgetfulsea@reddit (OP)
The kernel's stable development process is laughably bad. This mess was caused by an backport of this:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a71874379ec8c6e788a61d71b3ad014a8d9a5c08
Which turned into this:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5a1e865e51063d6c56f673ec8ad4b6604321b455
Enough nonsense makes it into stable trees it calls into question whether the maintainers are sufficiently testing what they release or looking properly at it at all. This is the latest severe example.
Prior-Advice-5207@reddit
Good thing all my machines run some kind of BSD whew
eggbart_forgetfulsea@reddit (OP)
https://lwn.net/Articles/1066507/