CVE-2011-1071 POC - http://www.securityfocus.com/bid/46563/exploit
CVE-2011-1095 POC - https://bugzilla.redhat.com/show_bug.cgi?id=625893
Don't use "rm -rf /"!
CVE-2011-1659 Possible POC - http://sourceware.org/bugzilla/show_bug.cgi?id=11883

CVE-2011-1095: doesn't appear to be fixed.

Before installing the update ...
$ LANG=' echo rm -rf /' locale
LANG= echo rm -rf /
After installing the update ...
$ LANG=' echo rm -rf /' locale
LANG=\ echo\ rm\ -rf\ /

So it's now escaping the spaces, but is still allowing
potentially dangerous commands to be set in the LANG.

CC: (none) => davidwhodgins

Thinking about this a bit more, I don't see this as a security
threat.  In order to do anything with this, the users envifonment
must be modified prior to executing a script that uses eval with
the locale commend.

If the "intruder" can modify the environment, they have user
level access already.

Scripts cannot be run with setuid or setgid, so in order to do
anything with this, the "intruder" would have to be able to
modify the root users environment.   If they can do that, then
they already have root access.

What am I missing that makes this a security vulnerability?

Regarding CVE-2011-1071, before the update ...
$ ./46563 3000000
Segmentation fault
After the update ...
$ ./46563 3000000
$

So that ones fixed.

The poc code for CVE-2011-1659 is identical to the code for CVE-2011-1071,
so that ones fixed too.

Unless a change is required due to comment 2, I consider testing complete
on i586 for the srpm
glibc-2.12.1-11.3.mga1.src.rpm

Tested OK here too x86_64

No errors in any logs and kernel modules built OK with the new kernel.

Validating


Advisory
-----------------------
Advisory:
This update addresses the following CVEs:

* CVE-2011-1071:
  The GNU C Library (aka glibc or libc6) before 2.12.2 and Embedded GLIBC
  (EGLIBC) allow context-dependent attackers to execute arbitrary code or
  cause a denial of service (memory consumption) via a long UTF8 string
  that is used in an fnmatch call, aka a "stack extension attack," a
  related issue to CVE-2010-2898, CVE-2010-1917, and CVE-2007-4782,
  as originally reported for use of this library by Google Chrome.


* CVE-2011-1095:
  locale/programs/locale.c in locale in the GNU C Library (aka glibc or
  libc6) before 2.13 does not quote its output, which might allow local
  users to gain privileges via a crafted localization environment
  variable, in conjunction with a program that executes a script that
  uses the eval function.


* CVE-2011-1659:
  Integer overflow in posix/fnmatch.c in the GNU C Library (aka glibc or
  libc6) 2.13 and earlier allows context-dependent attackers to cause a
  denial of service (application crash) via a long UTF8 string that is
  used in an fnmatch call with a crafted pattern argument, a different
  vulnerability than CVE-2011-1071.
-----------------------

SRPM: glibc-2.12.1-11.3.mga1.src.rpm

Could sysadmin please push from core/updates_testing to core/updates.
Please see comment 2 and comment 3 before pushing.


Thankyou!

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

(In reply to comment #2)
> CVE-2011-1095: doesn't appear to be fixed.
> 

It is.

> Before installing the update ...
> $ LANG=' echo rm -rf /' locale
> LANG= echo rm -rf /
> After installing the update ...
> $ LANG=' echo rm -rf /' locale
> LANG=\ echo\ rm\ -rf\ /
> 

before: 
if you set: LANG=' rm -rf /'
and a program does something like: eval $(locale)

say bye-bye to your system...

after the fix, your system is still safe...

> So it's now escaping the spaces, but is still allowing
> potentially dangerous commands to be set in the LANG.

The escaping of the LANG will make the potential dangerous command to be treated as text, not as a command, and thereby it wont do any damage.

update pushed.

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