A stack buffer overflow vulnerability has been discovered in the official Kentico v9.0, v10.0 & v11.0 content management system software. The vulnerability allows local attackers to compromise the software service to execute system specific attacks. The vulnerability is located in the `/CMSModules/AdminControls/Controls/Selectors/UserSelector.ascx.cs` file. Local attackers are able to inject own malicious script codes to compromise the software service. The request method to inject is POST and the attack vector is located on the application-side of the service.
The malicious content sent to the web browser often takes the form of a segment of JavaScript, but may also include HTML, Flash, or any other type of code that the browser may execute. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data, like cookies or other session information, to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
BizLogic xnami 1.0 has XSS via the comment parameter in an addComment action to the /media/ajax URI. At any uploaded media there is a comment system where people can post (also anonymous). The comment system is vulnerable to XSS attacks. Since it's persistent and there is an user login interface, it's possible for attackers to steal sessions of users and thus admin(s).
In the 'ScanForMissingValues' method, it uses 'head'. But it doesn't check the grown segment 'current' is equal to 'head' before calling the method. This can lead to an out-of-bounds write vulnerability.
The syscall process_policy(scope=PROC_POLICY_SCOPE_PROCESS, action=PROC_POLICY_ACTION_GET, policy=PROC_POLICY_RESOURCE_USAGE, policy_subtype=PROC_POLICY_RUSAGE_CPU, attrp=<userbuf>, target_pid=0, target_threadid=<ignored>) causes 4 bytes of uninitialized kernel stack memory to be written to userspace. If task_get_cpuusage() set *scope=0 because none of the flags TASK_RUSECPU_FLAGS_PERTHR_LIMIT, TASK_RUSECPU_FLAGS_PROC_LIMIT and TASK_RUSECPU_FLAGS_DEADLINE are set in task->rusage_cpu_flags, proc_get_task_ruse_cpu() does not write anything into *policyp, meaning that cpuattr.ppattr_cpu_attr in handle_cpuuse() remains uninitialized. task_get_cpuusage() and proc_get_task_ruse_cpu() always return zero, so handle_cpuuse() will copy cpuattr, including the unititialized ppattr_cpu_attr field, to userspace.
This module exploits a file upload vulnerability in phpCollab 2.5.1 which could be abused to allow unauthenticated users to execute arbitrary code under the context of the web server user.
The SMB server driver (srv.sys and srv2.sys) don't check the destination of a NTFS mount point when manually handling a reparse operation leading to being able to locally open an arbitrary device via an SMB client which can result in EoP. NTFS mount points are handled local to the SMB server so that the client does not see them. This is different from NTFS symbolic links which are passed back to the client to deal with. In order to handle the symbolic link case the server calls IoCreateFileEx from Smb2CreateFile passing the IO_STOP_ON_SYMLINK flag which results in the IoCreateFileEx call failing with the STATUS_STOPPED_ON_SYMLINK code. The server can then extract the substitution path from the reparse pointer buffer and either pass the buffer to the client if it's a symbolic link or handle it if it's a mount point. The way the server handles a symbolic link is to recall IoCreateFileEx in a loop (it does check for a maximum iteration count although I'd swear that's a recent change) passing the new substitute path. This is different to how the IO manager would handle this operation. In the IO manager's case the reparse operation is limited to a small subset of device types, such as Disk Volumes. If the new target isn't in the small list of types then the reparse will fail with an STATUS_IO_REPARSE_DATA_INVALID error. However the SMB server does no checks so the open operation can be redirected to any device. This is interesting due to the way in which the device is being opened, it's in a system thread and allows a caller to pass an arbitrary EA block which can be paged in.
When impersonating the anonymous token in an LPAC the WIN://NOAPPALLPKG security attribute is ignored leading to impersonating a non-LPAC token leading to EoP.
There's a missing check for impersonation level in NtImpersonateAnonymousToken when considering if the caller is currently an AC. This results in the function falling into the restricted token case if the caller is impersonating a non AC token at identification or below, leading to Elevation of Privilege.
When creating a new file on an NTFS drive it’s possible to circumvent security checks for setting an arbitrary owner and mandatory label leading to a non-admin user setting those parts of the security descriptor with non-standard values which could result in further attacks resulting EoP. The kernel limits who can arbitrarily set the Owner and Mandatory Label fields of a security descriptor. Specifically unless the current token has SeRestorePrivilege, SeTakeOwnershipPrivilege or SeRelabelPrivilege you can only set an owner which is set in the current token (for the label is can also be less than the current label). As setting an arbitrary owner in the token or raising the IL is also a privileged operation this prevents a normal user from setting these fields to arbitrary values. When creating a new file on an NTFS volume you can specify an arbitrary Security Descriptor with the create request and it will be set during the creation process. If you specify an arbitrary owner or label it will return an error as expected. Looking at the implementation in NTFS the function NtfsCreateNewFile calls NtfsAssignSecurity which then calls the kernel API SeAssignSecurityEx. The problem here is that SeAssignSecurityEx doesn’t take an explicit KPROCESSOR_MODE argument so instead the kernel takes the current thread’s previous access mode. The previous mode however might not match up with the current assumed access mode based on the caller, for example if the create call has been delegated to a system thread. A common place this mode mismatch occurs is in the SMB server, which runs entirely in the system process. All threads used by SMB are running with a previous mode of KernelMode, but will create files by specifying IO_FORCE_ACCESS_CHECK so that the impersonated caller identity is used for security cheks. This means that when creating a new file on an NTFS volume the security descriptor will be set using the kernel mode SeAssignSecurityEx API, allowing an arbitrary owner and mandatory label to be set.
Services By CQR