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.
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.
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: 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.
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: 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.
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.
Google Chrome before 5.0.375.127, and webkitgtk before 1.2.6, does not properly implement the history feature, which might allow remote attackers to spoof the address bar via unspecified vectors.
Description of problem: We leak at least 32bits of kernel memory to user land in tc dump, because we dont init all fields (capab ?) of the dumped structure.
Use C99 initializers so that holes and non explicit fields are zeroed.
http://patchwork.ozlabs.org/patch/61857/
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.