Integer signedness error in the CIFSFindNext function in fs/cifs/cifssmb.c in the Linux kernel before 3.1 allows remote CIFS servers to cause a denial of service (memory corruption) or possibly have unspecified other impact via a large length value in a response to a read request for a directory.

Dan Kaminsky pointed out that using partial MD4 and using that to generate a sequence number, of which only 24-bits are truly unguessable, seriously undermine the goals of random sequence number generation.

In particular, with only 24-bits being truly unguessable, packet injection into a session using even something like brute force is a real potential possibility.

We only use 24-bits because we regenerate the random number every 5 minutes "just in case." But what does is trade a "we don't know" kind of theoretical issue for a provably real one (brute force attack).

Therefore [Dave Miller] moving us more in line with RFC1948 (as well as OpenBSD and Solaris), to use MD5 and a full 32-bit result in the generated sequence number.

MD5 was selected as a compromise between performance loss and theoretical ability to be compromised. Willy Tarreau did extensive testing and SHA1 was found to harm performance too much to be considered seriously at this time.

We may later add a sysctl for various modes (ie. a "super secure" mode that uses SHA1 if people want that, and an "insecure" mode that doesn't use cryptographic hashing at all for people in protected environments where that might be safe to do).

[Dave Miller] also moved the sequence number generators out of random.c (they never really belonged there, and are only there due to historical artifacts), and fixed a bug in DCCP sequence number generation (on ipv6 the 43-bit sequence number was truncated to 32-bits).

Acknowledgements:

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

Currently, we skip doing the ispathaccessible check in cifsmount if there is no prefixpath. There is a report of at least one server however that allows a TREECONNECT to a share that has a DFS referral at its root. UNC that had no prefixpath was used in that case, so the ispathaccessible check was not triggered and the box later hit a BUG() because we were chasing a DFS referral on the root dentry for the mount. Upstream fix: 70945643722ffeac779d2529a348f99567fa5c33

References: https://bugzilla.redhat.com/showbug.cgi?id=682829 https://github.com/torvalds/linux/commit/70945643722ffeac779d2529a348f99567fa5c33

Acknowledgements:

Red Hat would like to thank Yogesh Sharma for reporting this issue.

Last updated 24 July 2024

Last updated 24 July 2024

IPv6 fragment identification generation is way beyond what we use for IPv4 : It uses a single generator. Its not scalable and allows DOS attacks.

Now inetpeer is IPv6 aware, we can use it to provide a more secure and scalable frag ident generator (per destination, instead of system wide)

This patch : 1) defines a new secureipv6id() helper 2) extends inetgetid() to provide 32bit results 3) extends ipv6selectident() with a new dest parameter

http://thread.gmane.org/gmane.linux.network/201773

Acknowledgements:

Red Hat would like to thank Fernando Gont for reporting this issue.

Multiple use-after-free vulnerabilities in libxml2 2.5.10, 2.6.16, 2.6.26, 2.6.27, and 2.6.32, and libxml 1.8.17, allow context-dependent attackers to cause a denial of service (application crash) via crafted (1) Notation or (2) Enumeration attribute types in an XML file, as demonstrated by the Codenomicon XML fuzzing framework.

A buffer overflow flaw was found in the Linux kernel's Auerswald PBX/System Telephone usb driver implementation. There's no upstream patch as the affected driver was removed from the kernel in 2.6.27.

For more information, check out the references: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4067 http://labs.mwrinfosecurity.com/files/Advisories/mwrilinux-usb-buffer-overflow2009-10-29.pdf

Acknowledgement:

Red Hat would like to thank Rafael Dominguez Vega for reporting this issue.

Description of problem:

