141–150 of 157 posts
Earlier quoted context omitted.
The problem comes about if your mac is serving web pages. If you aren't then there is less worry.
I think even just using DHCP put your Mac at risk: https://www.trustedsec.com/september-2014/shellshock-dhcp-rc...
Earlier quoted context omitted.
> "Decent shell script" is not a synonym for "portable shell script" Only for you. For me and a lot of others I suspect, if it isn't portable it isn't worth the trouble. If you have to re-compile a newer/older version of a shell to get the same results across machines, any potential benefits start to seem insignificant compared to the effort involved.
How? I already am running Chef on every machine I touch .
How do you handle situations where bash is included by default?
Do you remove the package or just push your binary over the top?
If you don't remove it, what happens when a package update then replaces your binary?
How often do you update the recipe to make sure it's getting the latest stable version and applying security patches?
Earlier quoted context omitted.
What responses does it pass, does it not sanitise them? Can anyone link to details of what DHCP does that's relevant here? Thanks.
Looking at http://code.metager.de/source/xref/isc-dhcp-debian/client/dh... It seems that server_name from DHCP response is passed to environment variable without sanitising. 3437 if (check_option_values(NULL, DHO_HOST_NAME, 3438 lease->server_name, 3439 strlen(lease->server_name)) == 0 ) { 3440 client_envadd (client, prefix, "server_name", 3441 "%s", lease->server_name); And script that is run after that (dhclient-sc…
See code here: http://lists.alioth.debian.org/pipermail/pkg-dhcp-commits/20...
Test your local machine: export evil='() { :;}; echo vulnerable'; bash -c echo; Vulnerable computers will print 'vulnerable'. Test a CGI: curl -i -X HEAD " http://website" -A '() { :;}; echo "Warning: Server Vulnerable"' Vulnerable scripts will emit a "Warning" header. If you get a 405 error, try it with a GET request. I don't know the PoC fo new version which wiggles around the patch. I've tried the PoC on ksh, csh,…
> Its advisable to rename bash, and replace it with a symlink to dash; it shouldn't break any scripts It most certainly will. dash provides a tiny subset of bash's functionality. Even scripts using #!/bin/sh often contain bashisms; a script using #!/bin/bash is certain to contain bashisms. If you really want to swap out bash, swapping it out with ksh is likely to break fewer scripts (though it could still break scrip…
I still contend that its a good idea. Most shell scripts used by the OS are written to dash in my experience; if you break ones you've added yourself, this is perhaps a good opportunity to review their security.
Earlier quoted context omitted.
Have you got a source for OS X DHCP being vulnerable? OS X has a copy of bash at /bin/sh so it's pretty vulnerable if you can find a way to remotely set environment variables and call system().
It was in the article linked. at the bottom it mentioned them
One early analysis [0] seems to indicate that OS X not vulnerable to this sort of DHCP client exploit.
0. http://complexitydaemon.wordpress.com/2014/09/26/bash-os-x-d...
Earlier quoted context omitted.
I suggest you read my post and maybe let it roll around your head that I've considered my environment and the domain of my problems in a way you aren't giving me credit for. Perhaps even, with that whole mention of devops, I do something such as--crazy thought incoming--install an updated version of bash on every system I must provision, just as I do Ruby, Python, etc.? "Decent shell script" is not a synonym for "por…
Exactly so. If I want PORTABLE, I write to "sh". If I want BASH, I write to BASH. The term "decent shell script" is wrong the way he uses it.
Writing to '/bin/sh' is understandable due to its ubiquitousness.
Bash is a superset that is not so ubiquitous, so it doesn't have the advantage that writing to /bin/sh does.
If you don't want portable, then don't write to shell script. Write to Perl Ruby or Python, which is also safer and more secure.
Basically, if some program does invoke /bin/bash, control first passes to this code which truncates suspicious environment variables. (and it dumps messages to the system log if/when it finds anything...)
The check should match for any variety of white space:
=(){
=() {
= ( ) {
etc... but feel free to update it for whatever other stupid things bash allows.
The code is at http://ad5ey.net/bash_shock_fix.c
Simple usage:
cd /bin
gcc -std=c11 -Wall -Wextra bash_shock_fix.c -o bash_shock_fix
mv bash bash.real
ln -s bash_shock_fix bash
phoenix(pts/1):~bin# ls -al bash*
lrwxrwxrwx 1 root root 14 Sep 27 00:23 bash -> bash_shock_fix
-rwxr-xr-x 1 root root 1029624 Sep 24 14:51 bash.real
-rwxr-xr-x 1 root root 9555 Sep 27 00:23 bash_shock_fix
-rw-r--r-- 1 root root 2990 Sep 27 00:23 bash_shock_fix.c
phoenix(pts/1):~bin#
Earlier quoted context omitted.
How? I already am running Chef on every machine I touch .
So you have a chef recipe to download and compile the same version of bash on every platform you use? How do you handle situations where bash is included by default? Do you remove the package or just push your binary over the top? If you don't remove it, what happens when a package update then replaces your binary? How often do you update the recipe to make sure it's getting the latest stable version and applying sec…
Earlier quoted context omitted.
Exactly so. If I want PORTABLE, I write to "sh". If I want BASH, I write to BASH. The term "decent shell script" is wrong the way he uses it.
Perhaps he didn't deliver the point... but BASH is not a good or safe language to write to. Writing to '/bin/sh' is understandable due to its ubiquitousness. Bash is a superset that is not so ubiquitous, so it doesn't have the advantage that writing to /bin/sh does. If you don't want portable, then don't write to shell script. Write to Perl Ruby or Python, which is also safer and more secure.
Earlier quoted context omitted.
Perhaps he didn't deliver the point... but BASH is not a good or safe language to write to. Writing to '/bin/sh' is understandable due to its ubiquitousness. Bash is a superset that is not so ubiquitous, so it doesn't have the advantage that writing to /bin/sh does. If you don't want portable, then don't write to shell script. Write to Perl Ruby or Python, which is also safer and more secure.
/bin/bash is on literally every machine I ever touch. It is on every Debian machine. It is on every Ubuntu machine. It is on every OS X machine. It is on every Windows (!) machine. And there are plenty of operations that are significantly more cumbersome to write in Ruby--otherwise, sure, I would do so. Backticks are nice, but there's no `set -e` (that I am aware of) and it becomes a huge hassle to do things in a sma…
Yes. Yes. Yes. Yes. No (unless Cygwin is installed).