Heap-based buffer overflow in the stringvformat function in string.c in Exim before 4.70 allows remote attackers to execute arbitrary code via an SMTP session that includes two MAIL commands in conjunction with a large message containing crafted headers, leading to improper rejection logging.
Exim 4.72 and earlier allows local users to gain privileges by leveraging the ability of the exim user account to specify an alternate configuration file with a directive that contains arbitrary commands, as demonstrated by the spooldirectory directive.
Description of problem: The handling functions for sending and receiving messages, in rdspagecopyuser(), use the unchecked copyuserinatomic functions without any access checks on user-provided pointers. As a result, by passing a kernel address as an iovec base address in recvmsg-style calls, a local user can overwrite arbitrary kernel memory, which can easily be used to escalate privileges to root.
Introduced via 7875e18e (v2.6.30-rc1).
Acknowledgements:
Red Hat would like to thank Dan Rosenberg of Virtual Security Research for reporting this issue.
Unspecified vulnerability in the Java Runtime Environment (JRE) in Java SE component allows remote attackers to affect confidentiality, integrity, and availability via Unknown vectors.
Marsh Ray of PhoneFactor has discovered a flaw in the TLS/SSL protocol related to the handling of the session rehandshakes / renegotiations. This flaw can possibly be used in the MITM attacks and allowing an attacker to inject attacker-chosen plain text prefix to the session of the victim.
Further details are available in the "Authentication Gap in TLS Renegotiation" blog post: http://extendedsubset.com/?p=8
Multiple directory traversal vulnerabilities in Lintian 1.23.x through 1.23.28, 1.24.x through 1.24.2.1, and 2.x before 2.3.2 allow remote attackers to overwrite arbitrary files or obtain sensitive information via vectors involving (1) control field names, (2) control field values, and (3) control files of patch systems.
Heap-based buffer overflow in the GIFLZWDecompressor::GIFLZWDecompressor function in filter.vcl/lgif/decode.cxx in OpenOffice.org (OOo) before 3.2 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via a crafted GIF file, related to LZW decompression.
Integer overflow in the XPMReader::ReadXPM function in filter.vcl/ixpm/svtxpmread.cxx in OpenOffice.org (OOo) before 3.2 allows remote attackers to execute arbitrary code via a crafted XPM file that triggers a heap-based buffer overflow.
The futexlockpi function in kernel/futex.c in the Linux kernel before 2.6.33-rc7 does not properly manage a certain reference count, which allows local users to cause a denial of service (OOPS) via vectors involving an unmount of an ext3 filesystem.
Use-after-free vulnerability in WebKit in Apple Safari before 4.0.5 allows remote attackers to execute arbitrary code or cause a denial of service (application crash) via an HTML document with improperly nested tags.
Marc Schoenefeld found a flaw in the way OpenOffice.org 3.2.0 and earlier, enforced non-executable permission, when browsing macros, written in Python scripting language. If a local user was tricked into opening a specially-crafted OpenDocument Text (ODT) file, containing macros, and previewed the macro directories structure, it could lead to Python macro execution even when macros execution was disabled.
WebKit in Apple Safari before 5.0 on Mac OS X 10.5 through 10.6 and Windows, Apple Safari before 4.1 on Mac OS X 10.4, and Google Chrome before 5.0.375.70 does not properly handle a transformation of a text node that has the IBM1147 character set, which allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted HTML document containing a BR element, related to a "type checking issue."
The pngdecompresschunk function in pngrutil.c in libpng 1.0.x before 1.0.53, 1.2.x before 1.2.43, and 1.4.x before 1.4.1 does not properly handle compressed ancillary-chunk data that has a disproportionately large uncompressed representation, which allows remote attackers to cause a denial of service (memory and CPU consumption, and application hang) via a crafted PNG file, as demonstrated by use of the deflate compression method on data composed of many occurrences of the same character, related to a "decompression bomb" attack.
Description of problem: A problem was found in the drivers/connector/connector.c code where users could send/allocate arbitrary amounts of NETLINKCONNECTOR messages to the kernel, causing OOM condition, killing selected processes or halting the system.
This is fixed in mainline commit f98bfbd78c37c5946cc53089da32a5f741efdeb7 by removing the code.
commit f98bfbd78c37c5946cc53089da32a5f741efdeb7 Author: Evgeniy Polyakov <zbr> Date: Tue Feb 2 15:58:48 2010 -0800
connector: Delete buggy notification code.
On Tue, Feb 02, 2010 at 02:57:14PM -0800, Greg KH (gregkh) wrote: > > There are at least two ways to fix it: using a big cannon and a small > > one. The former way is to disable notification registration, since it is > > not used by anyone at all. Second way is to check whether calling > > process is root and its destination group is -1 (kind of priveledged > > one) before command is dispatched to workqueue. > > Well if no one is using it, removing it makes the most sense, right? > > No objection from me, care to make up a patch either way for this?
Getting it is not used, let's drop support for notifications about (un)registered events from connector. Another option was to check credentials on receiving, but we can always restore it without bugs if needed, but genetlink has a wider code base and none complained, that userspace can not get notification when some other clients were (un)registered.
Kudos for Sebastian Krahmer <krahmer>, who found a bug in the code.
Signed-off-by: Evgeniy Polyakov <zbr> Acked-by: Greg Kroah-Hartman <gregkh> Signed-off-by: David S. Miller <davem>
Acknowledgements:
Red Hat would like to thank Sebastian Krahmer for reporting this issue.
Pierre Noguès found a NULL pointer dereference in the Pidgin MSN SLP protocol implementation, by processing custom emoticon messages. A remote, authenticated user could use this deficiency to cause a denial of service (Pidgin crash).
Acknowledgements:
Red Hat would like to thank the Pidgin project for reporting this issue. Upstream acknowledges Pierre Noguès of Meta Security as the original reporter.
The kgacceptkrb5 function in krb5/acceptseccontext.c in the GSS-API library in MIT Kerberos 5 (aka krb5) through 1.7.1 and 1.8 before 1.8.2, as used in kadmind and other applications, does not properly check for invalid GSS-API tokens, which allows remote authenticated users to cause a denial of service (NULL pointer dereference and daemon crash) via an AP-REQ message in which the authenticator's checksum field is missing.
Description of problem: The problem seams to be located in fs/binfmtelf.c:loadelfbinary(). It calls SETPERSONALITY() prior checking that the ELF interpreter is available. This in turn makes the previously 32 bit process a 64 bit one which would be fine if execve() would succeed. But after the SETPERSONALITY() the openexec() call fails (because it cannot find the interpreter) and execve() almost instantly returns with an error. If you now look at /proc/PID/maps you'll see, that it has the vsyscall page mapped which shouldn't be. But the process is not dead yet, it's still running. By now generating a segmentation fault and in turn trying to generate a core dump the kernel just dies.
Steps to Reproduce: 1. Enable core dumps 2. Start an 32 bit program that tries to execve() an 64 bit program 3. The 64 bit program cannot be started by the kernel because it can't find the interpreter, i.e. execve returns with an error 4. Generate a segmentation fault 5. panic
(EDIT: This is triggerable on 2.6.31.9-174.fc12.x8664).
Upstream commit: http://git.kernel.org/linus/221af7f87b97431e3ee21ce4b0e77d5411cf1549
Discussions: http://marc.info/?t=126466700200002&r=1&w=2
Acknowledgements:
Red Hat would like to thank Mathias Krause for reporting this issue.
Description of problem: CVE-2009-3553 (bug #530111) has not been completely fixed.
Version-Release number of selected component (if applicable): Versions known to be affected:
cups-1.3.7-11.el54.5 (RHEL-5.4.z) cups-1.3.7-16.el5 (RHEL-5)
Additional info: The cause is that the cupsdDoSelect() function uses one of several implementations depending on the underlying select/poll capabilities of the operating system. For kqueue and epoll implementations, cupsdRemoveSelect() does not immediately decrease the reference count for the file descriptor and instead adds it to the cupsdinactivefds array. File descriptors in that array are finally dereferenced in cupsdStopSelect() (i.e. program termination).
In Red Hat Enterprise Linux, the epoll implementation is used.
The previous fix for CVE-2009-3553 was to check that another reference was held for the file descriptor before calling the writecb function; however, that will always be the case for both the epoll and kqueue implementations.
The correct fix is to check whether the file descriptor is in the cupsdinactivefds array before calling the writecb function.
The browser engine in Mozilla Firefox 3.0.x before 3.0.18 and 3.5.x before 3.5.8, Thunderbird before 3.0.2, and SeaMonkey before 2.0.3 allows remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via vectors related to the nsBlockFrame::StealFrame function in layout/generic/nsBlockFrame.cpp, and unspecified other vectors.
OpenOffice.org (OOo) 2.0.4, 2.4.1, and 3.1.1 does not properly enforce Visual Basic for Applications (VBA) macro security settings, which allows remote attackers to run arbitrary macros via a crafted document.
An integer underflow flaw, possibly leading to a heap-based buffer overflow, was found in the way OpenOffice.org parsed certain records in Microsoft Word documents. An attacker could create a specially-crafted Microsoft Word document, which once opened by a local, unsuspecting user, could cause OpenOffice.org to crash or, potentially, execute arbitrary code with the permissions of the user running OpenOffice.org.
Credit: Nicolas Joly of VUPEN Vulnerability Research Team
A boundary error flaw, possibly leading to a heap-based buffer overflow, was found in the way OpenOffice.org parsed certain records in Microsoft Word documents. An attacker could create a specially-crafted Microsoft Word document, which once opened by a local, unsuspecting user, could cause OpenOffice.org to crash or, potentially, execute arbitrary code with the permissions of the user running OpenOffice.org.
Credit: Nicolas Joly of VUPEN Vulnerability Research Team
XMLScanner.java in Apache Xerces2 Java, as used in Sun Java Runtime Environment (JRE) in JDK and JRE 6 before Update 15 and JDK and JRE 5.0 before Update 20, and in other products, allows remote attackers to cause a denial of service (infinite loop and application hang) via malformed XML input, as demonstrated by the Codenomicon XML fuzzing framework.
Description of problem: The XFSIOCFSGETXATTR ioctl allows unprivileged users to read 12 bytes of uninitialized stack memory, because the fsxattr struct declared on the stack in xfsiocfsgetxattr() does not alter (or zero) the 12-byte fsxpad member before copying it back to the user.
http://www.linux.sgi.com/archives/xfs-masters/2010-09/msg00002.html
Acknowledgements:
Red Hat would like to thank Dan Rosenberg for reporting this issue.
Description of problem: There is a bug in sndseqossopen from sound/core/seq/oss/seqossinit.c. So here's the error path for some setup failure:
error: sndseqosswriteqdelete(dp->writeq); sndseqossreadqdelete(dp->readq); sndseqosssynthcleanup(dp); sndseqossmidicleanup(dp); deleteport(dp); deleteseqqueue(dp->queue); kfree(dp);
This looks okay, but actually, deleteport calls portdelete (eventually... this code is tough to follow) which does a freedevinfo on the owner struct seqossdevinfo, here (around ~269 in seqports.c):
if (port->privatefree) port->privatefree(port->privatedata);
because of this (around ~334 in seqossinit.c):
memset(&callback, 0, sizeof(callback)); callback.owner = THISMODULE; callback.privatedata = dp; callback.eventinput = sndseqosseventinput; callback.privatefree = freedevinfo; port.kernel = &callback;
Which does this:
static void freedevinfo(void private) { struct seqossdevinfo dp = (struct seqossdevinfo )private;
if (dp->timer) sndseqosstimerdelete(dp->timer); if (dp->writeq) sndseqosswriteqdelete(dp->writeq);
if (dp->readq) sndseqossreadqdelete(dp->readq); kfree(dp); }
So.....
deleteport(dp); deleteseqqueue(dp->queue); <= Oops, dereferencing released pointer. kfree(dp); <= Oops, double free.
Acknowledgements:
Red Hat would like to thank Tavis Ormandy for reporting this issue.
Buffer overflow in the niugetethtooltcamall function in drivers/net/niu.c in the Linux kernel before 2.6.36-rc4 allows local users to cause a denial of service or possibly have unspecified other impact via the ETHTOOLGRXCLSRLALL ethtool command.
Description of problem: This series closes a recently discovered problem in XFS filehandle conversion. On systems where inodes are dynamically deleted, XFS does not adequately verify the inode numbers in the filehandles, which results in reading stale inodes from disk and potentially returning them as valid files. Because these unlinked inodes were never zeroed out when the chunk was deallocated, some inodes in the chunk can still appear to have to data extents attached to them. This can lead to stale data exposure, exposure of active data and potentially overwriting of active data if the stale extents referenced in the unlinked inodes have been re-allocated.
Both NFS filehandles and local filehandles provided through libhandle have this same problem. libhandle requires root permissions to use the interface, so it is not exposing information that you can't get more easily with other means (e.g. xfsdb or reading directly form the block device), so there isn't really an issue here.
For NFS, we may incorrectly accept stale file handles for unlinked inodes after a server reboot if the unlinked inodes have not been overwritten leading to the above issues being triggered if multiple NFS clients are accessing the same files.
Christoph's make-bulkstat-coherent patch is the basis for this series as bulkstat can also expose unlinked inodes and information about them back to userspace as it makes the same assumptions about inode lookups as the file handle interfaces.
As a result, the first two patches of the series make up the real bug fix. The last two patches make it clear we are lookuping up untrusted inode numbers and clear away a shortcut that these interfaces used that we do not want used any more. Hence for backports to other kernels, only the first two patches are necessary.
The test program that demonstrates the issue via the openbyhandle interface can be found here:
http://oss.sgi.com/archives/xfs/2010-06/msg00191.html
Version 2: - removed useless ip->iimap.imblkno initialisation in xfsiread() - reworked a comment refering to bulkstat when it should refer to untrusted inodes. - removed typedefs from xfsimaplookup() - killed useless error logging from xfsimaplookup() - rearranged the logic flow of xfsimaplookup() to remove the gotos.
[PATCH 0/4, V2] xfs: validate inode numbers in file handles correctly http://article.gmane.org/gmane.comp.file-systems.xfs.general/33767
[PATCH 1/4] xfs: always use iget in bulkstat http://article.gmane.org/gmane.comp.file-systems.xfs.general/33770
[PATCH 2/4] xfs: validate untrusted inode numbers during lookup http://article.gmane.org/gmane.comp.file-systems.xfs.general/33771
[PATCH 3/4] xfs: rename XFSIGETBULKSTAT to XFSIGETUNTRUSTED http://article.gmane.org/gmane.comp.file-systems.xfs.general/33768
[PATCH 4/4] xfs: remove block number from inode lookup code http://article.gmane.org/gmane.comp.file-systems.xfs.general/33769
[PATCH] xfsqa: test openbyhandle() on unlinked and freed inode cluster http://oss.sgi.com/archives/xfs/2010-06/msg00191.html
fs/jfs/xattr.c in the Linux kernel before 2.6.35.2 does not properly handle a certain legacy format for storage of extended attributes, which might allow local users by bypass intended xattr namespace restrictions via an "os2." substring at the beginning of a name.
Description of problem: BUG: unable to handle kernel NULL pointer dereference at 00000004 IP: [<f7f06dca>] hashbindelete+0x14/0xad [irda] pdpt = 0000000000a57001 pde = 0000000000000000 Oops: 0000 [#1] SMP last sysfs file: /sys/devices/virtual/dmi/id/sysvendor Modules linked in: irda crcccitt fuse ip6tREJECT nfconntrackipv6 ip6tablefilter ip6tables ipv6 vmblock vsock vmmemctl vmhgfs uinput pcnet32 ppdev vmxnet microcode parportpc parport mii vmci i2cpiix4 i2ccore mptspi mptscsih mptbase scsitransportspi [last unloaded: scsiwaitscan]
Pid: 2403, comm: a.out Not tainted 2.6.33.6-147.2.4.fc13.i686.PAE #1 440BX Desktop Reference Platform/VMware Virtual Platform EIP: 0060:[<f7f06dca>] EFLAGS: 00010282 CPU: 0 EIP is at hashbindelete+0x14/0xad [irda] EAX: 00000000 EBX: 00000000 ECX: f2f97f4c EDX: f7f084aa ESI: df1b8800 EDI: f7f084aa EBP: eb19bd78 ESP: eb19bd64 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process a.out (pid: 2403, ti=eb19a000 task=f2ed9980 task.ti=eb19a000) Stack: 00000000 00000202 eb0df2c0 df1b8800 df1a6770 eb19bd84 f7f085f5 eb0df2c0 <0> eb19bd90 f7f0861f eb20c400 eb19bda4 f7f0a958 df1b8800 f7f0ebe4 df1a6770 <0> eb19bdb4 c06ef16e f2e21100 00000008 eb19bdbc c06ef1cf eb19bde0 c04d183a Call Trace: [<f7f085f5>] ? iriasdeleteobject+0x1b/0x2c [irda] [<f7f0861f>] ? iriasdeleteobject+0x19/0x1e [irda] [<f7f0a958>] ? irdarelease+0x65/0x127 [irda] [<c06ef16e>] ? sockrelease+0x14/0x59 [<c06ef1cf>] ? sockclose+0x1c/0x20 [<c04d183a>] ? fput+0xea/0x181 [<c04d18e4>] ? fput+0x13/0x15 [<c04cef5f>] ? filpclose+0x51/0x5b [<c043f260>] ? putfilesstruct+0x5f/0xb3 [<c043f2e8>] ? exitfiles+0x34/0x38 [<c0440a1b>] ? doexit+0x200/0x615 [<c044c4c0>] ? dequeuesignal+0xb1/0x120 [<c0440e9b>] ? dogroupexit+0x6b/0x94 [<c044c89d>] ? getsignaltodeliver+0x36e/0x389 [<c0407cd4>] ? dosignal+0x5a/0x6f4 [<c078359d>] ? apictimerinterrupt+0x31/0x38 [<c0455f57>] ? hrtimernanosleep+0x94/0xdc [<c04d7376>] ? pathput+0x15/0x18 [<c047c6a6>] ? auditsyscallexit+0xfa/0x10f [<c040838d>] ? donotifyresume+0x1f/0x79 [<c07831e4>] ? worknotifysig+0x13/0x1b Code: 04 01 74 0b 8b 55 f0 8d 43 0c e8 b8 bf 87 c8 83 c4 0c 5b 5e 5f 5d c3 55 89 e5 57 89 d7 56 53 89 c3 83 ec 08 c7 45 ec 00 00 00 00 <f6> 40 04 01 74 0b 8d 40 0c e8 40 bf 87 c8 89 45 ec 89 de c7 45 EIP: [<f7f06dca>] hashbindelete+0x14/0xad [irda] SS:ESP 0068:eb19bd64 CR2: 0000000000000004 ---[ end trace 8c5fb89ec896b3a8 ]--- Fixing recursive fault but reboot is needed!
Acknowledgements:
Red Hat would like to thank Tavis Ormandy for reporting this issue.
drivers/media/video/v4l2-compat-ioctl32.c in the Video4Linux (V4L) implementation in the Linux kernel before 2.6.36 on 64-bit platforms does not validate the destination of a memory copy operation, which allows local users to write to arbitrary kernel memory locations, and consequently gain privileges, via a VIDIOCSTUNER ioctl call on a /dev/video device, followed by a VIDIOCSMICROCODE ioctl call on this device.