Alexei Dobryanov has reported the following kernel utrace related issue (BZ#245735):

1. late ptracemayattach() check

static int ptraceattach(struct taskstruct task) { ... engine = utraceattach(task, (UTRACEATTACHCREATE | UTRACEATTACHEXCLUSIVE | UTRACEATTACHMATCHOPS), &ptraceutraceops, 0); [error checking] if (ptracemayattach(task)) { [more attaching process]

Doing may attach check there is asking for trouble, because utraceattach() will happily create and modify "struct utrace " and create and attach engines to it on task you don't have permissions. Order should be reverted. That's easy.

2. race around &deadengineops setting...

I originally thought #1 would lead to memory leaks, however, written dumb PTRACEATTACH'er gave much more amazing results.

The following program quickly (1 sec) oopses kernel when run against process you normally can't attach to (like normal user to getty processes)

#include <stdlib.h> #include <sys/ptrace.h>

int main(int argc, char argv[]) { pidt pid = atoi(argv[1]);

while (1) ptrace(PTRACEATTACH, pid, NULL, NULL);

return 0; }

Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: [<0000000000000000>] [<ffffffff8005f1cd>] reportquiescent+0x36/0x154 [<ffffffff8005f316>] utracequiescent+0x2b/0x238 [<ffffffff800601e9>] utracegetsignal+0x45d/0x4c0 [<ffffffff80039c6f>] getsignaltodeliver+0x169/0x47a [<ffffffff80008f5a>] donotifyresume+0xd0/0x7e2 [<ffffffff80203673>] spinunlockirqrestore+0x3f/0x45 [<ffffffff80051d71>] tracehardirqson+0x11b/0x13f [<ffffffff801400c0>] ttyread+0x81/0xc7 [<ffffffff80202ede>] tracehardirqsonthunk+0x35/0x37 [<ffffffff80051d71>] tracehardirqson+0x11b/0x13f [<ffffffff80009b43>] sysretsignal+0x21/0x31 [<ffffffff80009deb>] ptregscallcommon+0x67/0xac

This is a race we chatted with Roland about: http://marc.info/?l=linux-kernel&m=117863520707703&w=2

engine's flags and ops settings in utracedetach() and acting on them in reportquiescent():

utracedetach() reportquiescent() --------------- ------------------ [utrace lock held] [utrace lock is not held]

engine->flags = UTRACEEVENT(QUIESCE) | UTRACEACTIONQUIESCE;

if (engine->flags & UTRACEEVENT(QUIESCE)) REPORT(reportquiesce);

rcuassignpointer(engine->ops, &deadengineops);

At the moment of REPORT call engine's ops are still "live" ptrace ops which do not have ->reportquiesce callback. So, there will oops while calling function at NULL address. "Dead" ptrace engine ops do have dummy callback but it wasn't yet glued.

Obviously, patch #1 won't fix this.

3. Looks like nobody filed double free at utrace aka oops at rcuprocesscallbacks() against RHEL5 kernel.

It's bug https://bugzilla.redhat.com/bugzilla/showbug.cgi?id=207002 against FC6, but, hey, every utrace version has it. Test program attached. Every user can trigger it.

OpenOffice.org 1.1.x packages as shipped in Red Hat Enterprise Linux 3 and 4 shipped with certain libraries built with insecure RPATH set in the ELF header. RPATH was incorrectly set to '$ORIGIN' instead of $ORIGIN.

This issue can be exploited by a local user to run arbitrary code as some other user if victim can be convinced to run openoffice in the attacker controlled directory with specially crafted content.

Memory leak in a certain Red Hat deployment of vsftpd before 2.0.5 on Red Hat Enterprise Linux (RHEL) 3 and 4, when PAM is used, allows remote attackers to cause a denial of service (memory consumption) via a large number of invalid authentication attempts within the same session, a different vulnerability than CVE-2007-5962.

Buffer overflow in pattern.c in libxslt before 1.1.24 allows context-dependent attackers to cause a denial of service (crash) and possibly execute arbitrary code via an XSL style sheet file with a long XSLT "transformation match" condition that triggers a large number of steps.

Will Drewry of the Google Security Team reported an issue in OGG Vorbis library, that can cause crash of the application using vorbis library, trigger an infinite loop, or cause an integer overflow leading to possible heap overflow.

Problem is caused by codebooks with codebook.dim == 0.

Integer overflow in residue partition value (aka partvals) evaluation in Xiph.org libvorbis 1.2.0 and earlier allows remote attackers to execute arbitrary code via a crafted OGG file, which triggers a heap overflow.

Description of problem:

The default IPSec ifup script (/etc/sysconfig/network-scripts/ifup-ipsec) initializes the racoon configuration to use aggressive IKE mode, then fallback to main IKE mode if that fails:

... remote $DST { exchangemode aggressive, main; ...

Due to widely known attacks, the aggressive mode should be only used when public key authentication is in use. In practice, most administrators use IPSec with PSK authentication, which combined with aggressive mode leads to aforementioned vulnerability.

See this whitepaper for more information: http://www.netsc.ch/IMG/pdf/TargetingIKEen.pdf

The exchangemode should be changed to "main" only or, for a low-security fallback, to "main, aggressive" (in the opposite order than currently).

Stack-based buffer overflow in the PAMBasicAuthenticator::PAMCallback function in OpenPegasus CIM management server (tog-pegasus), when compiled to use PAM and without PEGASUSUSEPAMSTANDALONEPROC defined, might allow remote attackers to execute arbitrary code via unknown vectors, a different vulnerability than CVE-2007-5360.

During some routine code review last week, Alasdair Kergon spotted a security flaw in the clustered LVM daemon, clvmd. The report from him is as follows:

Clvmd, a privileged process, accepts, acts upon and responds to communications from unprivileged processes.

Background information ======================

clvmd belongs to the lvm2-cluster package and as such is normally used in shared storage clusters, where several machines are using the same disks in parallel. It is run on every machine in such a cluster. The daemon has to be enabled explictly after installing the package: it does not run by default (since RHEL4.5). Systems not running the daemon i.e. most LVM systems, not subscribed to RHN clustering channels, are not vulnerable.

Clvmd has three roles that require root privilege:

(1) Communicate with clvmd processes on other machines;

(2) Hold locks to ensure conflicting commands are not run in parallel;

(3) Make Logical Volumes available for use on the local machine by issuing the appropriate device-mapper ioctls to the kernel.

When a LVM command is issued in a cluster, an instruction is sent to the local clvmd to obtain the necessary locks and to activate or deactivate logical volumes. Any changes to the on-disk LVM metadata are performed by the original LVM process - not by clvmd itself - and then the instance of clvmd on each machine reads the updated metadata independently from disk.

The flaw ========

The problem was caused by an upstream commit made in April 2004. Prior to that, the communication between lvm and clvmd was through a socket in the filesystem, so it was protected by standard file-system security mechanisms. The commit in question changed it to use an abstract socket starting with a NUL byte (see 'man 7 unix') but no attempt was made to secure it by exchanging credentials. Consequently an unprivileged process can instruct clvmd to perform operations that were supposed to be available only to root.

Operations available to an attacker:

(1) Instruct clvmd to suspend the use of any Logical Volume visible to any machine in the cluster with immediate effect.

(2) Instruct clvmd to activate, deactivate or reload any Logical Volume visible to any machine in the cluster. (Deactivation will fail if the Logical Volume is in use.)

(3) Instruct clvmd to die.

(4) Instruct clvmd to restart (versions 2.02.64 and later).

(5) Instruct clvmd to obtain, release or report the state of locks held by the daemon.

(6) Enable/disable clvmd's debugging mode which controls the amount of detail it logs.

(7) Instruct clvmd to create a backup of a Volume Group's metadata on all the other nodes.

(8) Instruct clvmd to report the cluster name.

(9) Instruct clvmd to echo back the command it received.

(10) Instruct clvmd to refresh its internal caches.

Several of these involve performing privileged operations and could impact upon service availability on machines belonging to the cluster.

The fix ======= We are reverting to using a pathname for the socket and relying upon standard filesystem security.

Directory traversal vulnerability in slp.c in the MSN protocol plugin in libpurple in Pidgin 2.6.4 and Adium 1.3.8 allows remote attackers to read arbitrary files via a .. (dot dot) in an application/x-msnmsgrp2p MSN emoticon (aka custom smiley) request, a related issue to CVE-2004-0122. NOTE: it could be argued that this is resultant from a vulnerability in which an emoticon download request is processed even without a preceding text/x-mms-emoticon message that announced availability of the emoticon.

tog-Pegasus has a package hash collision DoS vulnerability

A race condition was found in the way 'mount.cifs' and 'umount.cifs' utilities performed mount / umount of a particular CIFS share to / from specified mount point (/etc/mtab~ lockfile was created before updating the /etc/mtab file and deleted once the operation completed), when these utilies were setuid root enabled. A local attacker could use this flaw to conduct denial of service attacks (failure of subsequent CIFS share umount / mount requests) by sending termination signal to 'mount.cifs' / 'umount.cifs' processes in the moment of existence of a stale (/etc/mtab~) lockfile.

References: [1] https://bugzilla.samba.org/showbug.cgi?id=7179 (upstream bug report) [2] http://git.samba.org/?p=cifs-utils.git;a=commitdiff;h=810f7e4e0f2dbcbee0294d9b371071cb08268200 (upstream patch) [3] http://www.openwall.com/lists/oss-security/2011/09/27/1 (CVE request) [4] http://www.openwall.com/lists/oss-security/2011/09/30/5 (CVE assignment)

Note: This flaw to be exploitable as described above requires the 'mount.cifs' / 'umount.cifs' utilities to be setuid root enabled. These utilities are not setuid root enabled on Red Hat Enterprise Linux and Fedora distributions, and thus these distributions as such are not vulnerable to this flaw.

The DHCPv6 client (dhcp6c) as used in the dhcpv6 project through 2011-07-25 allows remote DHCP servers to execute arbitrary commands via shell metacharacters in a hostname obtained from a DHCP message.

A postinstall script in the dovecot rpm allows local users to read the contents of newly created SSL/TLS key files.