VMware ESX contains an insufficient logging vulnerability. A malicious administrator could exploit this issue to perform certain operations without them being logged.
VMware ESX contains an out-of-bounds write vulnerability in the VMXNET3 virtual network adapter. A malicious actor with local administrative privileges on a virtual machine with VMXNET3 virtual network adapter may exploit this issue to execute code on the host. Non VMXNET3 virtual adapters are not affected by this issue.
A flaw was found in the bash functionality that evaluates specially formatted environment variables passed to it from another environment. An attacker could use this feature to override or bypass restrictions to the environment to execute shell commands before restrictions have been applied. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue.
Acknowledgements:
Red Hat would like to thank Stephane Chazelas for reporting this issue.
GNU Bash through 4.3 bash43-025 processes trailing strings after certain malformed function definitions in the values of environment variables, which allows remote attackers to write to files or possibly have unknown other impact via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the modcgi and modcgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution. NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-6271.
VMware ESXi 4.0 through 5.1 and ESX 4.0 and 4.1 allow remote attackers to cause a denial of service (NULL pointer dereference) by intercepting and modifying Network File Copy (NFC) traffic.
VMware Workstation 9.x before 9.0.1, VMware Player 5.x before 5.0.1, VMware Fusion 5.x before 5.0.1, VMware ESXi 4.0 through 5.1, and VMware ESX 4.0 and 4.1 allow guest OS users to cause a denial of service (VMX process disruption) by using an invalid port.
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.
Created attachment 331637 [details] ipdstcache (in blue) VS route -Cn | wc -l (in green) over time
Description of problem: The value of ipdstcache (in /proc/slabinfo) continues to grow constantly, even thought the cached route table remains fairly constant. This leads to the eventual time when ipdstcache reaches the value of /proc/sys/net/ipv4/route/maxsize. When this happens, the kernel complains with 'dst cache overflow' and the server no longer responds to any network activity.
Version-Release number of selected component (if applicable): kernel 2.6.18-92.1.22.el5
How reproducible: live system being currently affected by this issue.
Steps to Reproduce: 1. Configure test machine as a router between two networks 2. send packets from network A to network B with a large number of different source/dest IPs 3. Watch the values of ipdstcache and rtcache Actual results: ipdstcache continues to grow while rtcache grows and shrinks with the traffic
Expected results: ipdstcache and rtcache follow each other closely. Values return to zero after traffic stops and route cache entries expire.
Additional info:
It was discovered that sudo's sudoers file parses does not correctly handle group specification in RunasUser. If group was specified in the list (using syntax %group, to allow some user to run commands as any member of the group) and the user was already member of the group, sudo actually allowed the user to run commands as arbitrary system user.
SuSE and upstream bug report: https://bugzilla.novell.com/showbug.cgi?id=468923 http://www.gratisoft.us/bugzilla/showbug.cgi?id=327
This issue was confirmed on multiple 1.6.9 sudo versions. Latest upstream 1.7.0 was reported not to be affected, 1.6.8p12 previously shipped with Red Hat Enterprise Linux 5 was not affected as well. Problem was confirmed on 1.6.9p17 in RHEL5 and Fedora 10.
Upstream patch:
Index: parse.c =================================================================== RCS file: /home/cvs/courtesan/sudo/parse.c,v retrieving revision 1.160.2.21 diff -u -r1.160.2.21 parse.c --- parse.c 2 Nov 2008 14:35:53 -0000 1.160.2.21 +++ parse.c 23 Jan 2009 19:16:55 -0000 @@ -651,9 +651,11 @@ / If the user has a supplementary group vector, check it first. / - for (i = 0; i < userngroups; i++) { - if (grp->grgid == usergroups[i]) - return(TRUE); + if (strcmp(user, username) == 0) { + for (i = 0; i < userngroups; i++) { + if (grp->grgid == usergroups[i]) + return(TRUE); + } } if (grp->grmem != NULL) { for (cur = grp->grmem; cur; cur++) {
VMware ESX Server 1.5.2 before Patch 4 allows local users to execute arbitrary programs as root via certain modified VMware ESX Server environment variables.
VMware Tools in VMware Workstation 6.5.x before 6.5.4 build 246459; VMware Player 2.5.x before 2.5.4 build 246459; VMware ACE 2.5.x before 2.5.4 build 246459; VMware Server 2.x before 2.0.2 build 203138; VMware Fusion 2.x before 2.0.6 build 246742; VMware ESXi 3.5 and 4.0; and VMware ESX 2.5.5, 3.0.3, 3.5, and 4.0 does not properly access libraries, which allows user-assisted remote attackers to execute arbitrary code by tricking a Windows guest OS user into clicking on a file that is stored on a network share.
VMware Tools in VMware Workstation 6.5.x before 6.5.4 build 246459; VMware Player 2.5.x before 2.5.4 build 246459; VMware ACE 2.5.x before 2.5.4 build 246459; VMware Server 2.x before 2.0.2 build 203138; VMware Fusion 2.x before 2.0.6 build 246742; VMware ESXi 3.5 and 4.0; and VMware ESX 2.5.5, 3.0.3, 3.5, and 4.0 does not properly load VMware programs, which might allow Windows guest OS users to gain privileges by placing a Trojan horse program at an unspecified location on the guest OS disk.
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: A vulnerability in the 32-bit compatibility layer for 64-bit systems was reported. It is caused by insecure allocation of user space memory when translating system call inputs to 64-bit. A stack pointer underflow can occur when using the "compatallocuserspace" method with an arbitrary length input.
Reference: http://sota.gen.nz/compat1/
Upstream commit: http://git.kernel.org/linus/c41d68a513c71e35a14f66d71782d27a79a81ea6
Acknowledgements:
Red Hat would like to thank Ben Hawkes for reporting this issue.
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
http://kerneltrap.org/mailarchive/linux-netdev/2010/3/3/6271093/thread "The root cause for this problem is, when the receiver is doing releasesock() (i.e. after userspace recv, kernel udprecvmsg->skbfreedatagramlocked->releasesock), it moves skbs from backlog to skreceivequeue with the softirq enabled. In the above case, multiple busy senders will almost make it an endless loop. The skbs in the backlog end up eat all the system memory.
The issue is not only for UDP. Any protocols using socket backlog is potentially affected. The patch adds limit for socket backlog so that the backlog size cannot be expanded endlessly."
Upstream commits: http://git.kernel.org/linus/2499849ee8f513e795b9f2c19a42d6356e4943a4 http://git.kernel.org/linus/53eecb1be5ae499d399d2923933937a9ea1a284f http://git.kernel.org/linus/50b1a782f845140f4138f14a1ce8a4a6dd0cc82f http://git.kernel.org/linus/79545b681961d7001c1f4c3eb9ffb87bed4485db http://git.kernel.org/linus/55349790d7cbf0d381873a7ece1dcafcffd4aaa9 http://git.kernel.org/linus/6b03a53a5ab7ccf2d5d69f96cf1c739c4d2a8fb9 http://git.kernel.org/linus/8eae939f1400326b06d0c9afe53d2a484a326871 http://git.kernel.org/linus/a3a858ff18a72a8d388e31ab0d98f7e944841a62 http://git.kernel.org/linus/c377411f2494a931ff7facdbb3a6839b1266bcf6
Last updated 24 July 2024
Last updated 24 July 2024
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.
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/
Unspecified vulnerability in the Management Interface in VMware ESX Server 2.x up to 2.5.x before 24 December 2005 allows "remote code execution in the Web browser" via unspecified attack vectors, probably related to cross-site scripting (XSS).
Cross-site scripting (XSS) vulnerability in the management interface for VMware ESX 2.5.x before 2.5.2 upgrade patch 2, 2.1.x before 2.1.2 upgrade patch 6, and 2.0.x before 2.0.1 upgrade patch 6 allows remote attackers to inject arbitrary web script or HTML via messages that are not sanitized when viewing syslog log files.
Cross-site request forgery (CSRF) vulnerability in the management interface for VMware ESX Server 2.0.x before 2.0.2 patch 1, 2.1.x before 2.1.3 patch 1, and 2.x before 2.5.3 patch 2 allows allows remote attackers to perform unauthorized actions as the administrator via URLs, as demonstrated using the setUsr operation to change a password. NOTE: this issue can be leveraged with CVE-2005-3619 to automatically perform the attacks.
The management interface for VMware ESX Server 2.0.x before 2.0.2 patch 1, 2.1.x before 2.1.3 patch 1, and 2.x before 2.5.3 patch 2 records passwords in cleartext in URLs that are stored in world-readable web server log files, which allows local users to gain privileges.
vmware-config.pl in VMware for Linux, ESX Server 2.x, and Infrastructure 3 does not check the return code from a Perl chmod function call, which might cause an SSL key file to be created with an unsafe umask that allows local users to read or modify the SSL key.
VMware ESX Server 2.0.x before 2.0.2 and 2.x before 2.5.2 patch 4 stores authentication credentials in base 64 encoded format in the vmware.mui.kid and vmware.mui.sid cookies, which allows attackers to gain privileges by obtaining the cookies using attacks such as cross-site scripting (CVE-2005-3619).
HGFS.sys in the VMware Tools package in VMware Workstation 5.x before 5.5.6 build 80404, VMware Player before 1.0.6 build 80404, VMware ACE before 1.0.5 build 79846, VMware Server before 1.0.5 build 80187, and VMware ESX 2.5.4 through 3.0.2 does not properly validate arguments in user-mode METHODNEITHER IOCTLs to the \\.\hgfs device, which allows guest OS users to modify arbitrary memory locations in guest kernel memory and gain privileges.
Buffer overflow in OpenPegasus Management server, when compiled to use PAM and with PEGASUSUSEPAMSTANDALONEPROC defined, as used in VMWare ESX Server 3.0.1 and 3.0.2, might allow remote attackers to execute arbitrary code via vectors related to PAM authentication, a different vulnerability than CVE-2008-0003.
Double free vulnerability in VMware ESX Server 3.0.0 and 3.0.1 allows attackers to cause a denial of service (crash), obtain sensitive information, or possibly execute arbitrary code via unspecified vectors.
Buffer overflow in VMware ESX Server 3.0.0 and 3.0.1 might allow attackers to gain privileges or cause a denial of service (application crash) via unspecified vectors.