Re: [OpenIndiana-discuss] Bash bug issue
We have tested all our systems, and the only ones that were vulnerable (in cgi-bin) were ones that we had put in a bash script to test. if you don't have any bash scripts in your cgi-bin, and your default system shll is not bash (and on Solaris, and Ubuntu it isn't) then you pretty much aren't exploitable via a web-server. there are possible issues if you have restricted users/remote logons ... if the user has the bash shell as their default it is possible to escape from the restricted environment. e.g. http://troy.jdmz.net/rsync/index.html where you have a validate-rsync procedure that checks if you are connecting with the command rsync ... (the easiest way to fix the above is to create an rsyncd server and connect to that, rather than ssh'ing) also, although it's annoying you probably want to go around and delete all your authorized_keys files so that you cannot ssh in without a password. I'm not sure, but I've been told that github/heroku use bash for the shells that they allow remote connections on, I don't know if they are exploitable remotely, but I don't really want to check that out :) remember that you can only use this bug to run commands as the user who is logged on ... if the person knows the username and password already then they can just run the command straight. Jon On 30 September 2014 09:40, Jim Klimov jimkli...@cos.ru wrote: 29 сентября 2014 г. 17:46:20 CEST, Jason Matthews ja...@broken.net пишет: paraphrasing Joshua from WarGames, bash is a strange game where the only winning move is not to play. J. Sent from my iPhone On Sep 29, 2014, at 2:43 AM, Udo Grabowski (IMK) udo.grabow...@kit.edu wrote: As predicted, there's more bash horror (Score 11): ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss Maybe a stupid question on my side (sorry i'm overwhelmed with relocation and other life events), but how really is this bug exploitable? Especially on Solaris and illumos systems with sh/ksh by default and assumed no scripted CGI (hosts of native or java sourced web-code though) ? I mean, from what I gather, the bug allows to execute unexpected code with credentials of the user that executes bash. On a local system someone should already have a login to do that (or a hacked backdoor), so may have other means for doing mischief. Can it be used to elevate? How? Via config files for root-executed initscripts and cronjobs? If these are editable by a random untrustworthy user, the system is already busted without the bug... I kinda get the point about web-scripts especially where system programs can be called with the default shell of the webserver account (bash for some), although did not really grasp from cursory looks at the articles just how the env-function can be passed via http requests to do the exploit. Let's assume it can be done... as protection/precaution, would it suffice to make sure that apache's and such do not use bash in their /etc/passwd fields (and restart the daemons)? Also, did anyone (beside Oracle) already build and publish a replacement SUNWbash for legacy Solaris 8-10 systems? ;) Thanks, Jim -- Typos courtesy of K-9 Mail on my Samsung Android ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Bash bug issue
On Tue, 30 Sep 2014, Jim Klimov wrote: Maybe a stupid question on my side (sorry i'm overwhelmed with relocation and other life events), but how really is this bug exploitable? Especially on Solaris and illumos systems with sh/ksh by default and assumed no scripted CGI (hosts of native or java sourced web-code though) ? It is readily exploitable for web CGI scripts which provide/export values provided by the web server and remote client as environment variables. The CGI paradigm has thoroughly permiated web application infrastructures. The exploit requires that bash be executed with the problematic environment variables already set. Service applications obtained from Linux often require bash in order to run. On my own systems, the only service I found which was suspect was 'git' and 'gitweb.cgi' since the 'git' implementation depends on many shell scripts, which specifically depend on bash. For example, this is output from the test-cgi script provided with Apache: CGI/1.0 test script report: argc is 0. argv is . SERVER_SOFTWARE = Apache/2.0.63 (Unix) DAV/2 SERVER_NAME = www.simplesystems.org GATEWAY_INTERFACE = CGI/1.1 SERVER_PROTOCOL = HTTP/1.1 SERVER_PORT = 80 REQUEST_METHOD = GET HTTP_ACCEPT = text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 PATH_INFO = PATH_TRANSLATED = SCRIPT_NAME = /cgi-bin/test-cgi QUERY_STRING = REMOTE_HOST = REMOTE_ADDR = 65.66.245.66 REMOTE_USER = AUTH_TYPE = CONTENT_TYPE = CONTENT_LENGTH = and this is output from a Perl script called 'printenv' which prints everything made available: DOCUMENT_ROOT=/html GATEWAY_INTERFACE=CGI/1.1 HTTP_ACCEPT=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 HTTP_ACCEPT_ENCODING=gzip, deflate HTTP_ACCEPT_LANGUAGE=en-US,en;q=0.5 HTTP_CONNECTION=keep-alive HTTP_HOST=www.simplesystems.org HTTP_USER_AGENT=Mozilla/5.0 (X11; SunOS i86pc; rv:30.0) Gecko/20100101 Firefox/30.0 PATH=/usr/sbin:/usr/bin QUERY_STRING= REMOTE_ADDR=65.66.245.66 REMOTE_PORT=53877 REQUEST_METHOD=GET REQUEST_URI=/cgi-bin/printenv SCRIPT_FILENAME=/var/apache2/cgi-bin/printenv SCRIPT_NAME=/cgi-bin/printenv SERVER_ADDR=65.66.246.89 SERVER_ADMIN=webma...@simplesystems.org SERVER_NAME=www.simplesystems.org SERVER_PORT=80 SERVER_PROTOCOL=HTTP/1.1 SERVER_SIGNATURE=addressApache/2.0.63 (Unix) DAV/2 Server at www.simplesystems.org Port 80/address\n SERVER_SOFTWARE=Apache/2.0.63 (Unix) DAV/2 TZ=US/Central UNIQUE_ID=rExdoEFC9koAAEJpoxgJ -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] destroy all but specific snapshot
Tim Aslat t...@spyderweb.com.au writes:
Simplest option would be something like
zfs list -t snapshot -o name -H -r filesystem/path /tmp/snaplist.txt
edit /tmp/snaplist.txt to remove the snapshot you want to keep
for SNAP in `cat /tmp/snaplist.txt`
do
zfs destroy $SNAP
done
My syntax may be a little off with the for loop but I'm sure you get the
idea.
Cheers
Thanks for the input... I did think of something like that employing
a four loop but it seemed a bit cumbersome
So I thought I'd check once more thru the oracle stuff online about
snapshots and damned if I didn't stumble up on something that seems to
be one way to go, honestly its not a whole lot less (if any) less
cumbersome though.
http://docs.oracle.com/cd/E19253-01/819-5461/6n7ht6r4f/index.html
(Look under Holding ZFS Snapshots)
It revolves around the `hold' command which is really more of a
property I guess.
You pick out the snap[s] you want (in my case it was just one) and
label it with: `zfs hold LABEL zp/path/dir@SNAP'
Then you maybe use the -r flag with destroy or a four loop like I did:
I didn't have any complicated snaps behind clones or what not.
cd .../.zfs/snspshot
for SNAP in `ls -d *`;do zfs destroy zp/path/dir@${SNAP};done
When it hits the one with the `hold NAME' it reports that fact then
finishes off the rest.
You can then `release' the `hold' with: zfs release zp/path/dir@SNAP
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] destroy all but specific snapshot
On 9/30/2014 8:31 PM, Tim Aslat wrote:
Harry Putnam wrote on 01/10/2014 09:52:
This is not so easy to find in google searches
How does one go about destroying all but a specific snapshot? The one
I want is somewhere in the middle timewise So not wanting to use
`destroy -r'.
This is in a .zfs/snapshot/* where there are many auto snaps. So
looking for a way besides destroying -r or 1 by 1.
Hi Harry,
Simplest option would be something like
zfs list -t snapshot -o name -H -r filesystem/path /tmp/snaplist.txt
edit /tmp/snaplist.txt to remove the snapshot you want to keep
for SNAP in `cat /tmp/snaplist.txt`
do
zfs destroy $SNAP
done
Here's an equivalent one liner for you.
zfs list -t snapshot -H pool | grep -v the one you want to exclude |
awk '{print $1}' | xargs -n 1 zfs destroy
(you should run up to the last pipe and confirm that's what you want
before adding on the xargs. ;)
* warning: if you have replication to a backup server, removing all of
the snapshots for other filesystems will make those replicated snapshots
non-operative.
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] destroy all but specific snapshot
Yah, the paranoid part of my reptilian brain tells me not to issue a destroy
command on a resource I want to keep.
That said, it should be fine.
Sent from my iPhone
On Sep 30, 2014, at 6:53 PM, Harry Putnam rea...@newsguy.com wrote:
Tim Aslat t...@spyderweb.com.au writes:
Simplest option would be something like
zfs list -t snapshot -o name -H -r filesystem/path /tmp/snaplist.txt
edit /tmp/snaplist.txt to remove the snapshot you want to keep
for SNAP in `cat /tmp/snaplist.txt`
do
zfs destroy $SNAP
done
My syntax may be a little off with the for loop but I'm sure you get the
idea.
Cheers
Thanks for the input... I did think of something like that employing
a four loop but it seemed a bit cumbersome
So I thought I'd check once more thru the oracle stuff online about
snapshots and damned if I didn't stumble up on something that seems to
be one way to go, honestly its not a whole lot less (if any) less
cumbersome though.
http://docs.oracle.com/cd/E19253-01/819-5461/6n7ht6r4f/index.html
(Look under Holding ZFS Snapshots)
It revolves around the `hold' command which is really more of a
property I guess.
You pick out the snap[s] you want (in my case it was just one) and
label it with: `zfs hold LABEL zp/path/dir@SNAP'
Then you maybe use the -r flag with destroy or a four loop like I did:
I didn't have any complicated snaps behind clones or what not.
cd .../.zfs/snspshot
for SNAP in `ls -d *`;do zfs destroy zp/path/dir@${SNAP};done
When it hits the one with the `hold NAME' it reports that fact then
finishes off the rest.
You can then `release' the `hold' with: zfs release zp/path/dir@SNAP
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
