CVE-less vulnerabilities

Posted Jul 1, 2019 9:44 UTC (Mon) by james (subscriber, #1325)
In reply to: CVE-less vulnerabilities by sorokin
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.

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

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

CVE-less vulnerabilities

Posted Jul 1, 2019 17:35 UTC (Mon) by sorokin (guest, #88478) [Link] (1 responses)

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

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.

CVE-less vulnerabilities

Posted Jul 4, 2019 18:03 UTC (Thu) by Wol (subscriber, #4433) [Link]

Cyberax is okay. I think we have some people here who prize belief over empirical evidence. At least you can argue with people who are persuaded by evidence.

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,
Wol