4 ms·
If some person has the ability to control ports and execute code, you are one kernel vulnerability away from complete disaster.
by ReaLNero 4y ago
If some person has the ability to control ports and execute code, you are one kernel vulnerability away from complete disaster.
- School-Cotton 4y agoYes, but that’s not a good argument for removing layers of defense.
- _ph_ 4y agoIt is a good argument against keeping bad layers of defense, if it is trivial to make better ones.
- sph 4y agoIt's not a bad layer, it's quite effective. If you do not have root, there is no way to access 1-1024 period.
- _ph_ 4y agoIt is not effective, if this is not the type of "attack" you have to defend against vs. plugging a Raspberry Pi with some nefarious software into the same network. But yes, I think preventing random users from opening ports listening to the world is a good idea, I don't think it should be done this way. First of all, it possibly should affect all ports and there should be a configuration file which regulates which user can open which port. Tying that privilege to the root id is the worst possible way, as discussed. The right way is to define a mapping, which userid may open a port below 1024 or at all. That would also ban e.g. a malware to operate a backdoor server on a non-privileged port. And would mean that no service requires to have root rights. These things you could do to improve, not weaken the initial concept.
- worthless-trash 4y agoFrom my limited experience, most hackers dont care for kernel, once they have your services, they have the data.. thats enough.
- philsnow 4y agoattackers also want persistence and lateral movement, and privileged/kernel access makes that way easier