Looking to latest news, seems like that using BASH is something like preserving your money cache right, down, in the middle of your street. At Any Guy Pleasure to Load IT (tm).

Seriously, WE REALLY WE ARE DEPENDENTS ON BASH? There is NO another SHELL able to replace BASH?

Sorry for "bashing", all the best!

and pick one.

Well, Slackware ships a lot of shells:If you don't want to use bash, just don't use #!/bin/sh as a shebang as /bin/sh is a symlink to /bin/bash.

On the other hand, de-bashing the Slackware init scripts at least is not a simple task (there have already been thraads about that in this forum).

Personally, I'll will just follow official Slackware updates, but that depends on your use case.

You could have said the same thing about BMP when it was patient zero in a long string of graphic format vulnerabilities. I suspect we'll be seeing some other shell issues soon.

I see nothing wrong with continuing to use bash as the default system shell, and the upstream author has been very responsive to these issues.

For system tasks like startup and running local scripts, none of these recent bash issues have any impact. You're welcome to use a different shell under circumstances where the shell is exposed to untrusted input, but my advice would be to not do that with any shell if you can help it.

18 members found this post helpful.

Darth Vader

I was thinking the same thing as you, then I realized once everyone is done looking/changing bash, it could very well be more secure that any other shell

1 members found this post helpful.

I migrated from Solaris (and earlier System 3 and System V (R4) where sh or ksh were available -- I settled on KornShell late 80's, early 90's or so and the first thing I do after installation is change root's shell to /bin/ksh and set all user shells to the same (unless somebody really insists on BASH or, gulp, C-Shell).

I've never noted any security problems with either BASH or KornShell; could have been something that I did not notice, but I can't recall any. I have noticed, though, that KornShell and BASH are pretty compatible -- BASH is, after all, a look-work alike Bourne and Korn shells (pretty much). It's not a copy, it was developed using the functionality, not copying the code.

Why I don't use BASH is that it has added extensions. In my experience with coding (since the 1970's) is that extensions will always come back and bite you in the ass. I might take a while, but if you use extensions somehow, some day, you're going to get bit when a new version pops up (without that extension that was so handy when you were young and dumb and thought, "Why not?"). Bourne and Korn shells were both created at Bell Labs to "do one thing and do it well." In my opinion, BASH seems to have been "do all things" and that I try to avoid. BASH does seem to work and work just fine and just because of the current problem (which is, really, kind of a biggy) is no reason to bash BASH.

I think KornShell has been pretty much unchanged since, what 1993? Maybe a twiddle, twiddle there, but nothing I'm aware of. Is it "old?" Well, yeah, but when you do it right to begin with...

Bourne is much older and as far as I know has not changed in decades in Unix systems (like Solaris). In Slackware (and probably all Linux distributions, sh is a symbolic link to /bin/bash so it's not "actually" shell, it runs as an emulator.

But, to the question: sure you can use KornShell as a default (it will run Bourne shell grammar and syntax with no problem and it will run pretty much all BASH syntax [except extensions]). I have had no problems with KornShell being the default on my Slackware systems.

I do not change any #!/bin/bash in any shell programs and would not recommend doing so. BASH does work, seems to work fine and the recent problem was identified and fixed right quick once identified. That's the beauty of open source, lots of eyeballs, few uh-oh's and everybody knows about it and it gets fixed.

I write a lot of C, I happily use GNU C, I never, ever, use any GNU extensions because once burned twice shy and I don't ever want to rewrite something again for portability (I don't use any Solaris C extensions either for the same reason -- I do port software between Solaris and Slackware).

What the heck, try it and see.

On the other hand, if you really enjoy pain, change your default to C-Shell (and good luck with that mess).

Hope this helps some.

2 members found this post helpful.

I would have to agree that bash isn't what you want when dealing with untrusted input, such as a CGI proxy. I think perl would be a much better choice.

However, it should be a lesson to the bash devs to stop adding features nobody uses or wants.

I use ash to run my scripts and have converted the rc.d scripts to ash, this isn't because of this vulnerability, but because ash scripts are faster and more portable.

The shellshock vulnerability isn't just about the default command shell, it's also about services that invoke bash. Changing your default shell is not a panacea.
https://www.dfranke.us/posts/2014-09...n-vectors.html

@tronayne

Just out of interest (and it would seem we are very much two branches on the same tree) - have you had any problems with 'sprintf' (on sun vs gnu)?
I was once severely bitten by that (until I read the man-pages!!)

I always used to do something like this:and I just couldn't for the life of me understand why I got a core-dump on sun ... :-(

