4 ms·

They built a list of every pre/post command that had been in actual use (by looking through the source tree for clients of that service, naturally), and then tu

They built a list of every pre/post command that had been in actual use (by looking through the source tree for clients of that service, naturally), and then turned it into a hard-coded check list. The program would now refuse any pre/post commands unless it was one of those already known to it. This change patched the hole It didn't really patch the hole so much as it moved the hole to every command that was in that whitelist of commands that were ok to run as root. The author doesn't say when this was, but nowadays there are almost certainly better ways to solve this without letting these pre/post setup commands run as root.

tyingq 5y ago
Agree, and chances are one of the whitelisted things would allow you to bootstrap something else. I've seen attempts to grant limited sudo access by whitelist, and it's usually easy to get a shell one way or the other.
yjftsjthsd-h 5y ago
I like to think that this was the mitigation that they applied while they more carefully whittled down the list of commands to zero. I can dream:)
- deleted 5y ago
  [deleted]
ericbarrett 5y ago
These were pre- and post-deploy jobs for a service (?), so I'm guessing they were hard-coded as the whole command string.
hutzlibu 5y ago
"but nowadays there are almost certainly better ways to solve this without letting these pre/post setup commands run as root." How? The only clean solution I see (now or anytime in the past), would be to rewrite that "Actual Business Stuff" using the whole. But that is expensive, maybe very expensive (I think this was clients code and going around and telling them to change maybe complex code of theirs ... is not something you want or can afford to do) So they just patched the hole up as much as they could do. So I do consider it a patch(especially if the hardcoded commands as strings are verified commands and do not change or induce something else). Just maybe none that provides full security. But when you look at the state of things in IT in general ... I would say, there is indeed improvement, if at least gaping holes like this one gets fixed.
- Johnny555 5y ago
  How? No way to answer that without knowing why it needs root. especially if the hardcoded commands as strings are verified commands and do not change or induce something else But now that invoked program becomes another weak link that can be exploited. And you don't even know what those innvoked commands are so don't know if anything can be hardcoded other than the path to the executable. Yes, it's an improvement in security, but it's only one step that probably won't be revisited until, for example, someone finds out that there's an easily exploited buffer overflow in one of those invoked programs that run as root.

tyingq 5y ago

Agree, and chances are one of the whitelisted things would allow you to bootstrap something else. I've seen attempts to grant limited sudo access by whitelist, and it's usually easy to get a shell one way or the other.

yjftsjthsd-h 5y ago

I like to think that this was the mitigation that they applied while they more carefully whittled down the list of commands to zero. I can dream:)

deleted 5y ago
[deleted]

ericbarrett 5y ago

These were pre- and post-deploy jobs for a service (?), so I'm guessing they were hard-coded as the whole command string.

hutzlibu 5y ago

"but nowadays there are almost certainly better ways to solve this without letting these pre/post setup commands run as root." How? The only clean solution I see (now or anytime in the past), would be to rewrite that "Actual Business Stuff" using the whole. But that is expensive, maybe very expensive (I think this was clients code and going around and telling them to change maybe complex code of theirs ... is not something you want or can afford to do) So they just patched the hole up as much as they could do. So I do consider it a patch(especially if the hardcoded commands as strings are verified commands and do not change or induce something else). Just maybe none that provides full security. But when you look at the state of things in IT in general ... I would say, there is indeed improvement, if at least gaping holes like this one gets fixed.

Johnny555 5y ago
How? No way to answer that without knowing why it needs root. especially if the hardcoded commands as strings are verified commands and do not change or induce something else But now that invoked program becomes another weak link that can be exploited. And you don't even know what those innvoked commands are so don't know if anything can be hardcoded other than the path to the executable. Yes, it's an improvement in security, but it's only one step that probably won't be revisited until, for example, someone finds out that there's an easily exploited buffer overflow in one of those invoked programs that run as root.