It comes from Greg K-H and Linux both being super dismissive of security vulnerabilities, considering them "just another bug nothing special" and not prioritization them. There has never even been an effort to audit and clean up the code for issues like OpenBSD did.
A lot of anti-proprietary folks will say Linux is more secure than Windows/Mac, but it's not true. I work as a a pen tester and taking over most linux machines is generally much easier than you would think, because of issues like these that just don't get fixed or prioritized.
People will disagree with me out of principle, but I'm not wrong. When you have developers that don't take security seriously as they should, you won't have a secure product.
So first you have to get a user account. The code is unusable as a remote exploit. It is in a kernel driver that is not loaded by default and can't be loaded in all Linux versions without the relevant hardware being installed. Debian versions for example check if the relevant hardware (iSCSI) is present and won't load if it isn't (not likely IMO). So in other words more of a theoretical "bug" set.
So you can't use it unless you are already a user. Then it takes multiple hacks to enable the root acces
Chained exploits exist. And these types of exploits are generally not aimed at home users, but instead at companies with servers that handle thousands to millions of users content, much MUCH more valuable targets. Chain this with an exploit in a web server or some other service running on the server, and its a total pwn. And That's the point. YOU may not care AS AN END USER, but as someone who manages globally distributed infrastructure to support end users such as yourself, you're damn sure I do care to know about these things and their implications.
Chain this with an exploit in a web server or some other service running on the server, and its a total pwn.
Firstly, the module won't be loaded if the hardware isn't present and you need root privileges to load the module. The article claims that the module is always loaded on Red Hat, but I can clearly see that it isn't present on my CentOS systems.
Secondly, you should be running SELinux on your web server, which will prevent this exploit.
What hardware are you talking about? iSCSI is a way to expose a block device for network-based access. The only hardware required is a CPU, RAM and NIC. You can export a ramdisk over iSCSI if you want.
Also, the article doesn't say the relevant kennel module is loaded on RH-based distros: "Whether a normal user can load the vulnerable kernel module varies. They can, for instance, on all Red Hat based distros that GRIMM tested, he said."
If something like SystemD lets you use iSCSI to access a remote disk, your system is vulnerable.
SELinux, yeathe thin that all turoriks ( older than about 2 years) recomend the you turn off or run in oermisive mode just to cut down on log volume and rhe arational fault. Unfortunatly alot of people have ben pre coditioned to do one thing when they see any message saying anything about SELinux, us to turn it off, or if they have forgotten how to google it. This will slowl change as the okder tutorials and forum posts get down ranked by google{ hopefully), but untill then I fear SELinux might not be that
I would hope that the use of SELinux is improving.
When I recently migrated some servers from CentOS 6 to CentOS 7, I put in the effort to make then run with SELinux in enforcing mode. I would hope that other administrators are doing this too.
iSCSI is an abomination. Wrapping up blocks in TCP/IP packets so you can send them on the same layer two network segment (which is what happens in 99.999% of use case scenarios) is obscene.
I could also wax lyrical terrible it is without per channel pause when you have anything other than a one to one host to storage ratio. That was several weeks of my life I am not getting back working that shit out. Fun fact it's why per channel pause was added to Data Center Ethernet when the whole FCoE was a thing. Becau
The relevant hardware is an external network attached subsystem...
Yes, there CAN be offload adapters, BUT those are somewhat uncommon outside of fairly high end systems. AND the iSCSI subsystem is still separate from the kernel modules for the adapter.
I think the "debian" feature you're referring to is udev... It's not unique to debian or "debian like" systems.
So first you have to get a user account. The code is unusable as a remote exploit. It is in a kernel driver that is not loaded by default and can't be loaded in all Linux versions without the relevant hardware being installed.
The only hardware iSCSI needs is a network card, similar to SMB or NFS.
I guess most machines (including yours) have that hardware installed and enabled.
For a rebuttal of the 'opinion' above, see the following posting from a few years back: Why Linus is right (as usual) [erratasec.com].
And making the statement
I work as a a pen tester and taking over most linux machines is generally much easier than you would think
doesn't provide a lot of credibility, no information about the function of the respective Windows/Mac or Linux machines that were pen tested. If the Windows/Mac were servers managed by a competent admin and the Linux machines were not managed at all, (just desktops with users that were supposed to hit the update button but postponed it indefinitely) that would mak
People generally don't find security holes in OpenBSD because it is far less popular than Linux. Just because they aren't reported does not mean they don't exist.
I accept that Linux could have a bigger focus on security, but find me a significant OS that doesn't have privilege escalation exploits. No one has figured out how to stop those.
Your security model needs to assume that a hacker who has access to your system also has access to root, otherwise your security model is broken.
Your post shows that you have no clue what the term "Security through obscurity" means. For the password analogy to work you would have to be unable to log in even though you know the correct password.
You are wrong. The claim was never "Linux is more secure". The claim was always "with competent system administration, Linux is more secure". And that is where you fail. For example, removing kernel modules not needed falls under "basics".
I don't think it does come under "basics". I would call that "paranoid measures that have marginal use" Next update, they just get put back anyway. Or the next admin deletes your script when you leave
It comes from Greg K-H and Linux both being super dismissive of security vulnerabilities, considering them "just another bug nothing special" and not prioritization them. There has never even been an effort to audit and clean up the code for issues like OpenBSD did.
Multiple organizations have conducted security related code reviews and contributed patches for the Linux kernel.
I work as a a pen tester and taking over most linux machines is generally much easier than you would think, because of issues like these that just don't get fixed or prioritized.
You are full of shit. Remote exploits are rarely enabled by kernel vulnerabilities. Local privilege escalation is a dime a dozen on any non-niche OS.
People will disagree with me out of principle, but I'm not wrong. When you have developers that don't take security seriously as they should, you won't have a secure product.
If you find yourself in a position where developers a required to take security seriously in order to create a secure product you've already failed.
Agree. Maybe respondent watched Mr Robot, that's as far as they got with pen testing.
Remote exploits are rarely enabled by kernel vulnerabilities.
Right. When it does happen every few years then it's instant, industry wide news
Local privilege escalation is a dime a dozen on any non-niche OS.
If you think that then you should try it yourself. See if you can manage it with a CVE that's older than your last system update.
If you find yourself in a position where developers a required to take security seriously in order to create a secure product you've already failed.
Ah no, that's just not true, security is a culture that goes all the way up and down the stack. For example, A PHP hack who doesn't sanitize their SQL strings is a clear and present danger.
Linux has had terrible security for 10+ years now (Score:5, Interesting)
It comes from Greg K-H and Linux both being super dismissive of security vulnerabilities, considering them "just another bug nothing special" and not prioritization them. There has never even been an effort to audit and clean up the code for issues like OpenBSD did.
A lot of anti-proprietary folks will say Linux is more secure than Windows/Mac, but it's not true. I work as a a pen tester and taking over most linux machines is generally much easier than you would think, because of issues like these that just don't get fixed or prioritized.
People will disagree with me out of principle, but I'm not wrong. When you have developers that don't take security seriously as they should, you won't have a secure product.
Re: (Score:3, Informative)
So first you have to get a user account. The code is unusable as a remote exploit. It is in a kernel driver that is not loaded by default and can't be loaded in all Linux versions without the relevant hardware being installed. Debian versions for example check if the relevant hardware (iSCSI) is present and won't load if it isn't (not likely IMO). So in other words more of a theoretical "bug" set.
So you can't use it unless you are already a user. Then it takes multiple hacks to enable the root acces
Re:Linux has had terrible security for 10+ years n (Score:5, Interesting)
Chained exploits exist. And these types of exploits are generally not aimed at home users, but instead at companies with servers that handle thousands to millions of users content, much MUCH more valuable targets. Chain this with an exploit in a web server or some other service running on the server, and its a total pwn. And That's the point. YOU may not care AS AN END USER, but as someone who manages globally distributed infrastructure to support end users such as yourself, you're damn sure I do care to know about these things and their implications.
Re: (Score:3)
Firstly, the module won't be loaded if the hardware isn't present and you need root privileges to load the module. The article claims that the module is always loaded on Red Hat, but I can clearly see that it isn't present on my CentOS systems.
Secondly, you should be running SELinux on your web server, which will prevent this exploit.
Re:Linux has had terrible security for 10+ years n (Score:4, Informative)
What hardware are you talking about? iSCSI is a way to expose a block device for network-based access. The only hardware required is a CPU, RAM and NIC. You can export a ramdisk over iSCSI if you want.
Also, the article doesn't say the relevant kennel module is loaded on RH-based distros: "Whether a normal user can load the vulnerable kernel module varies. They can, for instance, on all Red Hat based distros that GRIMM tested, he said."
If something like SystemD lets you use iSCSI to access a remote disk, your system is vulnerable.
Re: (Score:2)
I read the article again.
It claims that there is a known way to get kernel modules installed, but for this specific case, it requires the rdma-core package to be installed.
On CentOS, if you have a no-GUI webserver, then the rdma-core package isn't installed.
So this exploit has another dependency: installation of the rdma-core package and almost certainly, SELinux would need to be disabled.
Re: (Score:1)
Re: (Score:2)
I would hope that the use of SELinux is improving.
When I recently migrated some servers from CentOS 6 to CentOS 7, I put in the effort to make then run with SELinux in enforcing mode. I would hope that other administrators are doing this too.
Re: (Score:3)
iSCSI is not a hardware feature. It's a network block storage protocol, which I happen to use at my home.
But sure, 99.999% of Linux users surely don't use it.
Re: (Score:2)
iSCSI is an abomination. Wrapping up blocks in TCP/IP packets so you can send them on the same layer two network segment (which is what happens in 99.999% of use case scenarios) is obscene.
I could also wax lyrical terrible it is without per channel pause when you have anything other than a one to one host to storage ratio. That was several weeks of my life I am not getting back working that shit out. Fun fact it's why per channel pause was added to Data Center Ethernet when the whole FCoE was a thing. Becau
Re: (Score:3)
The relevant hardware is an external network attached subsystem...
Yes, there CAN be offload adapters, BUT those are somewhat uncommon outside of fairly high end systems. AND the iSCSI subsystem is still separate from the kernel modules for the adapter.
I think the "debian" feature you're referring to is udev... It's not unique to debian or "debian like" systems.
Re: (Score:2)
So first you have to get a user account. The code is unusable as a remote exploit. It is in a kernel driver that is not loaded by default and can't be loaded in all Linux versions without the relevant hardware being installed.
The only hardware iSCSI needs is a network card, similar to SMB or NFS.
I guess most machines (including yours) have that hardware installed and enabled.
Re: (Score:2)
apple.com /s
Re: (Score:1)
I work as a a pen tester and taking over most linux machines is generally much easier than you would think
doesn't provide a lot of credibility, no information about the function of the respective Windows/Mac or Linux machines that were pen tested. If the Windows/Mac were servers managed by a competent admin and the Linux machines were not managed at all, (just desktops with users that were supposed to hit the update button but postponed it indefinitely) that would mak
Re: (Score:2)
Re: (Score:2)
I accept that Linux could have a bigger focus on security, but find me a significant OS that doesn't have privilege escalation exploits. No one has figured out how to stop those.
Your security model needs to assume that a hacker who has access to your system also has access to root, otherwise your security model is broken.
Re: Apples to pears. (Score:2)
Re: (Score:2)
You are wrong. The claim was never "Linux is more secure". The claim was always "with competent system administration, Linux is more secure". And that is where you fail. For example, removing kernel modules not needed falls under "basics".
Re: Linux has had terrible security for 10+ years (Score:1)
Re: (Score:3, Insightful)
It comes from Greg K-H and Linux both being super dismissive of security vulnerabilities, considering them "just another bug nothing special" and not prioritization them. There has never even been an effort to audit and clean up the code for issues like OpenBSD did.
Multiple organizations have conducted security related code reviews and contributed patches for the Linux kernel.
I work as a a pen tester and taking over most linux machines is generally much easier than you would think, because of issues like these that just don't get fixed or prioritized.
You are full of shit. Remote exploits are rarely enabled by kernel vulnerabilities. Local privilege escalation is a dime a dozen on any non-niche OS.
People will disagree with me out of principle, but I'm not wrong. When you have developers that don't take security seriously as they should, you won't have a secure product.
If you find yourself in a position where developers a required to take security seriously in order to create a secure product you've already failed.
Re: (Score:2)
You are full of shit.
Agree. Maybe respondent watched Mr Robot, that's as far as they got with pen testing.
Remote exploits are rarely enabled by kernel vulnerabilities.
Right. When it does happen every few years then it's instant, industry wide news
Local privilege escalation is a dime a dozen on any non-niche OS.
If you think that then you should try it yourself. See if you can manage it with a CVE that's older than your last system update.
If you find yourself in a position where developers a required to take security seriously in order to create a secure product you've already failed.
Ah no, that's just not true, security is a culture that goes all the way up and down the stack. For example, A PHP hack who doesn't sanitize their SQL strings is a clear and present danger.
Re: (Score:1)
Greg K-H and Linux
Not a good start.
People will disagree with me out of principle, but I'm not wrong.
Well, actually, you are wrong. I mean, you got the name of Linus wrong in the very first sentence.
If you can't even bother getting that detail right... The rest of your post is basically an appeal to yourself.
Not impressed.
I work as a a pen tester ? (Score:1)
I totally believe you are a a pen tester