PoC: https://bugzilla.redhat.com/show_bug.cgi?id=1157689

$ cat cve20147817.c 
#include <wordexp.h>
int main (void)
{
  wordexp_t we;
  return wordexp ("$((1`touch /tmp/x`))", &we, WRDE_NOCMD);
}



Testing mga3 32

$ gcc -o testcase cve20147817.c 
$ ./testcase

$ ll /tmp/x
-rw-r--r-- 1 claire claire 0 Nov 23 23:14 /tmp/x

$ rm -f /tmp/x
$ rm -f testcase

Installing updates and rebooting.

Whiteboard: MGA3TOO => MGA3TOO has_procedure

After reboot..

$ gcc -o testcase cve20147817.c 
$ ./testcase
$ ll /tmp/x
ls: cannot access /tmp/x: No such file or directory

Whiteboard: MGA3TOO has_procedure => MGA3TOO has_procedure mga3-32-ok

Thank you MrsB for the detailed testing procedure!

Testing complete on Mga4 i586, everything OK. Following the procedure from comment 3, I got the exact same results as MrsB (both before and after the update).

CC: (none) => wassi
Whiteboard: MGA3TOO has_procedure mga3-32-ok => MGA3TOO has_procedure mga3-32-ok mga4-32-ok

Testing on Mageia3-64 real hardware
using Claire's procedure in comment 1

$ rpm -q glibc
glibc-2.17-7.5.mga3
$ ll /tmp/x
-rw-r--r-- 1 zitounu zitounu 0 nov.  24 20:58 /tmp/x


$ rpm -q glibc
glibc-2.17-7.6.mga3
$ ll /tmp/x
ls: impossible d'accéder à /tmp/x: Aucun fichier ou dossier de ce type

All OK

CC: (none) => olchal
Whiteboard: MGA3TOO has_procedure mga3-32-ok mga4-32-ok => MGA3TOO has_procedure mga3-32-ok MGA3-64-OK mga4-32-ok

Testing MGA4-64 on HP6555b
Same result as Claire's Comment 3

CC: (none) => herman.viaene
Whiteboard: MGA3TOO has_procedure mga3-32-ok MGA3-64-OK mga4-32-ok => MGA3TOO has_procedure mga3-32-ok MGA3-64-OK mga4-32-ok MGA4-64-OK

Validating. Advisory uploaded.

Please push to updates.

Keywords: (none) => validated_update
Whiteboard: MGA3TOO has_procedure mga3-32-ok MGA3-64-OK mga4-32-ok MGA4-64-OK => MGA3TOO has_procedure advisory mga3-32-ok MGA3-64-OK mga4-32-ok MGA4-64-OK
CC: (none) => sysadmin-bugs

I'm not highly confident about rushing the glibc update after only 1 test per arch, given the issues we've had in the past, especially when most of the testing went into testing a POC and even more for mga3 where we won't be able to fix any regression due to this update.

Couldn't we wait for a few days? I know mga3 is EOLed today, but maybe EOL should mean "no more update candidates, but we will handle the remaining updates in the pipe", not "let's push everything we've got before it's too late". Or we shouldn't have accepted an update candidate to glibc for mga3 at all knowing that the time was too short.

CC: (none) => stormi

It's been here for 3 days already. Mga3 EOL means no further updates so let's push please.

Feel free to separate mga4 to a separate bug and we'll handle it separately, you'll also need to split the advisory if you do.

The alternative is not to push in mga3 and clean it from updates_testing

I know what EOL means, and I think there should have been a delay of at least one week between the last update candidate and the actual EOL.

I'm just pointing at a risk, I won't split the bug if I'm the only one thinking it's too fast for a glibc update.

Not pushing it is an alternative indeed, but maybe Thomas can maybe tell about the risks he thinks there are (or aren't).

You could test it too :)

I'll install it on my mga4 workstation, for sure :)

Can we delay this one for a few hours, and I'll send an urgent call for testing to the mailing list?

Certainly. I'll remove the validated_update keyword in case others are script pushed before this is ready.

We will need a push/no-push today though please.

Keywords: validated_update => (none)

This is ready for validation.  The change in this patch doesn't affect many programs in practice.  See this post for a list:
http://www.openwall.com/lists/oss-security/2014/11/21/9

So, for the paranoid, if you want to double-check that Flash still works just fine (including sound) and that the mailx package (i.e. the mail command) still works without errors, then you should feel comfortable that this update doesn't cause any regressions.

Well, the paranoid would not take the nature of the patch into account for such a package as glibc ;)

No obvious regression seen here on Mageia 3 32bit in vbox.
Among other tests, I made sure that flash works fine as advised by David.

CC: (none) => remi

I have not mentionned it here, but I've been using glibc-2.18-9.5.mga4.x86_64.rpm without any issue for some days as it was installed automatically with another testing package even before it was assigned to QA team.

As I did not test it using the PoC, I have not reported it her.

Testing package glibc for Mageia3-64 still runs well on my Mageia3-64 installation since my comment 4.

Both are on real hardware.

(In reply to Samuel VERSCHELDE from comment #10)

> 
> Not pushing it is an alternative indeed, but maybe Thomas can maybe tell
> about the risks he thinks there are (or aren't).


There should not be any problems with it as the only thing the fix does is:

https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=posix/wordexp.c;h=26f3a2653feba2b1a5904937d9d6b58c32109e24;hp=b6b65dd993ec7e2ee5e3e88f8800c2e254cb9d5f;hb=a39208bd7fb76c1b01c127b4c61f9bfd915bfe7c;hpb=130ac68ca25c9aa65e027e3e37337bc048205c69

wich in short does as per the upstrem commit message:

This patch fixes this by checking for WRDE_NOCMD
in exec_comm(), the only place that can execute a shell. All other
checks for WRDE_NOCMD are superfluous and removed.

so it "simply" moves an existing check up earlier in the call chain.

as for testing reference.. 
I also have it running on 2 live mga4 x86_64 servers and my mga4 x86_64 laptop since Saturday 22nd

It have no single problems in my test install it's fine to push it now until Mga3 eol.

CC: (none) => ozkyster

Thanks everybody for the extra tests and information.

I'm re-validating but please don't hesitate to mention any issues before the update is pushed, which should be later today.

Keywords: (none) => validated_update

ah, it was already revalidated.

Anyway, no issues here, everything works as expected (Mga3, 64bits, NVidia card), including HDvideo + sound + subtitles

CC: (none) => marja11

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGASA-2014-0496.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED