Curl’s backdoor threat

Re:Curl’s backdoor threat by yjftsjthsd-h on Tuesday September 12, 2017 @07:03AM (#15226300)

"Safe" languages make it harder to write some classes of bugs; this is good. I wonder, though, whether it's not a better return on investment to focus on sandboxing wherever possible? I can run curl in firejail right now with no code changes whatsoever. On supported systems, pledge() and SELinux rules can mitigate attacks with minimal effort. And we get to keep existing programs without investing the man-years to rewrite something that works.

[ Parent | on HN ]

Re:Curl’s backdoor threat by sitkack on Tuesday September 12, 2017 @08:46AM (#15226808)

These things are excellent, but lots of stuff gets pulled in via libs. Security is a layer and spectrum, both techniques are valid, valuable and needed.

We need to find a way to extend sandboxing to dynamic libraries in a way that is descriptive at the ops level. Something that can be applied a system management rule so that it can be distributed to end users now and not wait for the safe versions to get disseminated.

[ Parent | on HN ]

Re:Curl’s backdoor threat by jsudhams on Tuesday September 12, 2017 @09:57AM (#15227280)

Would making sure that every software has libraries packaged/signed and in the same folder as would work? It would minimize common shared lib and updates to the same. THough disk space will be wasted should be still acceptable to many use cases

[ Parent | on HN ]

Re:Curl’s backdoor threat by sitkack on Tuesday September 12, 2017 @11:31AM (#15228097)

Sandboxing is separate from authentication. Binaries getting compromised is orthogonal to a non-adversarial defect being used by an adversary.

[ Parent | on HN ]