6 ms·

Sandstorm gets a security review

107 points by bruo 10y ago

BuuQu9hu 10y ago
Many 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.
- kentonv 10y ago
  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.
tptacek 10y ago
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 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.
- kentonv 10y ago
  > 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 10y ago
    > 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?
the_common_man 10y ago
It'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?
- kentonv 10y ago
  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.
  - wingless 10y ago
    I wonder if you (core devs) could get full-time jobs to integrate Sandstorm with company infrastructures.
    - kentonv 10y ago
      Probably not -- finding a company willing to hire someone to deploy Sandstorm for them sounds at least as hard as finding a company willing to buy Sandstorm as a product and pay Sandstorm Inc. for support, which is what we had trouble with. I'm sure they exist but enterprise sales are non-trivial. :/ That said, my new employer is a big user of Cap'n Proto, a sub-project of Sandstorm.
erichocean 10y ago
Was Cap'n Proto audited as part of this?
- kentonv 10y ago
  I'm honestly not sure. I haven't been able to read the original report (which is not in English). My guess is that it did not receive direct attention. I note that Cap'n Proto did receive some scrutiny from security guru (and personal friend) Ben Laurie in the past: https://capnproto.org/news/2015-03-02-security-advisory-and-integer-overflow-protection.html https://capnproto.org/news/2015-03-02-security-advisory-and-... My next job is at a company that is a heavy user of Cap'n Proto, so expect more progress on this front going forward.

107 points by bruo 10y ago

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

kentonv 10y ago
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.

tptacek 10y ago

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

kentonv 10y ago
> 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 10y ago
  > 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?

the_common_man 10y ago

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

kentonv 10y ago
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.
- wingless 10y ago
  I wonder if you (core devs) could get full-time jobs to integrate Sandstorm with company infrastructures.
  - kentonv 10y ago
    Probably not -- finding a company willing to hire someone to deploy Sandstorm for them sounds at least as hard as finding a company willing to buy Sandstorm as a product and pay Sandstorm Inc. for support, which is what we had trouble with. I'm sure they exist but enterprise sales are non-trivial. :/ That said, my new employer is a big user of Cap'n Proto, a sub-project of Sandstorm.

erichocean 10y ago

Was Cap'n Proto audited as part of this?

kentonv 10y ago
I'm honestly not sure. I haven't been able to read the original report (which is not in English). My guess is that it did not receive direct attention. I note that Cap'n Proto did receive some scrutiny from security guru (and personal friend) Ben Laurie in the past: https://capnproto.org/news/2015-03-02-security-advisory-and-integer-overflow-protection.html https://capnproto.org/news/2015-03-02-security-advisory-and-... My next job is at a company that is a heavy user of Cap'n Proto, so expect more progress on this front going forward.