Shellshocked ?

[SpringHeeledJack]

BBC News - Web attacks build on Shellshock bug (http://www.bbc.co.uk/news/technology-29375636)

Is this something to be concerned about ? Or another impending disaster that never happens ?



SHJ

[KelvinD]

Something to worry about if you are running Unix/Linux, operate servers or a Mac.
If you are running Windows on a plain old PC, there shouldn't be any problem.

[Nige321]

If you are running a Mac you won't have a problem unless you've reconfigured UNIX services, which 99% of users wont. The remaining 1% will have a good idea of what they're doing, so will avoid the issue...
Typical media hype...:ugh:

[mixture]

SpringHeeledJack,

It is a real problem, but you need everything lined up for it to be workable.....

In a nutshell :

- Windows users : Nothing to worry about

- Mac users : Nothing to worry about unless you have been fiddling around and have some server software enabled that provides you with remote access to whatever that software does.

- Linux (desktop) users: You're bound to have some sort of default remote access (i.e. SSH) ... so make sure you keep your patches up to date and watch for new patches over the next couple of weeks.

- Linux (server) users: Since you're running a server, you should be patching it up regularly anyway !

In technical terms :

(a) you need to be running a vulnerable version of the BASH shell
(b) you need to have some software running on your machine that provides a means of access to (a).

Many people will have (a) ... not so many people will have (b).

[ExXB]

Mixture, thank you for the clarification. The reports in the media were all doom and gloom for all UNIX users.

A virtual beer is enroute

[BOAC]

For those hosted on Linux based servers, it might be as well to check they have patched - most have - and should have!

[SpringHeeledJack]

Thankyou mr mixture, that was clear enough even for the likes of me. :ok:



SHJ

[le Pingouin]

I wonder how many Internet facing Linux based devices such as smart TVs are running in ordinary homes? Don't like the chances of many them being patched.

[ExXB]

Comments from the mothership:

In a statement to Engadget, Apple claimed that "the vast majority of OS X users are not at risk...With OS X, systems are safe by default and not exposed to remote exploits of bash unless users configure advanced Unix services."

From: Apple Claims 'Vast Majority of OS X Users' Safe from Bash/Shellshock Exploit | Mac|Life (http://www.maclife.com/article/news/apple_claims_vast_majority_os_x_users_safe_bashshellshock_ex ploit)

Cult of Mac also provided a handy method of checking to see if your OS X unit is at risk. Simply open your terminal, and copy and paste the following command into the interface:

env x=’() { :;}; echo vulnerable’ bash -c ‘echo hello’

If you're not at risk, the Terminal should reply with:

bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x’ hello

I don't recommend this if you are unfamiliar with Terminal. I can tell you my iMac running 10.9.1 replied as above.

[ExXB]

I wonder how many Internet facing Linux based devices such as smart TVs are running in ordinary homes? Don't like the chances of many them being patched.

This may be true, but my Smart TV is not on-line all the day. To connect to my wifi network I have to log-in each time.

Also what could a black hat do with a hacked TV?

[mixture]

Also what could a black hat do with a hacked TV?


Use it as a zombie to contribute towards a DDoS attack.

[le Pingouin]

Until Apple releases a patch it's a fairly pointless exercise running that command - your bash is a vulnerable version. But as mentioned unless you're specifically allowing remote access it's not a problem.

Unfortunately a variation of the vulnerability has surfaced that needs additional patching. You might be patched for the first but not the second:

$ rm -f echo
$ env X='() { (a)=>\' sh -c "echo date"; cat echo

sh: X: line 1: syntax error near unexpected token `='
sh: X: line 1: `' sh: error importing function definition for `X'
Thu 25 Sep 2014 08:50:18 BST

The above output is an example of a vulnerable bash version. If you see a date in the output of that command your bash is vulnerable.

[mixture]

$ rm -f echo

Pray do tell, what's the point of that command ?

[le Pingouin]

Clearing the previous content. If you don't copy or type correctly the script might fail and you'll be looking at the content from the previous test.

What, prey tell, was the point of your posting?

[mixture]

What, prey tell, was the point of your posting?

To demonstrate that you've blindly copy-pasted from somewhere and have no idea what you've just posted !

There is no such thing as "clearing the previous content" unless you mean clearing the terminal screen with the "clear" command.

rm is the command to remove (or unlink) directory entries
"-f" just tells rm to do so without prompting for confirmation

Thus....

rm -f echo

is just saying "remove the file echo, if present in the current directory, and do so without prompting me"

And is therefore an utterly pointless command in your context, a fact proven beyond doubt with a simple stack trace...


$ strace rm -f echo
execve("/bin/rm", ["rm", "-f", "echo"], [/* 21 vars */]) = 0
brk(0) =
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
///TRUNCATED///
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B9600 opost isig icanon echo ...}) = 0
newfstatat(AT_FDCWD, "echo", 0x1335368, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory)
unlinkat(AT_FDCWD, "echo", 0) = -1 ENOENT (No such file or directory)
lseek(0, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
close(0) = 0
close(1) = 0
close(2) = 0
exit_group(0) = ?
+++ exited with 0 +++


See all those references to "No such file or directory" and "Illegal seek" ? That's you being told there's no such file in the current directory ...... I rest my case.

[Saab Dastard]

Message to all - play the ball not the man, or be banned.

Telling someone that their argument or action is incorrect is playing the ball, calling them a tw@t is playing the man.

End of message.

SD

PS - if you can't tell the difference, don't post.

[cattletruck]

Seems like a bit of sloppy programming on behalf of the bash source coders. Can't help but think that this bug has revealed how unsophisticated and vulnerable the importing of exported variables and functions in bash is, and that there is more trouble to come.

Have to wait for the release of babash (Born Again Born Again SHell)

I love a good explosion in a punctuation factory, and seeing that there are going to be a lot of old legacy systems lying around that are going to take some effort or a while to patch I thought I'd have a go at trying to come up with a work around for this problem.

My understanding is that the problem stems from the command line parser which executes poorly when spawning a new shell in conjunction with preserving exported functions.

So my approach is to help with the parsing by cleaning up the functions before they are exported.

After about one hours effort I came up with this basic approach:


# This function overloads (in C++ lingo) the export function
# Declare this in your scripts, or introduce in a wrapper,
# or add to bashrc.
#

# Disable bash's builtin export function before defining the new function.
enable -n export

# Define the new export function
export() {
# Step 1: Disable the bash builtin export function
enable -n export

# Step 2: Clean any exported function of nasties before export
# - lots of room for improvement here, this is just one basic idea.
pruned_variable=`echo "$*" | gawk 'BEGIN { RS="}" ; isafunc=0 ; prev_rec="" }
{ if(index($0, "()")) isafunc=1 ;
printf("%s", prev_rec) ;
prev_rec = $0 }
END { if(isafunc) { print "};" } else { print $0 } }'`

# Step 3: Debug - uncomment to debug
#echo "$pruned_variable"

# Step 4: Now we can export the cleaned up function
enable -a export
builtin export "$pruned_variable"
enable -n export
}

# Now export the new export function for use in child processes.
enable -a export
builtin export -f export
enable -n export


I bet a few here can see a way of beating step 2, but this is really basic and here just to give you an idea. This bit has been deliberately left lean and mean and more parsing/cleaning effort would be required for it to be implemented on a serious old legacy system.

I've tested this with basic examples I've found on the net and it works fine for my old unix implementations.

If you are running newer systems then you are much better off installing the latest bash patches.

[mixture]

Someone's been busy, cattletruck ! :cool:

As you say yourself though, needs more work on validation and parsing to bring up the robustness.

[ExXB]

But not at the Apple Store, only at Apple Downloads. Guess they figure most of us don't need it. See the links in this article:

Apple Releases Patches for Shellshock Bug ? Krebs on Security (http://krebsonsecurity.com/2014/09/apple-releases-patches-for-shellshock-bug/)

From the comments there you need the very latest versions of the OS, and Mavericks was just updated a few days ago so ...

[mixture]

Probably because they'll be rolling it into a larger update seeing as it doesn't affect the majority of their users.