It was discovered that Java Sound provider caching mechanism is insecure. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.
It was discovered that JAXWS incorrectly cached certain data initialized via thread context class loaders. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.
It was discovered that the AWT toolkit did not properly handle the toolkit threads. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.
It was discovered that JAXB incorrectly cached certain data initialized via thread context class loaders. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.
The caching framework in Django before 1.4.11, 1.5.x before 1.5.6, 1.6.x before 1.6.3, and 1.7.x before 1.7 beta 2 reuses a cached CSRF token for all anonymous users, which allows remote attackers to bypass CSRF protections by reading the CSRF cookie for anonymous users.
It was discovered that the activation framework did not properly protect the default command map. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.
It was discovered that FlavorMaps were not properly seperated between different AppContexts. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.
It was discovered that JAXWS incorrectly cached certain data initialized via thread context class loaders. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.
It was discovered that the system logger was not properly protected against using handlers of custom loggers created prior to the system logger. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.
Description of the problem:
A flaw was found in the way Linux kernel processed authenticated COOKIEECHO chunks.
A remote attacker could use this flaw to crash the system by sending a maliciously prepared SCTP handshake in order to trigger a NULL pointer dereference on the server.
Introduced by: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bbd0d59809f9
Acknowledgements:
Red Hat would like to thank Nokia Siemens Networks for reporting this issue.
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.
Multiple buffer overflows in X.Org libXfont before 1.4.8 and 1.4.9x before 1.4.99.901 allow remote font servers to execute arbitrary code via a crafted xfs protocol reply to the (1) fsrecvconnsetup, (2) fsreadopenfont, (3) fsreadqueryinfo, (4) fsreadextentinfo, (5) fsreadglyphs, (6) fsreadlist, or (7) fsreadlistinfo function.
Multiple integer overflows in the (1) fsgetreply, (2) fsallocglyphs, and (3) fsreadextentinfo functions in X.Org libXfont before 1.4.8 and 1.4.9x before 1.4.99.901 allow remote font servers to execute arbitrary code via a crafted xfs reply, which triggers a buffer overflow.
The django.util.http.issafeurl function in Django 1.4 before 1.4.13, 1.5 before 1.5.8, 1.6 before 1.6.5, and 1.7 before 1.7b4 does not properly validate URLs, which allows remote attackers to conduct open redirect attacks via a malformed URL, as demonstrated by "http:\\\djangoproject.com."
Django 1.4 before 1.4.13, 1.5 before 1.5.8, 1.6 before 1.6.5, and 1.7 before 1.7b4 does not properly include the (1) Vary: Cookie or (2) Cache-Control header in responses, which allows remote attackers to obtain sensitive information or poison the cache via a request from certain browsers.
Race condition in PolicyKit (aka polkit) allows local users to bypass intended PolicyKit restrictions and gain privileges by starting a setuid or pkexec process before the authorization check is performed, related to (1) the polkitunixprocessnew API function, (2) the dbus API, or (3) the --process (unix-process) option for authorization to pkcheck.
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.
A denial of service flaw was found in the way the JRE processes XML. A remote attacker could use this flaw to supply crafted XML that would lead to a denial of service.
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
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:
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: 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.
Integer overflow in the drmmodedirtyfbioctl function in drivers/gpu/drm/drmcrtc.c in the Direct Rendering Manager (DRM) subsystem in the Linux kernel before 3.1.5 allows local users to gain privileges or cause a denial of service (memory corruption) via a crafted ioctl call.
Description of problem:
A specially-crafted UDF filesystem could cause buffer overflow when parsing sparing tables in udfloadlogicalvol()@fs/udf/super.c.
The bug is fixed in upstream kernel via the following commits:
commit 1df2ae31c724e57be9d7ac00d78db8a5dabdd050 Author: Jan Kara <jack () suse cz> Date: Wed Jun 27 21:23:07 2012 +0200
udf: Fortify loading of sparing table
Add sanity checks when loading sparing table from disk to avoid accessing unallocated memory or writing to it.
and
commit adee11b2085bee90bd8f4f52123ffb07882d6256 Author: Jan Kara <jack () suse cz> Date: Wed Jun 27 20:20:22 2012 +0200
udf: Avoid run away loop when partition table length is corrupted Check provided length of partition table so that (possibly maliciously) corrupted partition table cannot cause accessing data beyond current buffer.
Upstream fixes: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=1df2ae31c724e57be9d7ac00d78db8a5dabdd050 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=adee11b2085bee90bd8f4f52123ffb07882d6256 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=57b9655d
References: http://seclists.org/oss-sec/2012/q3/2
A peer (or local user) may cause TCP to use a nominal MSS of as little as 88 (actual MSS of 76 with timestamps). Given that we have a sufficiently prodigious local sender and the peer ACKs quickly enough, it is nevertheless possible to grow the window for such a connection to the point that we will try to send just under 64K at once. This results in a single skb that expands to 861 segments.
In some drivers with TSO support, such an skb will require hundreds of DMA descriptors; a substantial fraction of a TX ring or even more than a full ring. The TX queue selected for the skb may stall and trigger the TX watchdog repeatedly (since the problem skb will be retried after the TX reset).
Upstream patch: http://www.spinics.net/lists/netdev/msg206332.html
References: http://seclists.org/oss-sec/2012/q3/171
Acknowledgements:
Red Hat would like to thank Ben Hutchings of Solarflare (tm) for reporting this issue.
Last updated 24 July 2024