TYPO3 before 4.4.1 allows XSS in the frontend search box.

A flaw was found in the default error response for status code 400. This could be used by an attacker to expose "httpOnly" cookies, when no custom ErrorDocument was specified.

This affects all versions of Apache from 2.2.0 up to and including 2.2.21. It will be fixed upstream in 2.2.22 (via r1235454 [1]).

[1] http://svn.apache.org/viewvc?view=revision&revision=1235454

Apache 2.2 fixed a possible crash on shutdown if a child changes the sbtype field in the scoreboard. Since unprivileged children should not be able to affect the parent in this way, this is treated as a Low severity security issue [1].

The reporter has a nice writeup of the flaw as well [2].

[1] http://svn.apache.org/viewvc?view=revision&revision=1230065 [2] http://www.halfdog.net/Security/2011/ApacheScoreboardInvalidFreeOnShutdown/

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.

OpenSSL before 0.9.8q, and 1.0.x before 1.0.0c, when SSLOPNETSCAPEREUSECIPHERCHANGEBUG is enabled, does not properly prevent modification of the ciphersuite in the session cache, which allows remote attackers to force the downgrade to an unintended cipher via vectors involving sniffing network traffic to discover a session identifier.

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.

Dmitri Gribenko discovered that the soffice script in the Openoffice.org package contained an insecure setting for the LDLIBRARYPATH, which could be abused by an attacker to execute arbitrary code.

The vulnerability is due to an insecure change to LDLIBRARYPATH, and environment variable used by ld.so(8) to look for libraries in directories other than the standard paths. When there is an empty item in the colon-separated list of directories in LDLIBRARYPATH, ld.so(8) treats it as a '.' (current working directory). If the given script is executed from a directory where a local attacker could write files, there is a chance for exploitation.

Currently in our soffice script we do...

LDLIBRARYPATH=$mypath${LDLIBRARYPATH+:$LDLIBRARYPATH}

while we should do...

LDLIBRARYPATH=$mypath${LDLIBRARYPATH:+:$LDLIBRARYPATH}

so if someone currently does export LDLIBRARYPATH= then our LDLIBRARYPATH ends up as LDLIBRARYPATH=/path: which has an empty entry which effectively means LDLIBRARYPATH=/path:.

Acknowledgements:

Red Hat would like to thank Dmitri Gribenko for reporting this issue.

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.

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: This doesn't look correct, the iosubmit systemcall calls doiosubmit() directly:

SYSCALLDEFINE3(iosubmit, aiocontextt, ctxid, long, nr, struct iocb user user , iocbpp) { return doiosubmit(ctxid, nr, iocbpp, 0); }

doiosubmit only checks if nr < 0, but doesnt check if the accessok multiplication will overflow.

