On Fri, Sep 26, 2014, at 05:05 PM, lolilolicon wrote: > The grep would find some false positives -- e.g., some perl script might > include #!/bin/sh in its body (such as findimagedupes). > > With dash you don't really need -p, which is more strict. > > The following will reduce the count drastically: > > #!/bin/sh > for f in /usr/bin/*; do > test -f "$f" || continue > sed -nr ' > /^#!/!d > \@^#![[:space:]]*/bin/(env[[:space:]]+)?sh\>@q1 > q > ' "$f" || checkbashisms -f "$f" > done > > This finds 259 instances for me, of which 208 instances are from a > *single* script /usr/bin/libtool -- which apparently really relies on > bash. > > Among The other instances of bashism, many are false positives (if we > had removed -f from the checkbashisms command line, some could have been > detected), but some are real, such as /usr/bin/bzgrep and /usr/bin/xbmc, > but they're mostly an easy fix for upstream. > > > Assuming that these bashisms all come from upstream, patching > > and maintaining them would be a chore. > > From my inspection above, bashism is really not that wide spread. Even if we agree to shift /bin/sh to dash, I'm not sure that it'll make that much of a difference. From what I've read, most of the problems come from CGI scripts which invoke bash, and ssh post-authentication. I'm not saying that these are the only vectors of attack, no, but these are the ones which are mentioned the most. Since bash is not generally used remotely (except in the case of sshing to a remote machine), I doubt that removing bashisms from most such scripts will really make much difference in security. How many of these scripts are even called remotely? How many of them actually form an attack surface? Do you have any data for that? Without actually having this data, it seems irresponsible to talk about shifting. If you do, however, then I'd be very interested in viewing it. Disclaimer: I have no security/programming credentials, I just script a bit in my spare time. -- Cheers! Savya
