Hacker News new | ask | show | jobs
by willvarfar 4904 days ago
Why doesn't Ruby (and Python and all other languages) have Perl's tainting built in and always running?

I'm not advocating it as the only security mechanism, but rather as another barrier to be overcome just like address-space-randomisation, data-exection prevention and all the rest...

(Haven't Google recently shared a valgrind-lite runtime bounds checker which is being incorporated into GCC etc? Might lead the way on how this can be down with the minimum of runtime cost.)

2 comments

Because tainting is an inherently flawed way to do security. Blacklisting capabilities/methods/data always leaves holes behind, and it's nearly impossible to secure a system using tainting alone. Even the Perl folks say it shouldn't be used as a security mechanism...it should be used to help thin out security issues during development and testing.

If you want to secure a system...whitelist, don't blacklist.

If the runtime overhead is low, then shouldn't tainting be used in addition to other techniques? ala Defense in depth?
You certainly can do that. You can also add more and more locks to your doors while leaving your windows open.
My understanding of the taint flag as implemented in Perl is that it is very much a whitelist. All user input is born tainted and much be verified clean before the flag is removed. It's possible to screw this up by verifying too much, but that's an overly-expansive whitelist problem, not a blacklist that isn't restrictive enough.
MRI has tainting through SAFE, but its generally considered problematic and might give a false sense of security. MRI and Rubinius don't implement it.
You mean JRuby and Rubinius, but yes...it's as flawed as every other blacklisting security mechanism. We mostly don't implement it because, well, "here, add these security checks and tainting propagation to EVERY METHOD IN THE SYSTEM and if you don't do it right, you're totally effed." Sounds great.
You add tainting propagation to every method in the system that handles tainted user input. Hopefully, this will encourage you to untaint the user input ASAP and build native objects out of it. Now, of course, if you take untainted strings and feed them into reflection/eval you are in a world of hurt, but perhaps you should stop using reflection/eval.