in reply to Re^6: Taint and Shellshock
in thread Taint and Shellshock

Thank you both, tobyink and kennethk, for the explanations. I have definitely learned from your comments.

UPDATE: Also instructive is an article -- cited in this (Mon, 2014-09-29) morning's Perlweekly -- by David Farrell. In essence, my view is both undermined and supported there:

As I now understand it, a BAD_ENV can be injected into the params passed to the server's CGI script, and (more-or-less) easily. But getting the malware into the server's environment requires -- at least as I now understand it -- that the server's owner/CGI-writer has failed to use taint to force the server-side code to effectively assess each of the params being provided by the outside user and prevent passage of meta-characters which are (TBO our current knowledge) required to make bash execute the malware writer's payload.

If I still have this wrong, pray continue my edumuckation....


++$anecdote ne $data


Replies are listed 'Best First'.
Re^8: Taint and Shellshock
by kennethk (Abbot) on Sep 29, 2014 at 17:50 UTC

    Thank you for sharing that link. The parallel between that article and LanX's suggestion is interesting. From my perspective, the Good Security™ solution is for Perl to balk if any of the %ENV is still tainted prior to shelling out; right now, it only holds for qw|PATH IFS CDPATH ENV BASH_ENV|. It's problematic that a module could expose you in this type of vector. It feels like it breaks the principle of least surprise. Unfortunately, that would break too many scripts and thus would never fly.

    My proposed solution (explicitly setting an exclusive list of expected parameters) would seem to resolve this this issue for my own external calls, but I wanted to get a sense of the relative value of those values I was defaultly relegating to the trash heap. Frankly, I'm still confused at the reluctance to just toss the hash content; of course, that's why I posed the OP.


    #11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.

      Much easier to fix the problem one level deeper. Just replace /bin/bash with this Perl script:

      #!/usr/bin/perl -wT use strict; # Clean up environment s/^\(\) {.*// for values %ENV; # Now, exec bash with our name and our arguments exec { $0 } '/bin/bash.original', @ARGV;

      If you're looking at validating all environment variables, you'd need to know which environment variables are supposed to hold what kind of values. And for example LD_PRELOAD or LD_LIBRARY_PATH should be passed through verbatim (because if an attacker already has access to these, you can't even trust yourself).

        LD_PRELOAD and LD_LIBRARY_PATH. Thank you; I knew I was forgetting something.

        #11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.