3 ms·

this listing is kinda misleading as most cases of sudo/SUID are not "it calls sudo" / "has SUID set" but "if called with sudo/suid it will not drop the elevat

this listing is kinda misleading as most cases of sudo/SUID are not "it calls sudo" / "has SUID set" but "if called with sudo/suid it will not drop the elevated privileges" (or refuses to run). this doesn't mean the table hasn't it's uses but most of the things in it don't allow you to bypass security restrictions by themselves at all even if supper buggy implemented, you always need to already be able to do some privileged operations, like setting suid root, to be able to bypass anything

planede 3y ago
I think the point is that an admin shouldn't configure these executables to be run at a different privilege level, as they are not written with that kind of security consideration in mind at all.
- dathinab 3y ago
  I think it's more like "what you can use in your toolbox for effectively exploiting some privilege escalation vulnerability". SUID is very explicit a tool only to be used for a very few niche use cases with very carefully crafted binaries. Basically a learned sysadmin putting SUID on an arbitrary binary (like most in that list) is enough reason to fire them for gross negligence without any prior warnings even in countries with strong employee protection, it's _that_ big of a "wtf. did you non accidentally do". So you don't really need a list for that. Similar as any small tooling binary (e.g. cat, base64, etc.) is _supposed_ to run under sudo, i.e. it's definitively not a case of "not written with that kind of security considerations in mind". Also for sysadmins this list isn't that useful as there are any number of arbitrary additionally binaries which behave similar on most systems, i.e. the list is very incomplete (and there is no way around that). Similar "being able to read/write a file with the permission the calling user has" is normally not something you care about, the caller is anyway allowed to do so. Or being able to trick a program to work as a form of shell (limited to the users permission) also normally doesn't matter. The user just can spawn it explicitly. Except if you build a toolbox you want to use after finding some (potentially limited) exploit (or if you want to consider what such an toolbox would likely use). Then is list is grate as it makes it easy to find a way to archive something (e.g. shell) with as little custom code (and potentially without it being obviously in monitoring tools).

planede 3y ago

I think the point is that an admin shouldn't configure these executables to be run at a different privilege level, as they are not written with that kind of security consideration in mind at all.

dathinab 3y ago
I think it's more like "what you can use in your toolbox for effectively exploiting some privilege escalation vulnerability". SUID is very explicit a tool only to be used for a very few niche use cases with very carefully crafted binaries. Basically a learned sysadmin putting SUID on an arbitrary binary (like most in that list) is enough reason to fire them for gross negligence without any prior warnings even in countries with strong employee protection, it's _that_ big of a "wtf. did you non accidentally do". So you don't really need a list for that. Similar as any small tooling binary (e.g. cat, base64, etc.) is _supposed_ to run under sudo, i.e. it's definitively not a case of "not written with that kind of security considerations in mind". Also for sysadmins this list isn't that useful as there are any number of arbitrary additionally binaries which behave similar on most systems, i.e. the list is very incomplete (and there is no way around that). Similar "being able to read/write a file with the permission the calling user has" is normally not something you care about, the caller is anyway allowed to do so. Or being able to trick a program to work as a form of shell (limited to the users permission) also normally doesn't matter. The user just can spawn it explicitly. Except if you build a toolbox you want to use after finding some (potentially limited) exploit (or if you want to consider what such an toolbox would likely use). Then is list is grate as it makes it easy to find a way to archive something (e.g. shell) with as little custom code (and potentially without it being obviously in monitoring tools).