CVE-less vulnerabilities
CVE-less vulnerabilities
Posted Jun 30, 2019 10:17 UTC (Sun) by sorokin (guest, #88478)In reply to: CVE-less vulnerabilities by Cyberax
Parent article: CVE-less vulnerabilities
We were talking about sandboxing. Do you know any examples where people rely on python nor nodejs security to run untrusted code? I don't know of any.
I can not comment about Chrome though. I know that it is multithreaded, but perhaps its sandbox runs single-threaded code. I don't know. Ok perhaps this is a example of single-threaded sandboxed environment, still it is an exception. And overtime we will see fewer and fewer single-threaded programs.
> Enough to avoid security bugs. The only effective way to de-louse the C programs is fuzz testing, everything else simply doesn't work. And fuzzying can't find everything.
As well as you need fuzzing to test sandboxes. I would say for now fuzzing is the most effective way of finding bugs in programs.
Posted Jun 30, 2019 17:48 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
> I can not comment about Chrome though.
You also seem to not understand the whole concept of sandboxes. Sandboxes limit the operations that the contained code can do, whether it's multithreaded or not. And it's not like regular uncontained libraries can't access threads by themselves, either directly or through injected exploit code.
> As well as you need fuzzing to test sandboxes. I would say for now fuzzing is the most effective way of finding bugs in programs.
The second most powerful way is to contain code in sandboxes.
Posted Jul 1, 2019 21:13 UTC (Mon)
by samuelkarp (subscriber, #131165)
[Link]
Hey, thanks for the shout-out! This is somewhat of a sidebar, but hopefully I can help a bit. While Firecracker is used in production at AWS, it's a relatively young project. We've certainly tried to build Firecracker in a secure way (Rust is one part of that, a very limited device model is another part, and limiting privileges by default with seccomp and jailing is another), but the short amount of time it has been open-source means the security community hasn't had a lot of time to necessarily identify any issues in it. I think this may be a much stronger argument in the future as the project continues to mature and (hopefully!) security-minded folks have an opportunity to look deeper.
(disclosure: I work for AWS and work with the Firecracker team; I am helping to build firecracker-containerd, a project focused on managing container workloads inside Firecracker microVMs.)
Posted Jul 4, 2019 17:59 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
> No. The most effective way is to write software in safe languages. E.g. a sandbox in Rust: https://github.com/firecracker-microvm/firecracker - they had no CVEs so far.
The only guaranteed secure way to write secure software is to prove it correct. Try doing that with C and its undefined behaviours - the end result will be quantum with bugs popping in and out of existence at random. And they do! I'm pretty sure there have been several occasions when an upgrade to GCC has caused bugs in software to pop INTO existence ... (because the compiler exploited a loophole in the definition of the language)
Cheers,
Posted Jul 1, 2019 9:44 UTC (Mon)
by james (subscriber, #1325)
[Link] (2 responses)
I know it's Perl, but I'd love the ability to run SpamAssassin in a sandbox (without making any complaints at all about either SpamAssassin or Perl security).
Posted Jul 1, 2019 17:35 UTC (Mon)
by sorokin (guest, #88478)
[Link] (1 responses)
I completely agree with that point. In many cases this can be a completely adequate security measure.
Actually my original comment was about testing. Looking back I regret that I even responded to Cyberax who is arguing just for the sake of arguing.
Posted Jul 4, 2019 18:03 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
And while "security through obscurity" is a bad thing to *rely* on - as a deliberate *extra* feature on top of other measures it *is* good. Run a parser inside a sandbox on a hardened kernel - the attacker has to first discover the security measure before he can attack it, which gives you extra opportunity to discover *him*.
Cheers,
CVE-less vulnerabilities
You mentioned managed languages first. So stop moving goalposts.
The sandboxed code is single-threaded.
No. The most effective way is to write software in safe languages. E.g. a sandbox in Rust: https://github.com/firecracker-microvm/firecracker - they had no CVEs so far.
CVE-less vulnerabilities
CVE-less vulnerabilities
Wol
CVE-less vulnerabilities
We were talking about sandboxing. Do you know any examples where people rely on python nor nodejs security to run untrusted code? I don't know of any.
Well, this thread started with rra saying:
Personally, I think it's no longer an acceptable security practice to run an image parser on untrusted input outside of a sandbox.
illustrating that sandboxing isn't just for untrusted code -- it's also for mostly-trusted code that is likely to handle hostile data (and where you might not totally trust the language sandbox).
CVE-less vulnerabilities
CVE-less vulnerabilities
Wol