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
