4 ms·

You said it: If you are not explicitly on the business of providing external access to your machine, the privesc isn't your problem (it's a problem, and it's ba

You said it: If you are not explicitly on the business of providing external access to your machine, the privesc isn't your problem (it's a problem, and it's bad, though), it's the fact that anybody could exploit the privesc in the first place.

Senji 10y ago
If you are a client of such a busines you would have to care too.
- qwertyuiop924 10y ago
  Of course you care about this sort of flaw: you need as many lines of defense as possible. But if anybody can exploit it in the first place, you've already got a major security hole.
throwaway2048 10y ago
no, because a bug like this turns any code execution exploit into remote root...
- tptacek 10y ago
  The point is that code execution is almost always remote root, because lots of bugs like this exist. Also: most engineers overestimate the relative value of root vs. simple inside-the-VPC code execution, which is almost always gameover anyways.
  - patio11 10y ago
    Thomas has elaborated on this a few times over the years, but to elaborate for people who weren't around for those conversations: if you can make an HTTP request from inside the firewall, which probably doesn't require root, you can pivot the attack to a variety of internal services which are not designed with security in mind. That could let you e.g. reconfigure networking appliances, grab credentials to internal or external services from DevOps-y credential stores, grab all manner of business secrets, pivot to direct SQL access to the DB laundered through e.g. internal analytics dashboards or admin tooling, etc.