From: dimke.fax@uni.de   
      
   William Unruh wrote:   
      
   > On 2014-09-29, Markus R. Keßler  wrote:   
   >> William Unruh wrote:   
   >>   
   >   
   >>> That does not matter.   
   >>> That command calls "bash" which means that the system will look through   
   >>> your path and use the first bash it comes across (in fact /tmp/bash   
   >>> almost certainly is nowhere on your path).   
   >>   
   >> That was the trick -- many thanks!   
   >>   
   >> So, I did the following:   
   >>   
   >> - /etc/passwd, entry for root: /bin/bash ==> /bin/dash   
   >   
   > It is of course OK to do that, but why? If they have logged in to root   
   > anyway, they can do anything already. Who cares if it is dash or bash as   
   > the default since they can always just do the command   
   > /bin/bash   
   > This does NOT replace bash as the default system shell (exec, sh,...)   
   > if your system is set up   
   > that way. It just replaces it as the default shell for root logons.   
   >   
   > I realise that this was temporary, but it was entirely unnecessary. Just   
   > replace bash.   
   > rpm -Uhv bash-4.2-49.1mga.i586.rpm   
   > and you are away at the races. No need to log off. No need to worry.   
   >   
   >> - init 3 (kill X.11)   
   >> - log off (from bash) and on (into dash) under root   
   >> - verify with lsof | grep /bin/bash that not in use   
   >> - replace /bin/bash with patched one   
   >> - undo /etc/passwd modification   
   >> - init 5   
   >> - log off from dash, log on into bash   
   >>   
   >>> So try   
   >>> env x='() { :;}; echo vulnerable' /tmp/bash -c 'echo hello'   
   >>   
   >> ...and now the expoit does not work any more on that box...   
   >>   
   >>   
   >>>> Logging in from text console (Ctrl-Alt-F1) into this user account did   
   >>>> not invoke /bin/bash and then /tmp/bash, but only /tmp/bash (the new   
   >>>> one).   
   >>>   
   >>> Nope. What you say is true for the bash whichis used by the login on the   
   >>> terminal, but not of that command. That command will use the first bash   
   >>> found in that user's path.   
   >>   
   >> What's still puzzling me is, that when updating Redhat, I just did a   
   >> "yum update bash" and there was no such logoff-login scenatio necessary.   
   >> I just apllied the update and the exploit instantly did not work   
   >> anymore.   
   >   
   > That was because the system bash was replaced so that when you did   
   > bash   
   > it was the new one that was used, not the old one.   
   > Had you updated mageia, the same would have happened. It was your   
   > attempt to test things out without replacing that caused the problems.   
   >   
   >   
   >>   
   >> I have no idea how Redhat installer did this in such a short and   
   >> convenient way.   
   >   
   > It simply replaced the current bash with the new one.   
      
   Hi,   
      
   any attempt to overwrite the current bash aborts with "busy".   
      
   The first workaround from above (/etc/passwd to dash and so on) indeed   
   seems to be more complicated than necessary -- I found out that simply   
   erasing the old bash (even though this is the current one in use) will   
   make it possible to write the new one afterwards.   
      
   cd /bin ; rm bash ; mv /tmp/newbash bash   
      
   will do the job. Weird.   
      
   Best regards,   
      
   Markus   
      
      
   --   
   Please reply to group only.   
   For private email please use http://www.dipl-ing-kessler.de/email.htm   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)