[kentonv]

> SSRF is an extremely bad vulnerability;

I'm not sure this blanket statement -- probably derived from the world of SaaS -- is necessarily helpful in the context of Sandstorm. Keep in mind that Sandstorm is meant to host internal-facing services. One doesn't normally expect that an external attacker will have authority to create a full user account and install their own apps, which is necessary to exploit this particular vulnerability. (It's actually the app, not Sandstorm itself, making the requests; Sandstorm failed to prevent apps from making requests to the private network.)

On Sandstorm Oasis, the service we run which does allow arbitrary visitors to create full user accounts (possibly the only Sandstorm server worldwide that does this), the SSRF did not provide access to anything sensitive.

I'm of course not saying it wasn't a problem -- I described the severity as "high" in the post.

> I'm pretty ambivalent about these "we got a security review, they said we're good" updates

To be clear, I never made any such claim. The post reports facts, which is that a security review occurred, and some pretty tricky-to-find bugs were found and fixed. I'm sure there are other bugs to be found.

I'd very much like to receive further reviews from other parties.

[simplehuman]

> Keep in mind that Sandstorm is meant to host internal-facing services.

If the goal is not to run internet facing services, why is the project so focused on security? In the enterprise, there is already F5, NIDS etc so nobody can get in. Is sandstorm trying to prevent employees from hacking the company or something?

[kentonv]

We don't think monolithic firewall-based security has been very successful at preventing hacks. Our goal is to create an environment that involves much more fine-grained separations, and enforces security properties at the platform level so that bugs in apps are largely mitigated. We want you to be able to deploy apps without having to security-review them first, which means the platform itself must provide guarantees.

Arguably an app-driven SSRF is a pretty big problem in that threat model. I think we missed it earlier because we imagine a future world where people don't expose unauthenticated services on the internal network and rely on their firewall to protect them. Of course, we need to keep in mind that the existing world isn't going to go away when people deploy Sandstorm and so we need to handle both worlds gracefully.

Another point to make is that we do envision use cases where someone sets up a personal server and invites their friends to it to chat and collaborate -- usually as "visitors" (can't install apps), but sometimes as full users sharing one server. Typically you'd only invite trusted friends to be "full users", though, unless you are running a hosting service. Hosting services (like ours) ought to be extra-careful with multiple layers of security.

[tptacek]

That's an argument people have been making for at least 10 years, and it falls apart pretty quickly: how secure do you think most companies would be if you opened up all their AWS security groups to the world?

[kentonv]

Right. As I said, it's not the case today, for most companies (with Sandstorm ourselves, as a company, being an exception). With most infrastructure people use today, leaving services unauthenticated makes life easier, so people are going to do it.

One of the goals of Sandstorm is to make it easy to connect services to each other where desired without making them open to the world, with the goal of solving this sort of problem.

[djrogers]

> In the enterprise, there is already F5, NIDS etc so nobody can get in.

Completely aside from the fact that there are thousands of breeches that prove that statement wrong, one must also be concerned with insiders, credential theft attacks, and tons of other threats that a monolithic 'build a wall' security model doesn't solve.

[kordless]

Sandstorm's model is close to what I call MSaaS, or managed software as a service. These services can be managed as a SaaS service on prem, yet still be hosted inside a company's network. The equivalence can come from companies selling software "services" by doing deployments of different required SaaS "packages" which can be accessed as a whole.

I think it's extremely important to highlight the security requirements for this type of business model deployment and don't think that focusing on security shouldn't be occurring just because it's running code in a private location.

[kevinr]

> Keep in mind that Sandstorm is meant to host internal-facing services.

This is not really obvious from any of your marketing copy or documentation, nor would it be a realistic expectation if it were. I think you need to secure like your users don't know or understand your intentions.

[kentonv]

Unfortunately, we've had trouble expressing what Sandstorm is in web page format, because it's so different from anything else out there. People tend try to pattern-match it to something else and get the wrong idea. This has been a constant struggle. But once you actually try it, I think it becomes a lot clearer.

There are literally two Sandstorm servers in the world that allow self-service creation of full user accounts (one of which is run by us). The rest are by invite only, which means that to launch an attack, you'd first have to trick the server admin into giving you an invite. That's certainly not impossible, but it is a significant barrier.

That said, again, I do agree this was a real problem -- we do think it's bad if invited users can compromise the server or its network. I'm not trying to claim otherwise, I'm just trying to put everything into full perspective and avoid hyperbole.

[tptacek]

That's true only to the extent that anything that can trigger SSRF is CSRF-safe. I'm not familiar with Sandstorm, but I assume you're saying that's the case here.

[kentonv]

Sandstorm mitigates most CSRF in apps by hosting each grain session on a randomly-generated subdomain. That is, every time a user opens an app instance, they talk to it on a new unguessable subdomain.

Granted, a network-level attacker who can sniff the victim's DNS resolutions could discover the hostname and launch a CSRF attack. But, that's a much, much higher barrier than normal. (And the app's own internal CSRF protection still applies.)

(We're also working on some other tricks to mitigate CSRF for defense-in-depth, e.g. relying on Chrome's use of the "Origin" header, though there are currently some issues blocking rolling this out.)

I think you would find Sandstorm interesting.

Here's more documentation on our security model: https://docs.sandstorm.io/en/latest/using/security-practices...

And more generally Sandstorm's fine-grained containerization model, which among other things mitigates many app vulnerabilities: https://sandstorm.io/how-it-works

And here's a list of actual known app vulnerabilities we've mitigated through our model (before we knew about them): https://docs.sandstorm.io/en/latest/using/security-non-event...

[kevinr]

URLs aren't normally considered sensitive by users.

"Hey Carol, can you send me the link you're using to the wiki? Mine isn't working."

[kentonv]

The users don't actually see the session hosts since they're in an iframe.

[mentat]

Understanding the importance and impact of pivot points in long term penetration seems to undermine "it's internal so it doesn't matter". Not that you're alone in that view but the "hard crunchy shell, soft chewy center" security model needs to die...