A patch from openSUSE was added to fix another buffer overflow:
http://openwall.com/lists/oss-security/2016/08/23/8

A CVE will probably come for that soon.

Updated packages in core/updates_testing:
========================
cracklib-2.9.2-2.2.mga5
libcrack2-2.9.2-2.2.mga5
libcrack2-python-2.9.2-2.2.mga5
cracklib-dicts-2.9.2-2.2.mga5
libcrack-devel-2.9.2-2.2.mga5

from cracklib-2.9.2-2.2.mga5.src.rpm

I have the update installed. 

In the link patch it mentioned the following. "To trigger the flaw, you need a specially-crafted "long" GECOS field, which can be done by a local user on the system. The attacker then needs to run some utility which uses cracklib to process this long GECOS field on the system. (such as "passwd" application which runs suid root)."  Is this now on me to replicate triggering the flaw?

s

CC: (none) => alexandersirris

I have the update installed. 

In the link patch it mentioned the following. "To trigger the flaw, you need a specially-crafted "long" GECOS field, which can be done by a local user on the system. The attacker then needs to run some utility which uses cracklib to process this long GECOS field on the system. (such as "passwd" application which runs suid root)."  Is this now on me to replicate triggering the flaw?

Yes, you are in at the deep end Alexander.  Normally testers should attempt to reproduce the bug or some aspect of it using hints from the backtrail of links.  In my experience PoCs are rarely available and even if they are the tester may not have the appropriate background to understand what is going on.  This community welcomes any attempts you might make in this respect but it all comes down to balancing the time you can afford and QA's workload.  Team leaders might advise you not to get too involved if it looks like a career move.  Some things we can only test at a shallow level, making sure the patched software still functions as it is supposed to or in extreme cases simply installs cleanly, i.e. without any obvious issues or conflicts.

Some testing before installing the update(s) may also be a good idea, particularly if a well defined PoC is available.  PoCs may not always be needed either.  Sometimes bugs manifest themselves directly when the software is run and command line testing gives you the opportunity to capture stack-traces and run things under strace or a debugger.

As before, apologies if I have over-stressed these points and thanks for joining the testing crew.  We definitely need you.

The link https://bugzilla.novell.com/attachment.cgi?id=688546 points to a C fragment supposed to test the patch.  This is linked from https://bugzilla.novell.com/show_bug.cgi?id=992966#c14 which gives an indication how to compile the reproducer(s) and shows expected results when the object files are run.  I have not tried any of this myself so have no idea if it would work.

Good luck.

CC: (none) => tarazed25

Ok I don't have a high level of experience but I'm going to take a crack (no pun intended) at trying to figure this out. I'll be sure to record my process.

>Created attachment 688546 [details]
>CVE-2016-6318.c

>QA REPRODUCER:

>gcc -O2 -Wall -g -o CVE-2016-6318 CVE-2016-6318.c -lcrack
>./CVE-2016-6318

I've downloaded the attachment that needs to be compiled, I believe the C fragment you are referring to. However, upon trying to reproduce using the gcc command I receive this error 

>gcc: command not found

I'm assuming the following attachment they have created will compile against cracklib and needs to be executed in the terminal. It contains the following code:

>extern const char *FascistCheck(const char *pw, const char *dictpath);
>extern char * FascistGecos(char *password, int uid);

>int main(int argc, char **argv) {
>	FascistCheck("tux", "/usr/lib/cracklib_dict");
>	FascistGecos("foobar", 45234);
>}

I tried to go to the Downloads/ directory where the file was located and run the following command

> ./CVE-2016-6318.c 
> ./CVE-2016-6318.c: Permission denied

Any idea why gcc does not compile the attached file?

It is possible that you do not have the development tools installed.  I am so used to specifying them at install time that I actually don't know what package(s) need to be installed.  There is probably a "task" package somewhere.  You could try 
$ urpmi gcc
as root and see what transpires.

No time just now but will try compiling the code here in the hope that it is complete.

By the way - the executable is CVE-2016-6318, without the extension.  I have tried the compilation before the update and found it produced an object file with execute permission.  There was a warning, which can probably be ignored.

Running the program produced no output.  
There seem to be three dict files on the system:
/usr/lib64/cracklib_dict.hwm
/usr/lib64/cracklib_dict.pwd
/usr/lib64/cracklib_dict.pwi
so I modified the C script.

	FascistCheck("tux", "/usr/lib64/cracklib_dict");

Which architecture are you running on?

Running the executable under strace provided an exit code though.

close(3)                                = 0
exit_group(648844256)                   = ?
+++ exited with 224 +++

I compiled the CVE-2016-6318-SLE12.c code after editing it to link to the 64-bit libraries and saw this result:

$ ./CVE-2016-6318-SLE12
*** buffer overflow detected ***: ./CVE-2016-6318-SLE12 terminated
======= Backtrace: =========
.......

which demonstrates the problem.

If you can sort out the gcc problem then all you have to do is follow the same steps.  You already have the updates installed so you should expect no error report from the ..SLE12 program.  If that is the case you can mark this update as OK.

HTH

> It is possible that you do not have the development tools installed.

I think that's what I'm missing, I'll look into it. 

>Running the program produced no output.  
>There seem to be three dict files on the system:
>/usr/lib64/cracklib_dict.hwm
>/usr/lib64/cracklib_dict.pwd
>/usr/lib64/cracklib_dict.pwi
>so I modified the C script.

>	FascistCheck("tux", "/usr/lib64/cracklib_dict");

>Which architecture are you running on?

32 bit

> I compiled the CVE-2016-6318-SLE12.c

With the .c extension? You mentioned...

>By the way - the executable is CVE-2016-6318, without the extension. 

I will try executing the code you provided asap. Len Lawrence you be my mentor? haha. I don't have one yet although rindolf said he would help me out where he can.

I would be honoured Alexander but I cannot promise much just now in the way of continuity because my personal life has been chaotic this summer and is unlikely to settle for another month.  Yes, Shlomi will probably find it difficult to find the time because he has quite a workload himself.

These exchanges are better handled through private emails so I shall drop a note in your inbox and we shall take it from there.  There are better teachers out there but we all have to take our turn.

Speak to you soon

Len

$ wget -O test.c https://bugzilla.novell.com/attachment.cgi?id=688546

CC: (none) => davidwhodgins, sysadmin-bugs
Keywords: (none) => validated_update
Whiteboard: (none) => advisory MGA5-32-OK

I'll finish this off for Alexander, running on x86_64.
Updated the packages and recompiled the two short programs, one to test the flaw against small GECOS fields and the other for large fields.  Both ran silently which indicates that the changes handle the problem.

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

http://advisories.mageia.org/MGASA-2016-0302.html

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