long doiosubmit(aiocontextt ctxid, long nr, struct iocb user user iocbpp, bool compat) { ... if (unlikely(!accessok(VERIFYREAD, iocbpp, (nrsizeof(iocbpp))))) return -EFAULT; ...

Then it uses this loop with getusernocheck(), which doesn't look safe.

... for (i=0; i<nr; i++) { struct iocb user useriocb; struct iocb tmp;

if (unlikely(getuser(useriocb, iocbpp + i))) { ret = -EFAULT; break; } ...

Acknowledgements:

Red Hat would like to thank Tavis Ormandy for reporting this issue.

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: tipc: Fix oops on send prior to entering networked mode (v3)

Fix TIPC to disallow sending to remote addresses prior to entering NETMODE

user programs can oops the kernel by sending datagrams via AFTIPC prior to entering networked mode. The following backtrace has been observed:

ID: 13459 TASK: ffff810014640040 CPU: 0 COMMAND: "tipc-client" [exception RIP: tipcnodeselectnexthop+90] RIP: ffffffff8869d3c3 RSP: ffff81002d9a5ab8 RFLAGS: 00010202 RAX: 0000000000000001 RBX: 0000000000000001 RCX: 0000000000000001 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000001001001 RBP: 0000000001001001 R8: 0074736575716552 R9: 0000000000000000 R10: ffff81003fbd0680 R11: 00000000000000c8 R12: 0000000000000008 R13: 0000000000000001 R14: 0000000000000001 R15: ffff810015c6ca00 ORIGRAX: ffffffffffffffff CS: 0010 SS: 0018 RIP: 0000003cbd8d49a3 RSP: 00007fffc84e0be8 RFLAGS: 00010206 RAX: 000000000000002c RBX: ffffffff8005d116 RCX: 0000000000000000 RDX: 0000000000000008 RSI: 00007fffc84e0c00 RDI: 0000000000000003 RBP: 0000000000000000 R8: 00007fffc84e0c10 R9: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fffc84e0d10 R14: 0000000000000000 R15: 00007fffc84e0c30 ORIGRAX: 000000000000002c CS: 0033 SS: 002b

What happens is that, when the tipc module in inserted it enters a standalone node mode in which communication to its own address is allowed <0.0.0> but not to other addresses, since the appropriate data structures have not been allocated yet (specifically the tipcnet pointer). There is nothing stopping a client from trying to send such a message however, and if that happens, we attempt to dereference tipcnet.zones while the pointer is still NULL, and explode. The fix is pretty straightforward. Since these oopses all arise from the dereference of global pointers prior to their assignment to allocated values, and since these allocations are small (about 2k total), lets convert these pointers to static arrays of the appropriate size. All the accesses to these bits consider 0/NULL to be a non match when searching, so all the lookups still work properly, and there is no longer a chance of a bad dererence anywhere. As a bonus, this lets us eliminate the setup/teardown routines for those pointers, and elimnates the need to preform any locking around them to prevent access while their being allocated/freed.

http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=d0021b252eaf65ca07ed14f0d66425dd9ccab9a6

Reported internally.

static int gfslock(struct file file, int cmd, struct filelock fl) { .. if ((ip->idi.dimode & (SISGID | SIXGRP)) == SISGID) return -ENOLCK; .. }

This is a check for mandatory locking where the GFS locking code will skip the lock in case sgid bits are set for the file.

This is similar to bz 218777 which affected RHEL 4 NFS shares on the client. The reproducer from https://bugzilla.redhat.com/showbug.cgi?id=218777#c1 (private) can be used to crash a system mounting a GFS filesystem.

I was able to reproduce this on 2.6.18-164.11.1 with kmod-gfs-0.1.34-2.el5

----------- [cut here ] --------- [please bite here ] --------- Kernel BUG at fs/locks.c:2080 invalid opcode: 0000 [1] SMP last sysfs file: /kernel/dlm/gfs-sachin/id CPU 0 Modules linked in: gfs(U) lockdlm gfs2 dlm configfs netloop netbk blktap blkbk iptMASQUERADE iptablenat ipnat xtstate ipconntrack nfnetlink iptREJECT xttcpudp iptablefilter iptables xtables bridge autofs4 hidp rfcomm l2cap bluetooth lockd sunrpc iscsitcp bnx2i cnic uio cxgb3i cxgb3 8021q libiscsitcp ibiser libiscsi2 scsitransportiscsi2 scsitransportiscsi ibsrp rds ibsdp ibipoib ipoibhelper ipv6 xfrmnalgo cryptoapi rdmaucm rdmacm ibucm ibuverbs ibumad ibcm iwcm ibaddr ibsa ibmad ibcore loop dmemc dmroundrobin dmmultipath scsidh video hwmon backlight sbs i2cec i2ccore button battery asusacpi ac parportpc lp parport srmod sg joydev pcspkr i5000edac edacmc qla2xxx bnx2 atapiix libata scsitransportfc serialcore serioraw idecd cdrom dmraid45 dmmessage dmregionhash dmmemcache dmsnapshot dmzero dmmirror dmlog dmmod usbstorage shpchp mptsas mptscsih mptbase scsitransportsas sdmod scsimod ext3 jbd uhcihcd ohcihcd ehcihc

Pid: 12585, comm: crash Tainted: G 2.6.18-164.11.1.HOTFIX.el5xen #1 RIP: e030:[<ffffffff80227976>] [<ffffffff80227976>] locksremoveflock+0xe4/0x124 RSP: e02b:ffff88003ff5de28 EFLAGS: 00010246 RAX: ffff88005275b3f8 RBX: ffff88003fb405b0 RCX: 7fffffffffffffff RDX: 0000000000000000 RSI: 0000000000000007 RDI: ffffffff8052d800 RBP: ffff8800512d23c0 R08: 0000000000000000 R09: 0000000000000000 R10: ffff88003ff5de28 R11: 00000000000000b0 R12: ffff88003fb404b0 R13: ffff88003fb404b0 R14: ffff8800545af0c0 R15: ffff88003fed64b0 FS: 00002b71ceb65210(0000) GS:ffffffff805ca000(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 Process crash (pid: 12585, threadinfo ffff88003ff5c000, task ffff880060288040) Stack: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000003129 0000000000000000 0000000000000000 0000000000000000 Call Trace: [<ffffffff802132d8>] fput+0x94/0x198 [<ffffffff802240af>] filpclose+0x5c/0x64 [<ffffffff8021e2c7>] sysclose+0x88/0xbd [<ffffffff802602f9>] tracesys+0xab/0xb6

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.

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.

Gleb Natapov found a bug in KVM that allows code that runs in CPL3 (inside a guest) to modify memory in CPL0 (inside a guest). The bug is in x86 emulator code. When emulator accesses guest's memory on behalf of the gust's code it does this with the CPL0 privilege, so if emulated instruction is executed by unprivileged code it can still modify memory that otherwise is not accessible to it. To tak advantage of this vulnerability malicious code should trick KVM to emulate malicious instruction. KVM emulates IO and MMIO instructions, so if unprivileged process has access to some IO port or MMIO region (framebuffer for instance) the bug is very easy to use to modify arbitrary location in kernel memory.

Description of problem: There's a pile of upstream commits that fixed issues that can lead to user-triggerable panics on supported boxes: http://groups.google.com/group/linux.kernel/msg/895f20870532241e.

54f5de709984bae0d31d823ff03de755f9dcac54 ecc1a8993751de4e82eb18640d631dae1f626bd6 1a0ef85f84feb13f07b604fcf5b90ef7c2b5c82f f106af4e90eadd76cfc0b5325f659619e08fb762 097eed103862f9c6a97f2e415e21d1134017b135 935874141df839c706cd6cdc438e85eb69d1525e 0ec62d290912bb4b989be7563851bc364ec73b56 c4caa778157dbbf04116f0ac2111e389b5cd7a29 2ea1d13f64efdf49319e86c87d9ba38c30902782 570dcf2c15463842e384eb597a87c1e39bead99b 564b3bffc619dcbdd160de597b0547a7017ea010 0067bd8a55862ac9dd212bd1c4f6f5bff1ca1301 f8b7256096a20436f6d0926747e3ac3d64c81d24 8c7b49b3ecd48923eb64ff57e07a1cdb74782970 9206de95b1ea68357996ec02be5db0638a0de2c1 2c6a10161d0b5fc047b5bd81b03693b9af99fab5 05d72faa6d13c9d857478a5d35c85db9adada685 bb52d6694002b9d632bb355f64daa045c6293a4e e77414e0aad6a1b063ba5e5750c582c75327ea6a aa65607373a4daf2010e8c3867b6317619f3c1a3

http://groups.google.co.jp/group/fa.linux.kernel/browsethread/thread/8bf22336b1082090

Description of problem: When print-fatal-signals is enabled it's possible to dump any memory reachable by the kernel to the log by simply jumping to that address from user space.

Or crash the system if there's some hardware with read side effects.

The fatal signals handler will dump 16 bytes at the execution address, which is fully controlled by ring 3.

In addition when something jumps to a unmapped address there will be up to 16 additional useless page faults, which might be potentially slow (and at least is not very efficient)

Fortunately this option is off by default and only there on i386.

But fix it by checking for kernel addresses and also stopping when there's a page fault.

References: http://patchwork.kernel.org/patch/69752/ http://git.kernel.org/linus/b45c6e76bc2c72f6426c14bed64fdcbc9bf37cb0

Quoting httpd 2.2 security page: http://httpd.apache.org/security/vulnerabilities22.html#2.2.15

low: Request header information leak CVE-2010-0434

A bug in the handling of headers in subrequests could lead to a reuse of memory. In a multithreaded MPM this could possibly cause an information leak from other requests being handled by a different thread.

Affects: 2.2.0 - 2.2.14

Upstream bug: https://issues.apache.org/bugzilla/showbug.cgi?id=48359

Upstream commits (2.2.x branch): http://svn.apache.org/viewvc?view=revision&revision=917867 http://svn.apache.org/viewvc?view=revision&revision=918427

The decompression implementation in the Imf::hufUncompress function in OpenEXR 1.2.2 and 1.6.1 allows context-dependent attackers to cause a denial of service (application crash) or possibly execute arbitrary code via vectors that trigger a free of an uninitialized pointer.

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.

The aclgroupoverride function in smbd/posixacls.c in smbd in Samba 3.0.x before 3.0.35, 3.1.x and 3.2.x before 3.2.13, and 3.3.x before 3.3.6, when dos filemode is enabled, allows remote attackers to modify access control lists for files via vectors related to read access to uninitialized memory.

Xfig, possibly 3.2.5, allows local users to read and write arbitrary files via a symlink attack on the (1) xfig-eps[PID], (2) xfig-pic[PID].pix, (3) xfig-pic[PID].err, (4) xfig-pcx[PID].pix, (5) xfig-xfigrc[PID], (6) xfig[PID], (7) xfig-print[PID], (8) xfig-export[PID].err, (9) xfig-batch[PID], (10) xfig-exp[PID], or (11) xfig-spell.[PID] temporary files, where [PID] is a process ID.

Description of problem: Frank Filz reported: the problem is that permission checking is skipped if atomic open is possible, but when exec opens a file, it just opens it OREADONLY which means EXEC permission will not be checked at that time.

This problem is observed by the following sequence (executed as root):

mount -t nfs4 server:/ /mnt4 echo "ls" >/mnt4/foo chmod 744 /mnt4/foo su guest -c "mnt4/foo"

Reference: http://article.gmane.org/gmane.linux.nfs/26592

Description of problem: The vmxsetmsr function in arch/x86/kvm/vmx.c in the VMX implementation in the KVM subsystem in the Linux kernel before 2.6.29.1 on the i386 platform allows guest OS users to cause a denial of service (OOPS) by setting the EFERLME (aka "Long mode enable") bit in the Extended Feature Enable Register (EFER) model-specific register, which is specific to the x8664 platform.

Reference: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiffplain;h=16175a796d061833aacfbd9672235f2d2725df65

nss-ldapd before 0.6.8 uses world-readable permissions for the /etc/nss-ldapd.conf file, which allows local users to obtain a cleartext password for the LDAP server by reading the bindpw field.

The ASN1STRINGprintex function in OpenSSL before 0.9.8k allows remote attackers to cause a denial of service (invalid memory access and application crash) via vectors that trigger printing of a (1) BMPString or (2) UniversalString with an invalid encoded length.

Race condition in the SystemTap stap tool 0.0.20080705 and 0.0.20090314 allows local users in the stapusr group to insert arbitrary SystemTap kernel modules and gain privileges via unknown vectors.

nfsd in the Linux kernel before 2.6.28.9 does not drop the CAPMKNOD capability before handling a user request in a thread, which allows local users to create device nodes, as demonstrated on a filesystem that has been exported with the rootsquash option.