Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sandstorm gets a security review

sandstorm.io

Post reply on HN
Print view View original

11–20 of 29 posts

Re: Sandstorm gets a security review

#11

Post by kentonv »

simplehuman wrote: post #9
kentonv wrote: post #6

Earlier quoted context omitted.

> 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 partic…

> 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?

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.

Re: Sandstorm gets a security review

#12

Post by tptacek »

kentonv wrote: post #11
simplehuman wrote: post #9

Earlier quoted context omitted.

> 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?

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 guarantee…

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?

Re: Sandstorm gets a security review

#13

Post by kentonv »

tptacek wrote: post #12
kentonv wrote: post #11

Earlier quoted context omitted.

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 guarantee…

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?

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.

Re: Sandstorm gets a security review

#14

Post by kordless »

simplehuman wrote: post #9
kentonv wrote: post #6

Earlier quoted context omitted.

> 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 partic…

> 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?

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.

Re: Sandstorm gets a security review

#15

Post by djrogers »

simplehuman wrote: post #9
kentonv wrote: post #6

Earlier quoted context omitted.

> 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 partic…

> 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?

> 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.

Re: Sandstorm gets a security review

#16

Post by kevinr »

kentonv wrote: post #6
tptacek wrote: post #3

SSRF is an extremely bad vulnerability; it's usually game-over on penetration tests. The zip-file path validation bug is also bad. I'm pretty ambivalent about these "we got a security review, they said we're good" updates, even when they include the actual contents of the report (the final contents of the reports you actually see are almost always negotiated between the client and the testers). It is a real problem f…

> 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 partic…

> 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.

Re: Sandstorm gets a security review

#17

Post by kevinr »

kentonv wrote: post #10
tptacek wrote: post #8

Earlier quoted context omitted.

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.

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 pr…

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."

Re: Sandstorm gets a security review

#18

Post by homakov »

tptacek wrote: post #3

SSRF is an extremely bad vulnerability; it's usually game-over on penetration tests. The zip-file path validation bug is also bad. I'm pretty ambivalent about these "we got a security review, they said we're good" updates, even when they include the actual contents of the report (the final contents of the reports you actually see are almost always negotiated between the client and the testers). It is a real problem f…

> SSRF is an extremely bad vulnerability; it's usually game-over on penetration tests

It's usually not. What can you do via HTTP protocol inside the network? Check out ssrf bible.

Re: Sandstorm gets a security review

#19

Post by kentonv »

kevinr wrote: post #17
kentonv wrote: post #10

Earlier quoted context omitted.

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 pr…

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."

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