Main Edition: BASH vulnerability a.k.a. 'Shellshock'

[DrHu]

You are getting into minutiae
--beginning to look like any argument to me; having your syntax taken apart word-by-word doesn't convey any sense of of any specific argument/opinion or viewpoint..

Essentially, no regular home user, which acts mainly as a client is likely to be that much affected by any BUGS in something such as the BASH shell (sh, being only the generic term for shell: aka command line)
https://en.wikipedia.org/wiki/Unix_shell

• The most generic sense of the term shell means any program that users employ to type commands. A shell hides the details of the underlying operating system and manages the technical details of the operating system kernel interface, which is the lowest-level, or "inner-most" component of most operating systems.

Each single user's personal setup , which if it did include server processes would be more problematic
--however the shellshock routines required a specific setup against the target (computer/system), that isn't a likely possibility except for publicly provided servers..

The truth is that the shellshock issue is an example of a Tempest in a teapot
--highly over-hyped by some internet/other interests (consultants) that wish to convey a particular view of Linux and OSS systems

Possibly I am getting too paranoid about that, and perhaps those reviewers/consultants are simply expressing their honest opinions

• I am not in the least bit worried about SHELLSHOCK issues or problems..

[killer de bug]

I'm not looking for an argument, I'm trying to understand why someone has posted apparently wrong info here which had not been deleted or amended by the admins.

That you misinterpret things doesn't make them wrong...

[karlchen]

Good night, folks.

Everything that can be told and discussed about the good old bash vulnerability a.k.a. 'shellshock' has been told and discussed ad nauseam. The most relevant pieces of information have been given in post #1 of this thread: The most recent bash patches for 'shellshock' should have been brought to your systems by mintupdate by now. If not then it is very likely your own fault. If you deliberately refuse to install the patches, then this is definitely your fault.

This thread will be closed now. In case you consider this step inappropriate feel free to contact a moderator or an administrator and request it to be re-opened.

Kind regards,
Karl

[panorain]

Hello There,

I came upon an article refering to an exploit in 'Bash' known as 'Shell Shock':

Noted here: --> http://shellshockexploit.com/

Can I please ask what I can do to protect my computer or server from this exploit?

For instance if I open up a Bash terminal on my computer running LinuxMint 17 with the 3.13.0-24-generic kernel installed and enter the following:

Code: Select all

env x='() { :;}; echo -n Exploitable\ ' bash -c 'echo Test'

I get this ouptut in return:
Test
So that means the version of Bash installed on my computer is vulnerable correct?

Thank you,

[tdockery97]

That's old, old news. Updates have already been provided to close that vulnerability.

[panorain]

If I can change my question then a little bit:

Menu --> Administration --> Update Manager --> View --> Linux Kernels:

The dropdown lists the following: --> http://cve.mitre.org/cgi-bin/cvename.cg ... -2014-0196 <-- how bad is that expolit?

Edit: A reliable and complete patch for Bash is not yet ready. [2014-09-25T10:00Z.]

A partial fix exists, but it doesn't fully solve the problem yet.

^above was found here https://nakedsecurity.sophos.com/2014/0 ... d-to-know/
Thank you for your response,

[panorain]

Could I install the MKSH shell via synaptic and not break a whole lot of things?

John Harris

As noted below:

Serious, yes, but still a Storm in a teacup here, Folks,

While it is being sorted out, switch over to the "MKSH" (MirBSD) shell.
As it did not and does not use the GNU tool kit chain, it has not been built with the "readline" issue that exploits "Bash".

However, like "Bash" the "MKSH" shell supports almost all of the same syntax and will run "Bash" scripts in a "SH" compatibility mode.
The Korn shell is also very old and very well tested.
I.E. HP, SUN, IBM, etc. all usually default to this command shell.

Unless you have something very "Bash" specific, MKSH" will do for now, if you are concerned.
Anything else that does not require "Bash" specifically should be swapped over.
Also please not that the "SH" command shell has the same problem as the "Bash" command shell.
I would also be looking at any script that uses the "readline" function or passes Unsanitized input or output to any "BASH" or "SH" shell.

One minor item, Google "Korn shell .profile and .kshrc" first, and make sure that you update or create the equivalent of the ".bash_profile" and ".bashrc" before you swap your shell over.

Also, you can pretty much cut and paste most of your ".bash_profile" into ".profile" and it will work.
For more advanced tricks, check out the "/etc/profile" script and the "/etc/profile.d/" directory, as applicable, to your platform.

Linux & Unix built in workarounds to issues since their inception.
Problem solved for now.

Thanks,

[karlchen]

<Moderator on>
We are the participants of the genuine Linux Mint forum thread about the "BASH vulnerability a.k.a. 'Shellshock'", Main Edition: BASH vulnerability a.k.a. 'Shellshock'
Your thread, panorain, and all its posts will be added to that thread. Your thread as you have created it will cease to exist. It will be part of the larger thread collective. Resistance is futile.
Assimilation completed. Welcome to the cube.
</Moderator off>

[MtnDewManiac]

If I can change my question then a little bit:

Menu --> Administration --> Update Manager --> View --> Linux Kernels:

The dropdown lists the following: --> http://cve.mitre.org/cgi-bin/cvename.cg ... -2014-0196 <-- how bad is that expolit?

I'm not only ignorant about a lot of computer stuff, I also have some damage (and am getting older) which causes me to have a great deal of trouble learning new things. So I am probably in the midst of the long, long line of people who tend to panic easily when someone mentions security concerns. But that one... Did you bother to read the description on the web page that you linked to?

The n_tty_write function in drivers/tty/n_tty.c in the Linux kernel through 3.14.3 does not properly manage tty driver access in the "LECHO & !OPOST" case, which allows local users to cause a denial of service (memory corruption and system crash) or gain privileges by triggering a race condition involving read and write operations with long strings.

According to the description of the issue, this is not a vulnerability in regards to random - or even aimed - attacks from "out there," it's only concerning local users. Not being a computer expert rocket surgeon brain scientist type, my solution would be a simple two-part one. One, remove any local users who are at all likely to attack your system from said system and, two, kick them out of your house (or fire them and kick them off your business premises, whichever is applicable). Well, actually, for me it'd be more of a three-part solution because just prior to kicking them off my property, I'd be kicking them a dozen times or so with one or the other of my steel-toed boots as a subtle way of encouraging them to not return. But if the computer in question is owned by a pacifist or some other form of plant-life, that middle step might be replaced by standing around and wringing one's hands or, IDK, molting or something.

IOW, if you're worried about what someone who is physically present might do to your computer, don't let them near it .

Regards,
MDM

[NChewie]

As the vulnerability appears to be available to LOCAL users who try to exploit the n_tty_write function to cause a denial of service attack to your own machine... you would really have to be in a bad mood to invoke it.

I can think of easier ways to cause a denial of service to my own machine [e.g. a swift kick]

I think MtnDewManiac has identified the correct admin response.