From: unruh@invalid.ca   
      
   On 2014-09-28, Markus R. Ke?ler  wrote:   
   > William Unruh wrote:   
   >   
   >> On 2014-09-28, Markus R. Ke?ler  wrote:   
   >>> Hi everybody,   
   >>>   
   >>> sure, you've already heard from one of the most severe bugs in linux   
   >>> bash these days.   
   >>>   
   >>> On my redhat machines it was no big challenge to fix the bug, because   
   >>> redhat created a patched version and put it into their repositories.   
   >>>   
   >>> Unfortunately, this is not possible with mandriva, of course.   
   >>   
   >> Well, it is. Madriva had patches out. But 2009.1 is 5 years old. Redhat   
   >> also doe not support 5 year old OSs.   
   >   
   > When updating some commercial servers recently, I got patches for Redhat   
   > 5 with kernel 2.6.18 (!). They provide updates for that ancient OS :-)   
   > But, yes, I know that this is commercial stuff and we pay for it.   
   >   
   >> You could always download bash source from a mageia mirror   
   >> (bash-4.2-49.1mga3.src.rpm) and compile it on your 2009.1 system.   
   >>   
   >>>   
   >>> So, on a box with mandriva 2009.1 / kernel 2.6.39.4, I got the shell   
   >>> sources and all patches from gnu.org, applied the patches successively   
   >>> and configured and made the executable.   
   >>   
   >> You do not tell use which source you got and which patches.  It is all   
   >> patches up to 49 --  bash42-049 that you need. Note that you need ALL   
   >> the patches, not just the last one.   
   >   
   > For bash 3.2 I did the following:   
      
   3.2? Why?   
      
   > - download and unpack the source   
   > - download all patches for this version   
   > - jump into the source dir   
   > - apply all patches in a loop:   
   >   for i in `ls ../bash-3.2-patches/bash32-0??` ; do   
   >       echo "$i:" ; patch -p0 < $i ;   
   >   done   
      
   And you know that those patches were supposed to solve the shellshock   
   problem? Have a look at the last couple of patches, and see if it says that it   
   solves   
   that problem.   
      
   >   
   > Afterwards I verifed the sources before and after patching (diff -qr   
   > original copy and patched version, vimdiff on file base when   
   > differences were found).   
   >   
   > I saw that the patches had been applied for sure.   
   >   
   >>> It can be invoked and does what it should, but unfortunately, before and   
   >>> after applying the patches and compiling, I always get as a   
   >>> result "vulnerable", when running the well-known test   
   >>>   
   >>> env x='() { :;}; echo vulnerable' bash -c 'echo hello'   
   >>>   
   >>> I tested this with different versions from 3.2 .. 4.3. but it's always   
   >>> the same.   
   >>>   
   >>> What's puzzling me even more, is, that I ran the above test on a redhat   
   >>> box, and after patching there appears no "vulnerable" any more, what   
   >>> means, the patch is valid. But, when downloading exactly this bash   
   >>> (2.05b) to my mandriva box, it runs, but there it shows "vulnerable"?!   
   >>   
   >> What does this mean "downloading exactly this bash"?   
   >> And where did you put this bash. Are you sure you do not have an old one   
   >> lying around that you are actually using?   
   >   
   > One of our admins created an ancient bash version (2.05b) and I   
   > downloaded this one, rather than create it by myself   
   >   
   > First I invoked bash over bash and when I saw that the exploit still   
   > worked, I created an /etc/passwd entry for a certain user, whose shell   
   > was no longer /bin/bash, but now was /tmp/bash.   
      
   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).   
      
   So try   
   env x='() { :;}; echo vulnerable' /tmp/bash -c 'echo hello'   
      
   >   
   > 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.   
      
   >   
   > But this also did not prevent the exploit from running "successfully".   
   >   
   >   
   >>> Does anyone have an idea what could cause this misbehaviour?   
   >>> A shell is one big monolithic executable, which does not install dozens   
   >>> of libraries out of its rpm, isn't it?   
   >>>   
   >>> Thanks for any hint.   
   >>>   
   >>> Best regards,   
   >>>   
   >>> Markus   
   >>>   
   >   
   > Thanks, best regards,   
   >   
   > Markus   
   >   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)