python-django: Password hash disclosure to "view only" admin users

An issue was discovered in Django 2.1 before 2.1.2, in which unprivileged users can read the password hashes of arbitrary accounts. The read-only password widget used by the Django Admin to display an obfuscated password hash was bypassed if a user has only the "view" permission (new in Django 2.1), resulting in display of the entire password hash to those users. This may result in a vulnerability for sites with legacy user accounts using insecure hashes.

Monstra CMS V3.0.4 has an information leakage risk (e.g., PATH, DOCUMENT_ROOT, and SERVER_ADMIN) in libraries/Gelato/ErrorHandler/Resources/Views/Errors/exception.php.

Citrix ShareFile StorageZones Controller before 5.4.2 has Information Exposure Through an Error Message.

An issue was discovered in Oracle WebCenter Interaction Portal 10.3.3. The portal component is delivered with an insecure default User Profile community configuration that allows anonymous users to retrieve the account names of all portal users via /portal/server.pt/user/user/ requests. When WCI is synchronised with Active Directory (AD), this vulnerability can expose the account names of all AD users. NOTE: this CVE is assigned by MITRE and isn't validated by Oracle because Oracle WebCenter Interaction Portal is out of support.

The AjaxControl component of Oracle WebCenter Interaction Portal 10.3.3 does not validate the names of pages when processing page rename requests. Pages can be renamed to include characters unsupported for URIs by the web server hosting the WCI Portal software (such as IIS). Renaming pages to include unsupported characters, such as 0x7f, prevents these pages from being accessed over the web server, causing a Denial of Service (DoS) to the page. NOTE: this CVE is assigned by MITRE and isn't validated by Oracle because Oracle WebCenter Interaction Portal is out of support.

An issue was discovered in OpenAFS before 1.6.23 and 1.8.x before 1.8.2. Several RPC server routines did not fully initialize their output variables before returning, leaking memory contents from both the stack and the heap. Because the OpenAFS cache manager functions as an Rx server for the AFSCB service, clients are also susceptible to information leakage. For example, RXAFSCB_TellMeAboutYourself leaks kernel memory and KAM_ListEntry leaks kaserver memory.

ceph: debug logging for v4 auth does not sanitize encryption keys

Ceph does not properly sanitize encryption keys in debug logging for v4 auth. This results in the leaking of encryption key information in log files via plaintext. Versions up to v13.2.4 are vulnerable.

sssd: Information leak in infopipe due to an improper uid restriction

sssd versions from 1.13.0 to before 2.0.0 did not properly restrict access to the infopipe according to the "allowed_uids" configuration parameter. If sensitive information were stored in the user directory, this could be inadvertently disclosed to local attackers.

ansible: Information disclosure in vvv+ mode with no_log on

ansible before versions 2.5.14, 2.6.11, 2.7.5 is vulnerable to a information disclosure flaw in vvv+ mode with no_log on that can lead to leakage of sensible data.

golang: crypto/x509 allows for denial of service via crafted TLS client certificate

The crypto/x509 package of Go before 1.10.6 and 1.11.x before 1.11.3 does not limit the amount of work performed for each chain verification, which might allow attackers to craft pathological inputs leading to a CPU denial of service. Go TLS servers accepting client certificates and TLS clients are affected.

golang: "go get" vulnerable to directory traversal via malicious package

In Go before 1.10.6 and 1.11.x before 1.11.3, the "go get" command is vulnerable to directory traversal when executed with the import path of a malicious Go package which contains curly braces (both '{' and '}' characters). Specifically, it is only vulnerable in GOPATH mode, but not in module mode (the distinction is documented at https://golang.org/cmd/go/#hdr-Module_aware_go_get). The attacker can cause an arbitrary filesystem write, which can lead to code execution.

golang: "go get" command vulnerable to RCE via import of malicious package

In Go before 1.10.6 and 1.11.x before 1.11.3, the "go get" command is vulnerable to remote code execution when executed with the -u flag and the import path of a malicious Go package, or a package that imports it directly or indirectly. Specifically, it is only vulnerable in GOPATH mode, but not in module mode (the distinction is documented at https://golang.org/cmd/go/#hdr-Module_aware_go_get). Using custom domains, it's possible to arrange things so that a Git repository is cloned to a folder named ".git" by using a vanity import path that ends with "/.git". If the Git repository root contains a "HEAD" file, a "config" file, an "objects" directory, a "refs" directory, with some work to ensure the proper ordering of operations, "go get -u" can be tricked into considering the parent directory as a repository root, and running Git commands on it. That will use the "config" file in the original Git repository root for its configuration, and if that config file contains malicious commands, they will execute on the system running "go get -u".

It was found that wolfssl before 3.15.7 is vulnerable to a new variant of the Bleichenbacher attack to perform downgrade attacks against TLS. This may lead to leakage of sensible data.

nettle: Leaky data conversion exposing a manager oracle

A Bleichenbacher type side-channel based padding oracle attack was found in the way nettle handles endian conversion of RSA decrypted PKCS#1 v1.5 data. An attacker who is able to run a process on the same physical core as the victim process, could use this flaw extract plaintext or in some cases downgrade any TLS connections to a vulnerable server.

gnutls: Bleichenbacher-like side channel leakage in PKCS#1 v1.5 verification and padding oracle verification

A Bleichenbacher type side-channel based padding oracle attack was found in the way gnutls handles verification of RSA decrypted PKCS#1 v1.5 data. An attacker who is able to run process on the same physical core as the victim process, could use this to extract plaintext or in some cases downgrade any TLS connections to a vulnerable server.

kernel: cleancache: Infoleak of deleted files after reuse of old inodes

A security flaw was found in the Linux kernel in a way that the cleancache subsystem clears an inode after the final file truncation (removal). The new file created with the same inode may contain leftover pages from cleancache and the old file data instead of the new one.

openstack-mistral: std.ssh action may disclose presence of arbitrary files

A flaw was found in openstack-mistral. By manipulating the SSH private key filename, the std.ssh action can be used to disclose the presence of arbitrary files within the filesystem of the executor running the action. Since std.ssh private_key_filename can take an absolute path, it can be used to assess whether or not a file exists on the executor's filesystem.

nginx: Denial of service and memory disclosure via mp4 module

nginx before versions 1.15.6, 1.14.1 has a vulnerability in the ngx_http_mp4_module, which might allow an attacker to cause infinite loop in a worker process, cause a worker process crash, or might result in worker process memory disclosure by using a specially crafted mp4 file. The issue only affects nginx if it is built with the ngx_http_mp4_module (the module is not built by default) and the .mp4. directive is used in the configuration file. Further, the attack is only possible if an attacker is able to trigger processing of a specially crafted mp4 file with the ngx_http_mp4_module.

ghostscript: Incorrect "restoration of privilege" checking when running out of stack during exception handling

An issue was discovered in Artifex Ghostscript before 9.25. Incorrect "restoration of privilege" checking when running out of stack during exception handling could be used by attackers able to supply crafted PostScript to execute code using the "pipe" instruction. This is due to an incomplete fix for CVE-2018-16509.

In Go Ethereum (aka geth) before 1.8.14, TraceChain in eth/api_tracer.go does not verify that the end block is after the start block.