Sandstorm gets a security review
sandstorm.io
Sandstorm gets a security review
1–10 of 29 posts
Re: Sandstorm gets a security review
#2Many of these problems were in third-party libraries. It would be cool if Sandstorm were written with capability-safe languages like E or Monte or Pony which encode Sandstorm's security properties into the structure of the language.
Re: Sandstorm gets a security review
#3SSRF 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 for the industry that there's no clarity to be had about what it means to have had an assessment, what the different assessors capabilities are, how engagements are scoped, &c. I tend to mistrust organizations that use audit results to claim a clean bill of health --- or anything like that --- but more and more projects do that now, so I don't know how valuable that rule of thumb will remain.
Re: Sandstorm gets a security review
#4Many of these problems were in third-party libraries. It would be cool if Sandstorm were written with capability-safe languages like E or Monte or Pony which encode Sandstorm's security properties into the structure of the language.
Sandstorm is of course a huge fan of capabilities, but unfortunately the available capability-safe languages out there do not currently have the kind of ecosystem needed to be really productive. Instead, Sandstorm compromises by using a capability-based RPC layer, Cap'n Proto, which is heavily based on E's CapTP.
With that said, I don't think it's really true that a capability-based programming language would have avoided these problems.
1. For the Nodemailer problem, no ambient authority was used to split the email into two addresses. A capability-based implementation could have done the same thing. This is more of a langsec issue in that the API was a bit foot-shooty.
2. If the zip implementation were completely rewritten in a capability language, then sure, this vulnerability could have been avoided. It also could have been avoided if zip accepted NUL-delimited filenames rather than newline-delimited. It's not really practical to rewrite the world in another language, unfortunately.
3. SSRF can be avoided using capabilities (forcing the attacker to present a capability, not just an address, to any third-party server they wish to access). Ironically, though, this is a networking issue, not an in-process issue, so what we really need is stricter application of capabilities at the network layer, rather than a capability programming language. Sandstorm is actually willing to push capabilities at the network layer. The trouble is, the network is often used to talk to the rest of the world, which isn't usually capability-based. Hence, we have to make compromises.
4. The Linux kernel bug would maybe have been avoided if the kernel were written in a capability language, but that's a pretty enormous undertaking. Alternatively, it could have been avoided if we forced all our apps to be written in capability languages, but that would mean that no existing codebase could be ported to Sandstorm, which is far too large a cost. That said, I would like to have some special support for apps written in capability languages someday, e.g. to let the user know that this app is extra-safe.
Put simply, going all-capabilities is just not practical today, and we have to make compromises in order to make meaningful progress.
Re: Sandstorm gets a security review
#5It's amusing to see that it got a security overview _after_ it shutdown it's business operations. I am curious if it get a security review when it was a proper company given that their USP is security.
I am still sad that the business didn't work out :( I thought there was going to be a follow up blog on where they ended up getting acqui-hired?
Re: Sandstorm gets a security review
#6SSRF 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 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.
Re: Sandstorm gets a security review
#7It's amusing to see that it got a security overview _after_ it shutdown it's business operations. I am curious if it get a security review when it was a proper company given that their USP is security. I am still sad that the business didn't work out :( I thought there was going to be a follow up blog on where they ended up getting acqui-hired?
We actually didn't get acquihired -- Sandstorm is still an independent company, and I'm still the CEO and majority shareholder, but we no longer have paid employees. We're continuing to work on Sandstorm, and have even pushed some major new features in the last couple weeks (e.g. the Powerbox UI for connecting apps to each other and to the outside world with explicit user permission).
What did happen is we're all getting new full-time jobs elsewhere, since we aren't making enough money to pay ourselves. Most of us actually haven't started our new jobs yet (taking a little break) but we'll have a blog post when it happens in a couple weeks.
Re: Sandstorm gets a security review
#8SSRF 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…
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.
Re: Sandstorm gets a security review
#9SSRF 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.
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?
Re: Sandstorm gets a security review
#10Earlier 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…
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 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...