4 ms·
This probably happened because they allowed users to execute root commands on their server. Either they quickly shut down the site or someone else did it by shu
by dx034 9y ago
This probably happened because they allowed users to execute root commands on their server. Either they quickly shut down the site or someone else did it by shutting down some servers.
> https://twitter.com/svblxyz/status/969220402768736258 https://twitter.com/svblxyz/status/969220402768736258
- jiggliemon 9y agoOh my. There must be some sort of hall of fame for security vulnerabilities. And this belongs in it. Perhaps they’re passing this command to a secured container? I shouldn’t make excuses for them, but passing root commands to the shell seems too far out there.
- zbentley 9y ago> root commands to the shell seems too far out there You haven't been in software too long, have ya? /s Glibness aside (and I meant the above as a joke, not a personal attack), this is distressingly common to the point of being near-universal in some areas of our industry.
- profmonocle 9y ago> Perhaps they’re passing this command to a secured container? That would indicate they were concerned about shell injection while writing the code. But if that were true, why would they skip the much simpler step of sanitizing/escaping the input?
- chopin 9y agoThis seems more to warrant a business Darwin Award.
- peterwwillis 9y ago> There must be some sort of hall of fame for security vulnerabilities. It's called the Pwnie Awards. https://pwnies.com/ https://pwnies.com/
- cyphar 9y ago> Perhaps they’re passing this command to a secured container? This would still raise my eyebrows, since root inside a container is still something you should avoid unless absolutely necessary (especially if they aren't using user namespaces). Just because containers add some newer security features to regular processes doesn't mean you should forget the security features (POSIX DAC) that were there in the first place.