Shellshocked ?
Thread Starter
Shellshocked ?
BBC News - Web attacks build on Shellshock bug
Is this something to be concerned about ? Or another impending disaster that never happens ?
SHJ
Is this something to be concerned about ? Or another impending disaster that never happens ?
SHJ
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...
Typical media hype...
Join Date: Aug 2002
Location: Earth
Posts: 3,663
Likes: 0
Received 0 Likes
on
0 Posts
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).
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).
Join Date: May 2009
Location: Confoederatio Helvetica
Age: 69
Posts: 2,847
Likes: 0
Received 0 Likes
on
0 Posts
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
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
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.
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
Join Date: May 2009
Location: Confoederatio Helvetica
Age: 69
Posts: 2,847
Likes: 0
Received 0 Likes
on
0 Posts
Also what could a black hat do with a hacked TV?
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.
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.
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?
What, prey tell, was the point of your posting?
Join Date: Aug 2002
Location: Earth
Posts: 3,663
Likes: 0
Received 0 Likes
on
0 Posts
What, prey tell, was the point of your posting?
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 +++
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.
Last edited by mixture; 28th Sep 2014 at 09:27.
Spoon PPRuNerist & Mad Inistrator
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.
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.
Join Date: Apr 1998
Location: Mesopotamos
Posts: 5
Likes: 0
Received 0 Likes
on
0 Posts
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:
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.
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() {
# Now export the new export function for use in child processes.
enable -a export
builtin export -f export
enable -n export
# 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
}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'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.
Last edited by cattletruck; 29th Sep 2014 at 23:59. Reason: version 2
Join Date: May 2009
Location: Confoederatio Helvetica
Age: 69
Posts: 2,847
Likes: 0
Received 0 Likes
on
0 Posts
Apple Releases Patches for Shellshock Bug
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
From the comments there you need the very latest versions of the OS, and Mavericks was just updated a few days ago so ...
Apple Releases Patches for Shellshock Bug ? Krebs on Security
From the comments there you need the very latest versions of the OS, and Mavericks was just updated a few days ago so ...