So, if I replace bash for pdksh I will have no problems with the init scripts?

I think many people would be concerned of the bash issue in a web server configuration, since it is the default shell, and the attack vector in this recent case is concerning. I am not a website programmer, but I am exposed to shell scripting. So I am aware of a general recommendation to avoid exposing system calls in unsafe contexts. Really the burden of security is in the scripts written to call the shell. So it doesn't matter which shell you use as they all can be exploitable when the shell is called incorrectly.

In this link, it shows how system() is dangerous, and how perl taint mode helps catch problems.
http://www.webreference.com/programm...int/index.html

This reply is only meant as an example, and please study out proper web security elsewhere. This is just to explain it is not a specific shell that is unsafe, but how these web scripts can call up a shell that is unsafe.

Not really any that I can recall. One of the lessons learned during a completely wasted youth was sticking to ANSI standards and watching carefully for buffer overflows (after far too any core dumps and hair pulling exercises). Nowadays it's POSIX (which is just ANSI with with some world standards thrown in for good measure).

One of those lessons was that strlen() is a Good Thing when dealing with buffers (and slapping a NULL at the end of a string "just in case"). I also always initialize buffers "just in case," and I always use functions (like the printf family) with
Yeah, I know, you don't have to but I like declaring what I'm doing so I don't get bit by something I've forgotten (like some functions slap a null on a sting and some don't).

I also use standard definitions; e.g., BUFSIZ, for declaring buffers. BUFSIZ is 8192 (Slackware 14.1 64-bit) and given the amount of memory available, who really cares; it's the size the I/O buffers that the system uses so why not? And it ports between platforms and compilers so you don't get bit by Windows if you're forced to actually trying to port something to one of those monsters.

I've learned to check stuff like where the pointer is pointing (so I don't go one byte over the end of the buffer). Easy enough, simple arithmetic, keeps your phone from ringing at 0300.

I generate Makefiles (with a handy piece of software I got from the AT&T Software Toolchest a long, long time ago named makefile) that runs "just fine" on Slackware and on Solaris. Maybe a little fiddling around with the definition of the compiler (just do that on the command line), maybe a definition of where to find libraries (also command line) and wow, zowie, clean compile, clean execution. The Sun C and GNU compilers are pretty standard and the grammar and syntax is standard so things work without a lot of hassle. I tend to follow AT&T standards (they were the guys that invented all this stuff after all) for make and C (you can't go wrong with K&R) and I never, ever use extensions. I have found the C compilers do a terrific job of optimizing (at least for the work that I do) with just a simple -O so never mind the options. Keep it simple seems to be a good bet.

And, yeah, reading the manual page for functions I'm not quite sure of is mandatory. Every platform is a little different but thankfully there are standards that you adhere to and you avoid problems (and never, ever use vendor extensions -- roll your own if you have to, but never incorporate a vendor extension in your code if you like to sleep through the night).

Just a few lesson learned (the hard way).

Unknown without a lot of seeing what happens, eh?

By the way, you've got ksh with Slackware, why not just use that.

I have a question, if I remove bash, will everything still work if I symlink zsh or ksh to sh ? You can disregard the /etc/rc.d scripts as I have already converted these to ash.

I'm asking because it looks like the rabbit hole only goes deeper with the bash vulnerabilities.

You'll find bash scripts all over the place, so ripping it out completely isn't really an option.

I'm with you. There seems to be a very big elephant in the room: this bash feature of parsing code from environment variables is inherently-insecure and no amount of fixing individual parser errors is going to alter that. The feature is ill-conceived and needs to be turned off by default: if not all-together then certainly when running POSIXLY_CORRECT as /bin/sh. I don't understand why upstream seem so reluctant to do that. I very much doubt that anyone is using this feature other than black-hats and script-kiddies, and I suspect that most of us weren't even aware that it even did this before this fiasco.

While I understand Pat not wanting to knee-jerk react to this incident, if upstream don't do something like the above then IMO we should be looking to change 'sh' to ash/dash/ksh. Yes, its going to be a lot of work, and we're going to expose some breakage in scripts that incorrectly specify #!/bin/sh but use bashisms, but if upstream don't come to their senses soon then I don't really see a better choice. The initscripts/shell profiles have gotten a bit crufty over 20 years of evolution anyway so this might be a good opportunity to kill two birds with one stone and give them a bit of an overhaul. It might be getting a little late in the dev cycle for that though, so even if we convince Pat that this is a prudent course of action this is something that would most likely need to wait until after the next release in order to give it time to settle in.

6 members found this post helpful.