From: dimke.fax@uni.de
William Unruh wrote:
> 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?
Just mentioned one out of many versions I tried
>> - 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.
Yes, in one of the most recent patches there are comments which claim to
solve the problem. In bash43-025 they state:
"Under certain circumstances, bash will execute user code while
processing the environment for exported function definitions."
And the relevant source fragments related to these comments were
integrated into the source afterwards.
>> 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).
That was the trick -- many thanks!
So, I did the following:
- /etc/passwd, entry for root: /bin/bash ==> /bin/dash
- 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.
I have no idea how Redhat installer did this in such a short and
convenient way.
>> 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
>>
>>
--
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)
|
