Last updated 24 July 2024

It was discovered that the Invariance Weakness of the RC4 stream cipher could be used to recover plaintext from a TLS connection, when RC4 encryption is used.

"The Invariance Weakness is an L-shape key pattern in RC4 keys, which once it exists in an RC4 key, preserves part of the state permutation intact throughout the initialization process. This intact part includes the least significant bits of the permutation, when processed by the PRGA algorithm, determines the least significant bits of the allegedly pseudo-random output stream along a long prefix of the stream."

This can lead to significant leakage of plaintext bytes from the ciphertext.

External Reference:

http://www.imperva.com/docs/HIIAttackingSSLwhenusingRC4.pdf

Last updated 24 July 2024

Last updated 24 July 2024

Description of problem: The compat ipc functions allow unprivileged users to read uninitialized stack memory, because some of the structures used and declared on the stack are not altered or zeroed before being copied back to the user.

Reference: http://www.openwall.com/lists/oss-security/2010/10/07/1 http://lkml.org/lkml/2010/10/6/492

Acknowledgements:

Red Hat would like to thank Dan Rosenberg for reporting this issue.

Description of problem: The "mem" array used as scratch space for socket filters is not initialized, allowing unprivileged users to leak kernel stack bytes.

http://www.spinics.net/lists/netdev/msg146361.html http://lists.grok.org.uk/pipermail/full-disclosure/2010-November/077321.html

Acknowledgements:

Red Hat would like to thank Dan Rosenberg for reporting this issue.

Description of problem: The semctl syscall has several code paths that lead to the leakage of uninitialized kernel stack memory (namely the IPCINFO, SEMINFO, IPCSTAT, and SEMSTAT commands) during the use of the older, obsolete version of the semidds struct. The copysemidtouser() function declares a semidds struct on the stack and copies it back to the user without initializing or zeroing the 'sembase', 'sempending', 'sempendinglast', and 'undo' pointers, allowing the leakage of 16 bytes of kernel stack memory. The code is still reachable on 32-bit systems - when calling semctl() newer glibc's automatically OR the IPC command with the IPC64 flag, but invoking the syscall directly allows users to use the older versions of the struct.

Reference: http://www.openwall.com/lists/oss-security/2010/10/06/6 http://www.spinics.net/lists/mm-commits/msg80234.html

Acknowledgements:

Red Hat would like to thank Dan Rosenberg for reporting this issue.

Description of problem: The old shm interface allows unprivileged users to read uninitialized stack memory, because shmidds structure declared on the stack is not altered or zeroed before being copied back to the user.

Reference: http://www.openwall.com/lists/oss-security/2010/10/07/1 http://lkml.org/lkml/2010/10/6/454

Acknowledgements:

Red Hat would like to thank Vasiliy Kulikov of Openwall and Kees Cook for reporting this issue.

Description of problem: The VIAFBGETINFO device ioctl allows unprivileged users to read 1968 bytes of uninitialized stack memory, because the "reserved" member of the viafbioctlinfo struct declared on the stack is not altered or zeroed before being copied back to the user.

Reference: http://www.openwall.com/lists/oss-security/2010/10/06/6 http://lkml.indiana.edu/hypermail//linux/kernel/1009.1/03392.html

Acknowledgements:

Red Hat would like to thank Dan Rosenberg for reporting this issue.

arch/x86/kvm/x86.c in the Linux kernel before 2.6.36.2 does not initialize certain structure members, which allows local users to obtain potentially sensitive information from kernel stack memory via read operations on the /dev/kvm device.

Description of problem: http://lkml.org/lkml/2010/9/11/168 The EQLGETMASTRCFG device ioctl allows unprivileged users to read 16 bytes of uninitialized stack memory, because the "mastername" member of the masterconfigt struct declared on the stack in eqlgmastercfg() is not altered or zeroed before being copied back to the user.

Acknowledgements:

Red Hat would like to thank Dan Rosenberg for reporting this issue.

Description of problem: http://lkml.org/lkml/2010/9/11/170 The CHELSIOGETQSETNUM device ioctl allows unprivileged users to read 4 bytes of uninitialized stack memory, because the "addr" member of the chreg struct declared on the stack in cxgbextensionioctl() is not altered or zeroed before being copied back to the user.

Acknowledgements:

Red Hat would like to thank Dan Rosenberg for reporting this issue.

Description of problem: http://lkml.org/lkml/2010/9/11/167

The TIOCGICOUNT device ioctl allows unprivileged users to read 9 bytes of uninitialized stack memory, because the "reserved" member of the serialicounterstruct struct declared on the stack in hsogetcount() is not altered or zeroed before being copied back to the user. This patch takes care of it.

Acknowledgements:

Red Hat would like to thank Dan Rosenberg for reporting this issue.

Description of problem: There is a problem with the ioctl subsystem for drm, though it is most explicitly exposed by the intel GEM driver. Under driver-defined ioctls, drm does not sanitize the ioctl command, allowing the caller to specify how much memory should be kmalloc'd and copied back to the caller, regardless of what the driver ioctl actually does (it doesn't even need to succeed).

drivers/gpu/drm/drmdrv.c

long drmioctl(struct file filp, unsigned int cmd, unsigned long arg) ... unsigned int nr = DRMIOCTLNR(cmd); ... if ((nr >= DRMCOMMANDBASE) && (nr < DRMCOMMANDEND) && (nr < DRMCOMMANDBASE + dev->driver->numioctls)) ioctl = &dev->driver->ioctls[nr - DRMCOMMANDBASE]; ... if (cmd & (IOCIN | IOCOUT)) { if (IOCSIZE(cmd) <= sizeof(stackkdata)) { kdata = stackkdata; } else { kdata = kmalloc(IOCSIZE(cmd), GFPKERNEL); ... } } ... retcode = func(dev, kdata, filepriv); ... if (cmd & IOCOUT) { if (copytouser((void user )arg, kdata, IOCSIZE(cmd)) != 0) retcode = -EFAULT; }

"cmd" is caller-controlled, and can do whatever it likes for IOCSIZE(cmd), IOCIN and IOCOUT, resulting in leakage of previously freed kernel heap memory contents up to 16K in size.

Description of problem: Calling ETHTOOLGRXCLSRLALL with a large rulecnt will allocate kernel heap without clearing it. For the one driver (niu) that implements it, it will leave the unused portion of heap unchanged and copy the full contents back to userspace.

This is different from CVE-2010-2478, but was introduced at the same time (0853ad66, 2.6.27-rc1).

Upstream commit: http://git.kernel.org/linus/ae6df5f96a51818d6376da5307d773baeece4014

Acknowledgements:

Red Hat would like to thank Kees Cook for reporting this issue.

Directory traversal vulnerability in pure-FTPd 1.0.22 and possibly other versions, when running on SUSE Linux Enterprise Server and possibly other operating systems, when the Netware OES remote server feature is enabled, allows local users to overwrite arbitrary files via unknown vectors.