Dave Wheeler has an excellent, level-headed write-up here. One thing he points out, is that the bug was in there for 25 years(!) before it was caught. It's good that it was found and fixed, but the number of observed exploits in the wild over that time was essentially nil.

Another thing he points out, is that now more of the "incidental" code is going to get a lot closer scrutiny.

1 members found this post helpful.

Nah, judging by what I've read on 'bug-bash' they simply wouldn't be open to the idea. Someone already suggested disabling the feature when bash was invoked as 'sh' and was met with a dismissive comment. As far as Chet is concerned shell-shock is fixed by the BASH_FUNC_ prefix, and while they're still finding and fixing parsing issues, they simply don't see function importing as a threat any more.

When I wrote that patch it was simply so I could do away with that horrid bash-wrapper I was using as a short term fix. Then I thought "Hmmm, I wonder how hard it would be to add a configure option", and the patch I posted above was the result of me finding out. it was never intended for upstream (it'd need some more work for that: update documentation, GNU code styling and so on), and as I said, above, there wouldn't be any point as they just wouldn't see a need for it anyway.

Medium term, I'm going to work towards moving away from bash as the system /bin/sh on my local boxes, which is not only about this function importing stuff, there are other reasons beyond that to do so.

Keep us posted; I'm sure I'm not the only one who would be interested in your progress.
Others in the forum seem to have had success with ksh as /bin/sh; another option which I have used and liked in the past is mksh

Cheers

Hmmm... It seams that the FreeBSD guys already did something like this here.. You seem to have a different approach, but I like the 'no-import-functions' addition...

Yep, I think the original idea came from one of the NetBSD guys, FreeBSD followed suit, and I wouldn't be at all surprised if OpenBSD haven't done something similar too.

I pretty much just did what they did, but I got a little carried away and wrapped it all in configure options.

The problem with --no-import-functions is that it doesn't protect you from calls to system() or popen() or any other call to bash that won't specify it. It might be useful on the #! line of CGI scripts: though anyone in their right mind shouldn't be writing CGI in bash or any other shell script in the first place, so its probably of limited value.

As I said in one of the posts above, mostly it was just to see if I could do it.

I think the BSD guys actually care about security, I mean look at this bash issue, libressl, and the handling of the kernel breach (much better than Linux did).

I think I'll dual boot FreeBSD for a while.

Go for OpenBSD then.

I hit a couple of problems using the AT&T ksh that slackware ships. Though it has many of the features that bash has, there are some differences:

Unlike bash, "eval" seems to work argument by argument in ksh, so that:
needs to be written as:
or you get a syntax error. This is in rc.S in the cryptsetup handling. Luckily using the quotes doesn't break bash, so quote it and it'll work in both shells, but its a difference non the less. Anyway, I've since rewritten that part of rc.S, so that doesn't really concern me, but the same issue could turn up in other scripts.


A second issue I discovered in AT&T ksh, is that it seems to break installpkg! Now, this one is odd, as it seems to be intermittent, but more often breaks than works. In /sbin/installpkg there is this section of code:
What seems to happen is that the tmpsize$$ file is left empty, which then means that UNCOMPRESSED is left empty, which causes a syntax error in the test. But, it occasionally works, and I haven't been able to determine why.

A final issue with ksh stems from its default aliases, specifically 'stop' which unfortunately seems to be a fairly common function name in many scripts and will result in ksh trying to run a kill command rather than the intended function.


mksh looks interesting and will be something I'm going to be looking at, though I've not been playing with it long enough to get a feel for how well it works. It does have a much smaller memory footprint that bash, which is nice.


Anyway, that's what I've discovered so far.

1 members found this post helpful.

Yeah, I've also noticed that installpkg and upgradepkg aren't safe to switch to ksh, like you said they work sometimes but not other times.

Why would you want to switch the package tools to use Ksh? I don't see the reason for this. What attack vector is there?

There's no reason at-all to use ksh for pkgtools, you're kind of missing the point. I was just using ksh because it was installed. The goal of my experiment was to identify issues that occur when I change /bin/sh to any shell other than bash, and the pkgtools just happen to specify #!/bin/sh and so were impacted. I started with ash first, and then moved onto ksh because it was already installed. Next on my list is mksh.

Ideally I'd like to be able to have the system be agnostic with regard to what provides /bin/sh, but I accept that this may be too problematic given the amount of scripts out there that just assume bash. Dismiss it as scratching an itch if you want, but I don't see what's so wrong with having a go and seeing what happens!

I was surprised by this particular issue with installpkg given that I believe the pkgtools are designed to be usable with 'ash' and as such I wasn't expecting any problems. Given the intermittent nature of the problem, I suspect its some sort of race condition/bug in ksh rather than any problem with the installpkg script itself, which seems to be in keeping with POSIX and seems to work fine with any other shell, including mksh (which I tested briefly).

...And those of us who use KornShell rather than BASH can change the shebang of the scripts in concern, one way or another.

I didn't try but other than just editing each involved script, that could be replacing the symlink /bin/sh with a script that chooses a different shell in the few cases it's needed.

PS I should have tried... "Bad interpreter", of course.

I know that I should think before I type, and check before I post, but sometimes I forget. Sorry for the noise.

I'm getting to where I've got some time to fiddle around and see what I can break.

I'm going to do a clean install (Slackware 64-bit, 14.1) then change the /bin/sh symbolic link from bash to ksh. Then I'm going to install all the patches and see what happens (if anything).

As I understand it, BASH or KornShell when executed as sh are supposed to magically become only Bourne Shell (with no "extras") and it might be interesting to see if that's actually completely true. The #!/bin/sh should execute any of the Bourne compatible shells as sh (just as #!/bin/ksh or #!/bin/bash should execute as either of those).

If stuff works, I'll start adding data bases and a couple of applications (like, oh, say, OpenOffice) and see what happens (shouldn't be anything happening in those cases, they're not shell programs).

I kind of suspect that linking /bin/ksh to /bin/sh won't do much of anything and I won't be changing anything that explicitly has the BASH shebang embedded (that would be an actual BASH shell program and I'll just leave that alone for the moment). I have done a little bit of fiddling around with BASH programs, running them as KornShell, and mostly they just work (the grammar and syntax are pretty much the same for most stuff but not for the exotic BASHisms).

This might just be an interesting exercise in futility, eh?

It's not. While running bash as 'sh' (or with --posix or POSIXLY_CORRECT=y ) does change some of its behaviours to be more in keeping with the POSIX standard, it doesn't disable any of its extensions. A shell can be POSIX compliant while still providing extensions, but a shell-script isn't POSIX compliant if it uses any of them.

1 members found this post helpful.

Well, alrighty then, that puts the kibosh on that. Bah, humbug.

Looks to me like my choice is to stick with KornShell for all shell programming (which is what I do anyway) and hope that system BASH shell programs don't carry ebola along with 'em.

Hobson's choice.