SGI: Security

VenomousPinecone wrote: Whaddya' mean? that's not what the floppy drive is for? All these years of my life spent in confusion.

Madame Chiang ! Madame Chiang ! Is it really true ?

What are you saying, VP? That the floppy makes your internal drives hard?

Thank you, I'll be here all week.

ClassicHasClass wrote: What are you saying, VP? That the floppy makes your internal drives hard?

Thank you, I'll be here all week.

I'm tempted to issue a Moderator's Warning for corniness.

Hey, I'm just staying classy.

Oh, FFS.

http://tenfourfox.blogspot.com/2014/09/ ... -4327.html

Thanks, CHC. Much appreciated!

Everyone has criticized the Bourne syntax and its ambiguity for the last 30 years, and now I guess the chickens are coming home to roost. It doesn't help that Bash is more complex and adds numerous features (basically a superset of ksh88). Fortunately BSD and Debian-derived systems are mostly safe from it ("/bin/sh" is not Bash on those systems).

Updating is easy and only takes a few seconds, but it's unfortunate that it has to happen at all. I wouldn't be sad if Linux distros just replaced Bash with mksh for a standard shell (upgrade to "rc"?). Really, the features of ksh88 were always good enough. We don't need SSH host autocompletion or other stupid things. Unfortunately part of the GNU strategy in the 1980s was to extend Unix programs by adding more features so everyone would want the "super" versions. Some of their improvements were good, like removing artificial limits, and using more efficient algorithms, but adding features led to bloat.

Edsger Dijkstra wrote: How do we convince people that in programming simplicity and clarity —in short: what mathematicians call "elegance"— are not a dispensable luxury, but a crucial matter that decides between success and failure?

Edsger Dijkstra wrote: Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.

On Debian 7:

Ironically, I *think* NetWare 6.5 is affected, too. It comes with bash-3.0 and several other GNU/BSD utilities built as NLMs (NetWare Loadable Modules). I tested the original CVE-2014-6271 exploit on it, and it doesn't work immediately, but if you exit and reload BASH.NLM, it seems to suddenly process the environment var set and partially execute the bug. Haven't seen a patch from Novell yet to address the issue. I might go badger them just for fun...

4.3.28 is out, and the 10.4+ universal binary is updated, which should fix all five CVEs finally.

http://tenfourfox.blogspot.com/2014/09/ ... dated.html

a second shellshock thread now

please, the politically correct term is PTSD.

foetz wrote: a second shellshock thread now

Actually, this is the third thread. I keep merging them, and a new one appears! Kind of like patches to bash!

josehill wrote: Kind of like patches to bash!

a good match then

I absolutely astounded that the authors of bash thought it a neat idea to

(a) export functions via environment variables
(b) execute contents of any environment variable with the script parser/handler

Its like somebody shooting themselves in the head with every revolver they find to see if they are loaded.

Plonkers!

porter wrote: I absolutely astounded that the authors of bash thought it a neat idea to

(a) export functions via environment variables
(b) execute contents of any environment variable with the script parser/handler

Its like somebody shooting themselves in the head with every revolver they find to see if they are loaded.

Plonkers!

Part of the problem is that Bash is just too complex. The design of the Bourne shell was convoluted enough, and then they add on so many "special features." Glad that my "/bin/sh" is "/bin/dash", and I will use Bash only for custom shell scripts using Bash features.

Actually some of the extra features in Bash are useful, like in-process testing with "[[ ]]", and in-process arithmetic with "let". By switching over to Bash features, some of the programs I've written have become much more efficient. These are all available in ksh88 and mksh, though.

When a system relies on one component so much, that component has to be simple, safe, and sturdy. Even aside from this Shellshock vulnerability, Bash is very questionable for the role of "/bin/sh". It's too complex.

Yes, we already know that you favor a "See Figure 1" approach to system usability. You really don't need to say it in every post.

jwp wrote: Bash is very questionable for the role of "/bin/sh"

for sure. i've never been a bash fan but i wouldn't bash it too much here (pun ) either because the problem is linux. to be more precise it being way too spoiled.
system related scripts should never use more than what a real sh can provide. by that the dependency on one specific shell is reduced a lot and by that all bad things that can come out of that

Just installed the latest patched bash to my Internet-facing firewall (running Slackware 14.0), of note, see highlight below:

Installing package bash-4.2.050-i486-1_slack14.0.txz:
PACKAGE DESCRIPTION:
# bash (sh-compatible shell)
#
# The GNU Bourne-Again SHell. Bash is a sh-compatible command
# interpreter that executes commands read from the standard input or
# from a file. Bash also incorporates useful features from the Korn
# and C shells (ksh and csh). Bash is ultimately intended to be a
# conformant implementation of the IEEE Posix Shell and Tools
# specification (IEEE Working Group 1003.2).
#
# Bash must be present for the system to boot properly.
#
Executing install script for bash-4.2.050-i486-1_slack14.0.txz.
Package bash-4.2.050-i486-1_slack14.0.txz installed.

that's a result of /bin/sh being a link to it. Only a few non-critical init scripts use it directly.
try

robespierre wrote: Yes, we already know that you favor a "See Figure 1" approach to system usability. You really don't need to say it in every post.

I must say it in every post!