An access control vulnerability exists in the Applet Rhino Script Engine component of Oracle's Java Runtime Environment allows an attacker to remotely execute arbitrary code.
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.
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
DistUpgrade/DistUpgradeViewKDE.py in Update Manager before 1:0.87.31.1, 1:0.134.x before 1:0.134.11.1, 1:0.142.x before 1:0.142.23.1, 1:0.150.x before 1:0.150.5.1, and 1:0.152.x before 1:0.152.25.5 does not properly create temporary files, which allows local users to obtain the XAUTHORITY file content for a user via a symlink attack on the temporary file.
DistUpgrade/DistUpgradeFetcherCore.py in Update Manager before 1:0.87.31.1, 1:0.134.x before 1:0.134.11.1, 1:0.142.x before 1:0.142.23.1, 1:0.150.x before 1:0.150.5.1, and 1:0.152.x before 1:0.152.25.5 on Ubuntu 8.04 through 11.10 does not verify the GPG signature before extracting an upgrade tarball, which allows man-in-the-middle attackers to (1) create or overwrite arbitrary files via a directory traversal attack using a crafted tar file, or (2) bypass authentication via a crafted meta-release file.
Untrusted search path vulnerability in pammotd (aka the MOTD module) in libpam-modules before 1.1.3-2ubuntu2.1 on Ubuntu 11.10, before 1.1.2-2ubuntu8.4 on Ubuntu 11.04, before 1.1.1-4ubuntu2.4 on Ubuntu 10.10, before 1.1.1-2ubuntu5.4 on Ubuntu 10.04 LTS, and before 0.99.7.1-5ubuntu6.5 on Ubuntu 8.04 LTS, when using certain configurations such as "session optional pammotd.so", allows local users to gain privileges by modifying the PATH environment variable to reference a malicious command, as demonstrated via uname.
gdm/guest-session-cleanup.sh in gdm-guest-session 0.24 and earlier, as used in Ubuntu Linux 10.04 LTS, 10.10, and 11.04, allows local users to delete arbitrary files via a space in the name of a file in /tmp. NOTE: this identifier was SPLIT from CVE-2012-0943 per ADT1/ADT2 due to different codebases and affected versions. CVE-2012-0943 is used for the guest-account issue.
ppa.py in Software Properties before 0.81.13.3 does not validate the server certificate when downloading PPA GPG key fingerprints, which allows man-in-the-middle (MITM) attackers to spoof GPG keys for a package repository.
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.
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."
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.
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.
Description of problem: Reported by Taviso Ormandy via the Ubuntu Security Team.
$ gcc keyctl.c -o keyctl -lkeyutils $ ./keyctl [ 213.999221] BUG: unable to handle kernel NULL pointer dereference at 00000034 [ 214.002770] IP: [<c02f0f2a>] keyctlsessiontoparent+0x12a/0x1c0 [ 214.006011] pde = 0fdb0067 pte = 00000000 [ 214.008007] Oops: 0000 [#1] SMP [ 214.008973] last sysfs file: /sys/module/ppdev/initstate [ 214.010466] Modules linked in: binfmtmisc vmblock vsock vmmemctl vmhgfs acpiphp sndens1371 gameport sndac97codec ac97bus sndpcmoss sndmixeross sndpcm sndseqdummy sndseqoss sndseqmidi sndrawmidi sndseqmidievent sndseq sndtimer sndseqdevice ppdev fbcon tileblit font bitblit softcursor snd psmouse serioraw parportpc soundcore sndpagealloc vmci shpchp i2cpiix4 vga16fb vgastate intelagp agpgart lp parport mptspi mptscsih mptbase floppy scsitransportspi vmxnet [ 214.024416] [ 214.024899] Pid: 1772, comm: a.out Not tainted (2.6.32-24-generic #41-Ubuntu) VMware Virtual Platform [ 214.027413] EIP: 0060:[<c02f0f2a>] EFLAGS: 00210046 CPU: 0 [ 214.028927] EIP is at keyctlsessiontoparent+0x12a/0x1c0 [ 214.030419] EAX: d2cde100 EBX: d2cdeb00 ECX: 000003e8 EDX: cfcfc480 [ 214.032132] ESI: cfddb300 EDI: 00000000 EBP: d2c33f94 ESP: d2c33f7c [ 214.033811] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 214.035292] Process a.out (pid: 1772, ti=d2c32000 task=d79bbfc0 task.ti=d2c32000) [ 214.037346] Stack: [ 214.037926] 00000000 000003e8 d2cde700 004370c0 00000012 08048520 d2c33fac c02f22e5 [ 214.040262] <0> 00000004 00000012 00327ff4 08048520 d2c32000 c01033ec 00000012 004370c0 [ 214.042795] <0> 0804852b 00327ff4 08048520 00000001 00000120 0000007b 0000007b 00000000 [ 214.045405] Call Trace: [ 214.046108] [<c02f22e5>] ? syskeyctl+0x65/0x170 [ 214.047434] [<c01033ec>] ? syscallcall+0x7/0xb [ 214.048711] Code: 90 0f 85 77 ff ff ff 8b 7a 08 89 7d ec 3b 78 18 0f 85 68 ff ff ff 3b 7a 18 0f 85 5f ff ff ff 3b 7a 10 0f 85 56 ff ff ff 8b 7d e8 <3b> 4f 34 8d 76 00 0f 85 47 ff ff ff 8b 7d f0 3b 4f 34 0f 85 3b [ 214.056401] EIP: [<c02f0f2a>] keyctlsessiontoparent+0x12a/0x1c0 SS:ESP 0068:d2c33f7c [ 214.058676] CR2: 0000000000000034 [ 214.059605] ---[ end trace cc41d96061101854 ]---
Description of problem: This problem was originally tracked down by Brad Spengler.
When calling wireless ioctls, if a driver does not correctly validate/shrink iwp->length, the resulting copytouser can leak up to 64K of kernel heap contents.
It seems that this is triggerable[1] in 2.6.32 at least on ath5k, but I was not able to track down how. The twisty maze of ioctl handlers stumped me. :) Other drivers I checked did not appear to have any problems, but the potential remains. I'm not sure if this patch is the right approach; it was fixed differently[2] in grsecurity.
[1] http://forums.grsecurity.net/viewtopic.php?f=3&t=2290&start=0 [2] http://grsecurity.net/~spender/wireless-infoleak-fix2.patch
Discussion: http://lkml.org/lkml/2010/8/27/413
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:
When parsing a peer's supported HMAC authentication options in the sctpauthasocgethmac() function, a malicious peer can craft their HMAC array in such a way as to cause memory corruption (out-of-bounds read followed by use of retrieved out-of-bounds data), which at the very least could cause a denial of service via kernel panic, and possibly worse. It appears this could be triggered remotely when connecting to a malicious peer, or locally by a user acting as both endpoints. In both cases, the "authenable" sysctl must be set in order to trigger the bug.
References: http://marc.info/?l=oss-security&m=128619854321910&w=1 http://marc.info/?l=linux-kernel&m=128596992418814&w=2
Description of problem: The PKTCTRLCMDSTATUS device ioctl retrieves a pointer to a pktcdvddevice from the global pktdevs array. The index into this array is provided directly by the user and is a signed integer, so the comparison to ensure that it falls within the bounds of this array will fail when provided with a negative index.
This can be used to read arbitrary kernel memory or cause a crash due to an invalid pointer dereference. This can be exploited by users with permission to open /dev/pktcdvd/control (on many distributions, this is readable by group "cdrom").
Upstream commit: http://git.kernel.org/linus/252a52aa4fa22a668f019e55b3aac3ff71ec1c29
Description of problem: The sndctlnew() function in sound/core/control.c allocates space for a sndkcontrol struct by performing arithmetic operations on a user-provided size without checking for integer overflow. If a user provides a large enough size, an overflow will occur, the allocated chunk will be too small, and a second user-influenced value will be written repeatedly past the bounds of this chunk. This code is reachable by unprivileged users who have permission to open a /dev/snd/controlC device (on many distros, this is group "audio") via the SNDRVCTLIOCTLELEMADD and SNDRVCTLIOCTLELEMREPLACE ioctls.
Upstream commit: http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=commitdiff;h=5591bf07225523600450edd9e6ad258bb877b779
Acknowledgements:
Red Hat would like to thank Dan Rosenberg for reporting this issue.
Last updated 24 July 2024
Description of problem: sctppacketconfig() is called when getting the packet ready for appending of chunks. The function should not touch the current state, since it's possible to ping-pong between two transports when sending, and that can result packet corruption followed by skb overlfow crash.
Upstream commit: http://git.kernel.org/linus/4bdab43323b459900578b200a4b8cf9713ac8fab
Reference: http://marc.info/?l=linux-netdev&m=128453869227715&w=3 http://www.spinics.net/lists/linux-sctp/msg01051.html
Essentially, we are resetting the contents of the packet when it's not empty.
Description of problem: The problem was in the way the gfs2 directory code was trying to re-use sentinel directory entries.
In the failing case, gfs2's rename function was renaming a file to another name that had the same non-trivial length. The file being renamed happened to be the first directory entry on the leaf block.
First, the rename code (gfs2rename in opsinode.c) found the original directory entry and decided it could do its job by simply replacing the directory entry with another. Therefore it determined correctly that no block allocations were needed.
Next, the rename code deleted the old directory entry prior to replacing it with the new name. Therefore, the soon-to-be replaced directory entry was temporarily made into a directory entry "sentinel" or a place holder at the start of a leaf block.
Lastly, it went to re-add the replacement directory entry in that leaf block. However, when gfs2direntfindspace was looking for space in the leaf block, it used the wrong value for the sentinel. That threw off its calculations so later it decides it can't really re-use the sentinel and therefore must allocate a new leaf block. But because it previously decided to re-use the directory entry, it didn't waste the time to grab a new block allocation for the inode. Therefore, the inode's ialloc pointer was still NULL and it crashes trying to reference it.
In the case of sentinel directory entries, the entire dirent is reused, not just the "free space" portion of it, and therefore the function gfs2direntfindspace should use the value 0 rather than GFS2DIRENTSIZE(0) for the actual dirent size.
Fixing this calculation enables the reproducer programs to work properly.
Juliano Rizzo announced: [1] http://www.ekoparty.org/2011/juliano-rizzo.php
that at ekoparty Security Conference, from 2011-09-21 to 2011-09-23 they will present a new fast block-wise chosen-plaintext attack against SSL/TLS. One application of the attack should allow the adversary to efficiently decrypt and obtain authentication tokens and cookies from HTTPS requests.
The Red Hat Security Response Team is watching progress on this one and once further details are available, we will immediately react to ensure timely manner updates for affected packages.
Description of problem: It requires debugfs to be mounted on a local system
$ mount | grep debugfs none on /sys/kernel/debug type debugfs (rw) none on /var/lib/ureadahead/debugfs type debugfs (rw,relatime)
Tested with Ubuntu Maverick 10.04.1 with kernel 2.6.32-24-generic-pae. It's probably not exploitable in any meaningful way, although it produces page fault in kernel mode, and makes subsequent processes opening /sys/kernel/debug/tracing/setftracefilter (or setftracenotrace) unkillable, so it's a little bit of a DoS (or at least, annoyance).
Found via one of Tavis Ormandy's tools, I just quickly analyzed it and provided a testcase.
Acknowledgements:
Red Hat would like to thank Robert Swiecki of Google Security Team for reporting this issue.