It was found that glibc's utility, responsible for editing of system's mtab table, improperly sanitized user supplied mount point names containing certain special character. Local attacker could use this flaw to add arbitrary mount points (corrupt system's "/etc/mtab" file) or, potentially, set unauthorized mount options. Other attacks are also possible.

Issue severity note: ------------------- The /etc/mtab file handles mounted devices and is automatically updated by the mount command (more precisely by the dedicated "mount" tool for relevant filesystem). Unprivileged user to be able to run such a tool (and modify content of /etc/mtab), this tool needs to be suid root enabled. The dedicated "mount" tools, as shipped with Red Hat Enterprise Linux (mount.cifs, mount.fuse, fusermount, mount.nfs, mount.nfs4) does NOT allow unprivileged user to use them (without prior grant of additional privileges from the privileged user) for editing of system's /etc/mtab file, which mitigates impact of this flaw.

Integer signedness error in the elfgetdynamicinfo function in elf/dynamic-link.h in ld.so in the GNU C Library (aka glibc or libc6) 2.0.1 through 2.11.1, when the --verify option is used, allows user-assisted remote attackers to execute arbitrary code via a crafted ELF program with a negative value for a certain dtag structure member in the ELF header.

Common Vulnerabilities and Exposures assigned an identifier CVE-2009-4880 to the following vulnerability:

Multiple integer overflows in the strfmon implementation in the GNU C Library (aka glibc or libc6) 2.10.1 and earlier allow context-dependent attackers to cause a denial of service (memory consumption or application crash) via a crafted format string, as demonstrated by a crafted first argument to the moneyformat function in PHP, a related issue to CVE-2008-1391.

References: [1] http://securityreason.com/achievementsecurityalert/67 [2] https://bugzilla.redhat.com/showbug.cgi?id=524671 [3] http://sources.redhat.com/bugzilla/showbug.cgi?id=10600 [4] http://sourceware.org/git/?p=glibc.git;a=commit;h=199eb0de8d673fb23aa127721054b4f1803d61f3 [5] http://www.ubuntu.com/usn/USN-944-1 [6] http://www.securityfocus.com/bid/36443 [7] http://secunia.com/advisories/39900 [8] http://www.vupen.com/english/advisories/2010/1246

Public PoC (from [3]):

[cx@localhost ~]$ php -r 'moneyformat("%.1073741821i",1);' Segmentation fault

Stack consumption vulnerability in the regcomp implementation in the GNU C Library (aka glibc or libc6) through 2.11.3, and 2.12.x through 2.12.2, allows context-dependent attackers to cause a denial of service (resource exhaustion) via a regular expression containing adjacent repetition operators, as demonstrated by a {10,}{10,}{10,}{10,} sequence in the proftpd.gnu.c exploit for ProFTPD.

Maksymilian Arciemowicz reported a deficiency in the way glibc regular expression engine processed certain patterns. A local attacker could use this flaw to cause a denial of service (crash due stack overflow).

Note: The above described behavior is a limitation of glibc regular expression engine. Regular expression matching function is called recursively for certain types of patterns (where subexpression using quantifier is nested inside of another quantified expression), where long input can result in deep recursion and exhaustion of all stack memory (i.e. impact is limited to crash). Amount of stack memory available to glibc regular expression engine influences the size of input that must be provided to trigger the crash. Alternatively, expression can be modified to avoid quantification nesting, or program modified to limit size of input passed to regular expression engine.

Conclusion: Due the above described behavior Red Hat Security Response Team would not classify this deficiency to be a security issue.

References: [1] http://www.kb.cert.org/vuls/id/912279 [2] http://www.securityfocus.com/archive/1/515589 [3] http://forums.cnet.com/7726-6132102-5042238.html [4] http://secunia.com/advisories/42547/ [5] http://securityreason.com/securityalert/8003

A security flaw was found in the way strcoll() interface of glibc, the GNU libc libraries, performed failsafe back to alloca() routine when malloc() function call failed previously (due to out of memory [OOM] condition for example). If an application linked against glibc was missing an application-level sanity checks for validity of strcoll() arguments and accepted untrusted input, an attacker could use this flaw to cause the particular application to crash or, potentially, execute arbitrary code with the privileges of the user running the application.

Upstream bug report (including the reproducer): [1] http://sourceware.org/bugzilla/showbug.cgi?id=14552#c0

Issue / part: 1) alloca() stack overflow from [1].

References: [2] http://www.openwall.com/lists/oss-security/2012/09/07/9 [3] http://www.openwall.com/lists/oss-security/2012/09/07/15 [4] http://www.openwall.com/lists/oss-security/2012/09/10/1 [5] http://www.openwall.com/lists/oss-security/2012/09/10/3 [6] http://www.openwall.com/lists/oss-security/2012/09/13/16

An integer overflow, leading to buffer overflow flaw was found in the way the implementation of strcoll() routine, used to compare two strings based on the current locale, of glibc, the GNU libc libraries, performed calculation of memory requirements / allocation, needed for storage of the strings. If an application linked against glibc was missing an application-level sanity checks for validity of strcoll() arguments and accepted untrusted input, an attacker could use this flaw to cause the particular application to crash or, potentially, execute arbitrary code with the privileges of the user running the application.

Upstream bug report (including reproducer): [1] http://sourceware.org/bugzilla/showbug.cgi?id=14547