aswin1906/github-advisory-2021.csv huggingface dataset:
Arbitrary File Creation/Overwrite on Windows via insufficient relative path sanitization
Published: 2021-08-31T16:05:05Z
Aliases: CVE-2021-37713

### Impact

Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution

node-tar aims to guarantee that any file whose location would be outside of the extraction target directory is not extracted. This is, in part, accomplished by sanitizing absolute paths of entries within the archive, skipping archive entries that contain `..` path portions, and resolving the sanitized paths against the extraction target directory.

This logic was insufficient on Windows systems when extracting tar files that contained a path that was not an absolute path, but specified a drive letter different from the extraction target, such as `C:some\path`.  If the drive letter does not match the extraction target, for example `D:\extraction\dir`, then the result of `path.resolve(extractionDirectory, entryPath)` would resolve against the current working directory on the `C:` drive, rather than the extraction target directory.

Additionally, a `..` portion of the path could occur immediately after the drive letter, such as `C:../foo`, and was not properly sanitized by the logic that checked for `..` within the normalized and split portions of the path.

This only affects users of `node-tar` on Windows systems.

### Patches

4.4.18 || 5.0.10 || 6.1.9

### Workarounds

There is no reasonable way to work around this issue without performing the same path normalization procedures that node-tar now does.

Users are encouraged to upgrade to the latest patched versions of node-tar, rather than attempt to sanitize paths themselves.

### Fix

The fixed versions strip path roots from all paths prior to being resolved against the extraction target folder, even if such paths are not "absolute".

Additionally, a path starting with a drive letter and then two dots, like `c:../`, would bypass the check for `..` path portions.  This is checked properly in the patched versions.

Finally, a defense in depth check is added, such that if the `entry.absolute` is outside of the extraction taret, and we are not in preservePaths:true mode, a warning is raised on that entry, and it is skipped.  Currently, it is believed that this check is redundant, but it did catch some oversights in development.
Uninitialized memory access in outer_cgi
Published: 2021-08-25T20:55:25Z
Aliases: CVE-2021-30454

An issue was discovered in the outer_cgi crate before 0.2.1 for Rust. A user-provided Read instance receives an uninitialized memory buffer from KeyValueReader.
Multiple security issues including data race, buffer overflow, and uninitialized memory drop in arr
Published: 2021-08-25T20:49:04Z
Aliases: CVE-2020-35886

arr crate contains multiple security issues. Specifically,

1.  It incorrectly implements Sync/Send bounds, which allows to smuggle non-Sync/Send types across the thread boundary.
2. Index and IndexMut implementation does not check the array bound.
3. Array::new_from_template() drops uninitialized memory.
Data races in rulinalg
Published: 2021-08-25T20:48:09Z
Aliases: CVE-2020-35879

The affected version of rulinalg has incorrect lifetime boundary definitions for RowMut::raw_slice and RowMut::raw_slice_mut. They do not conform with Rust's borrowing rule and allows the user to create multiple mutable references to the same location. This may result in unexpected calculation result and data race if both references are used at the same time.
Cross-site scripting in jfinal
Published: 2021-08-13T15:22:14Z
Aliases: CVE-2021-33348

An issue was discovered in JFinal framework v4.9.10 and below. The "set" method of the "Controller" class of jfinal framework is not strictly filtered, which will lead to XSS vulnerabilities in some cases.
Out-of-bounds write in ChakraCore
Published: 2021-08-02T17:26:23Z
Aliases: CVE-2020-0768

A remote code execution vulnerability exists in the way the scripting engine handles objects in memory in Microsoft browsers, aka 'Scripting Engine Memory Corruption Vulnerability'. This CVE ID is unique from CVE-2020-0823, CVE-2020-0825, CVE-2020-0826, CVE-2020-0827, CVE-2020-0828, CVE-2020-0829, CVE-2020-0830, CVE-2020-0831, CVE-2020-0832, CVE-2020-0833, CVE-2020-0848.
TimelockController vulnerability in OpenZeppelin Contracts
Published: 2021-08-30T16:12:49Z
Aliases: CVE-2021-39168

### Impact

A vulnerability in `TimelockController` allowed an actor with the executor role to take immediate control of the timelock, by resetting the delay to 0 and escalating privileges, thus gaining unrestricted access to assets held in the contract. Instances with the executor role set to "open" allow anyone to use the executor role, thus leaving the timelock at risk of being taken over by an attacker.

### Patches

A fix is included in the following releases of `@openzeppelin/contracts` and `@openzeppelin/contracts-upgradeable`:
- 4.3.1
- 3.4.2
- 3.4.2-solc-0.7

Deployed instances of `TimelockController` should be replaced with a fixed version by migrating all assets, ownership, and roles.

### Workarounds

Revoke the executor role from accounts not strictly under the team's control. We recommend revoking all executors that are not also proposers. When applying this mitigation, ensure there is at least one proposer and executor remaining.

### References

[Post-mortem](https://forum.openzeppelin.com/t/timelockcontroller-vulnerability-postmortem/14958).

### Credits

The issue was identified by an anonymous white hat hacker through [Immunefi](https://immunefi.com/).

### For more information

If you have any questions or comments about this advisory, or need assistance executing the mitigation, email us at security@openzeppelin.com.
Improperly Controlled Modification of Object Prototype Attributes
Published: 2021-08-03T16:48:46Z

### Impact

The software receives input from an upstream component that specifies attributes that are to be initialized or updated in an object, but it does not properly control modifications of attributes of the object prototype.

### Patches

`think-config@1.1.3` patched it, anyone used `think-config` should upgrade to `>=1.1.3` version.

### References

https://cwe.mitre.org/data/definitions/1321.html

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [thinkjs/thinkjs](https://github.com/thinkjs/thinkjs)
* Email us at [i@imnerd.org](mailto:i@imnerd.org)
Arbitrary File Creation/Overwrite via insufficient symlink protection due to directory cache poisoning
Published: 2021-08-03T19:00:40Z
Aliases: CVE-2021-32803

### Impact

Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution

`node-tar` aims to guarantee that any file whose location would be modified by a symbolic link is not extracted. This is, in part, achieved by ensuring that extracted directories are not symlinks.  Additionally, in order to prevent unnecessary `stat` calls to determine whether a given path is a directory, paths are cached when directories are created.

This logic was insufficient when extracting tar files that contained both a directory and a symlink with the same name as the directory. This order of operations resulted in the directory being created and added to the `node-tar` directory cache. When a directory is present in the directory cache, subsequent calls to mkdir for that directory are skipped. However, this is also where `node-tar` checks for symlinks occur.

By first creating a directory, and then replacing that directory with a symlink, it was thus possible to bypass `node-tar` symlink checks on directories, essentially allowing an untrusted tar file to symlink into an arbitrary location and subsequently extracting arbitrary files into that location, thus allowing arbitrary file creation and overwrite.

This issue was addressed in releases 3.2.3, 4.4.15, 5.0.7 and 6.1.2.

### Patches

3.2.3 || 4.4.15 || 5.0.7 || 6.1.2

### Workarounds

Users may work around this vulnerability without upgrading by creating a custom `filter` method which prevents the extraction of symbolic links.

```js
const tar = require('tar')

tar.x({
  file: 'archive.tgz',
  filter: (file, entry) => {
    if (entry.type === 'SymbolicLink') {
      return false
    } else {
      return true
    }
  }
})
```

Users are encouraged to upgrade to the latest patch versions, rather than attempt to sanitize tar input themselves.
Data races in generator
Published: 2021-08-25T20:55:41Z

The `Generator` type is an iterable which uses a generator function that yields
values. In affected versions of the crate, the provided function yielding values
had no `Send` bounds despite the `Generator` itself implementing `Send`.

The generator function lacking a `Send` bound means that types that are
dangerous to send across threads such as `Rc` could be sent as part of a
generator, potentially leading to data races.

This flaw was fixed in commit [`f7d120a3b`](https://github.com/Xudong-Huang/generator-rs/commit/f7d120a3b724d06a7b623d0a4306acf8f78cb4f0)
by enforcing that the generator function be bound by `Send`.
Array size is not checked in sized-chunks
Published: 2021-08-25T20:45:04Z
Aliases: CVE-2020-25793

An issue was discovered in the sized-chunks crate through 0.6.2 for Rust. In the Chunk implementation, the array size is not checked when constructed with From<InlineArray<A, T>>.
Cross-Site Scripting via SVG media files
Published: 2021-08-23T19:43:00Z
Aliases: CVE-2021-37710

### Impact
Cross-Site Scripting via SVG media files

### Patches
We recommend updating to the current version 6.4.3.1. You can get the update to 6.4.3.1 regularly via the Auto-Updater or directly via the download overview.

https://www.shopware.com/en/download/#shopware-6

### Workarounds
For older versions of 6.1, 6.2, and 6.3, corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version.
Use after free in image
Published: 2021-08-25T20:44:43Z
Aliases: CVE-2019-16138

Affected versions of this crate would call Vec::set_len on an uninitialized vector with user-provided type parameter, in an interface of the HDR image format decoder. They would then also call other code that could panic before initializing all instances.

This could run Drop implementations on uninitialized types, equivalent to use-after-free, and allow an attacker arbitrary code execution.

Two different fixes were applied. It is possible to conserve the interface by ensuring proper initialization before calling Vec::set_len. Drop is no longer called in case of panic, though.

Starting from version 0.22, a breaking change to the interface requires callers to pre-allocate the output buffer and pass a mutable slice instead, avoiding all unsafe code.
Use after free in rusqlite
Published: 2021-08-25T20:47:48Z
Aliases: CVE-2020-35870

An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated via an Auxdata API use-after-free.
Data race in va-ts
Published: 2021-08-25T20:51:56Z
Aliases: CVE-2020-36220

In the affected versions of this crate, Demuxer<T> unconditionally implemented Send with no trait bounds on T. This allows sending a non-Send type T across thread boundaries, which can cause undefined behavior like unlocking a mutex from a thread that didn't lock the mutex, or memory corruption from data race. The flaw was corrected in commit `0562cbf` by adding a T: Send bound to the Send impl for Demuxer<T>.
XStream is vulnerable to an Arbitrary Code Execution attack
Published: 2021-08-25T14:47:57Z
Aliases: CVE-2021-39146

### Impact
The vulnerability may allow a remote attacker to load and execute arbitrary code from a remote host only by manipulating the processed input stream. No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types.

### Patches
XStream 1.4.18 uses no longer a blacklist by default, since it cannot be secured for general purpose.

### Workarounds
See [workarounds](https://x-stream.github.io/security.html#workaround) for the different versions covering all CVEs.

### References
See full information about the nature of the vulnerability and the steps to reproduce it in XStream's documentation for [CVE-2021-39146](https://x-stream.github.io/CVE-2021-39146.html).

### Credits
Ceclin and YXXX from the Tencent Security Response Center found and reported the issue to XStream and provided the required information to reproduce it.

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [XStream](https://github.com/x-stream/xstream/issues)
* Contact us at [XStream Google Group](https://groups.google.com/group/xstream-user)
XStream is vulnerable to an Arbitrary Code Execution attack
Published: 2021-08-25T14:47:28Z
Aliases: CVE-2021-39149

### Impact
The vulnerability may allow a remote attacker to load and execute arbitrary code from a remote host only by manipulating the processed input stream. No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types.

### Patches
XStream 1.4.18 uses no longer a blacklist by default, since it cannot be secured for general purpose.

### Workarounds
See [workarounds](https://x-stream.github.io/security.html#workaround) for the different versions covering all CVEs.

### References
See full information about the nature of the vulnerability and the steps to reproduce it in XStream's documentation for [CVE-2021-39149](https://x-stream.github.io/CVE-2021-39149.html).

### Credits
Lai Han of NSFOCUS security team found and reported the issue to XStream and provided the required information to reproduce it.

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [XStream](https://github.com/x-stream/xstream/issues)
* Contact us at [XStream Google Group](https://groups.google.com/group/xstream-user)
Data races in thex
Published: 2021-08-25T20:50:26Z
Aliases: CVE-2020-35927

An issue was discovered in the thex crate through 2020-12-08 for Rust. Thex<T> allows cross-thread data races of non-Send types.
Cachet configuration leak
Published: 2021-08-30T16:11:43Z
Aliases: CVE-2021-39174

### Impact

Authenticated users, regardless of their privileges (_User_ or _Admin_), can leak the value of any configuration entry of the dotenv file, e.g. the application secret (`APP_KEY`) and various passwords (email, database, etc). 

### Patches

This issue was addressed by improving `UpdateConfigCommandHandler` and preventing the use of nested variables in the resulting dotenv configuration file.

### Workarounds

Only allow trusted source IP addresses to access to the administration dashboard.

### References

Further technical details are available at [https://blog.sonarsource.com/cachet-code-execution-via-laravel-configuration-injection](https://blog.sonarsource.com/cachet-code-execution-via-laravel-configuration-injection).

### For more information

If you have any questions or comments about this advisory, you can contact:
- The original reporters, by sending an email to vulnerability.research [at] sonarsource.com;
- The maintainers, by opening an issue on this repository.
Arbitrary File Creation/Overwrite due to insufficient absolute path sanitization
Published: 2021-08-03T19:06:36Z
Aliases: CVE-2021-32804

### Impact

Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution

`node-tar` aims to prevent extraction of absolute file paths by turning absolute paths into relative paths when the `preservePaths` flag is not set to `true`. This is achieved by stripping the absolute path root from any absolute file paths contained in a tar file. For example `/home/user/.bashrc` would turn into `home/user/.bashrc`. 

This logic was insufficient when file paths contained repeated path roots such as `////home/user/.bashrc`. `node-tar` would only strip a single path root from such paths. When given an absolute file path with repeating path roots, the resulting path (e.g. `///home/user/.bashrc`) would still resolve to an absolute path, thus allowing arbitrary file creation and overwrite. 

### Patches

3.2.2 || 4.4.14 || 5.0.6 || 6.1.1

NOTE: an adjacent issue [CVE-2021-32803](https://github.com/npm/node-tar/security/advisories/GHSA-r628-mhmh-qjhw) affects this release level. Please ensure you update to the latest patch levels that address CVE-2021-32803 as well if this adjacent issue affects your `node-tar` use case.

### Workarounds

Users may work around this vulnerability without upgrading by creating a custom `onentry` method which sanitizes the `entry.path` or a `filter` method which removes entries with absolute paths.

```js
const path = require('path')
const tar = require('tar')

tar.x({
  file: 'archive.tgz',
  // either add this function...
  onentry: (entry) => {
    if (path.isAbsolute(entry.path)) {
      entry.path = sanitizeAbsolutePathSomehow(entry.path)
      entry.absolute = path.resolve(entry.path)
    }
  },

  // or this one
  filter: (file, entry) => {
    if (path.isAbsolute(entry.path)) {
      return false
    } else {
      return true
    }
  }
})
```

Users are encouraged to upgrade to the latest patch versions, rather than attempt to sanitize tar input themselves.
XStream is vulnerable to an Arbitrary Code Execution attack
Published: 2021-08-25T14:46:38Z
Aliases: CVE-2021-39154

### Impact
The vulnerability may allow a remote attacker to load and execute arbitrary code from a remote host only by manipulating the processed input stream. No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types.

### Patches
XStream 1.4.18 uses no longer a blacklist by default, since it cannot be secured for general purpose.

### Workarounds
See [workarounds](https://x-stream.github.io/security.html#workaround) for the different versions covering all CVEs.

### References
See full information about the nature of the vulnerability and the steps to reproduce it in XStream's documentation for [CVE-2021-39154](https://x-stream.github.io/CVE-2021-39154.html).

### Credits
ka1n4t found and reported the issue to XStream and provided the required information to reproduce it.

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [XStream](https://github.com/x-stream/xstream/issues)
* Contact us at [XStream Google Group](https://groups.google.com/group/xstream-user)
Memory corruption in array-tools
Published: 2021-08-25T20:57:19Z
Aliases: CVE-2020-36452

An issue was discovered in the array-tools crate before 0.3.2 for Rust. Affected versions of this crate don't guard against panics, so that partially uninitialized buffer is dropped when user-provided `T::clone()` panics in `FixedCapacityDequeLike<T, A>::clone()`. This causes memory corruption.
Improper Restriction of Rendered UI Layers or Frames in yourls
Published: 2021-08-30T16:22:16Z
Aliases: CVE-2021-3734

yourls is vulnerable to Improper Restriction of Rendered UI Layers or Frames
PHP file inclusion via insert tags
Published: 2021-08-23T19:41:04Z
Aliases: CVE-2021-37626

### Impact

It is possible for untrusted users to load arbitrary PHP files via insert tags.

Installations are only affected if there are untrusted back end users.

### Patches

Update to Contao 4.4.56, 4.9.18 or 4.11.7.

### Workarounds

Disable the login for untrusted back end users.

### References

https://contao.org/en/security-advisories/php-file-inclusion-via-insert-tags

### For more information

If you have any questions or comments about this advisory, open an issue in [contao/contao](https://github.com/contao/contao/issues/new/choose).
Missing release of memory in sized-chunks
Published: 2021-08-25T20:45:01Z
Aliases: CVE-2020-25795

Chunk:

* Array size is not checked when constructed with unit() and pair().
* Array size is not checked when constructed with From<InlineArray<A, T>>.
* Clone and insert_from are not panic-safe; A panicking iterator causes memory safety issues with them.

InlineArray:

* Generates unaligned references for types with a large alignment requirement.
FPE in `tf.raw_ops.UnravelIndex`
Published: 2021-08-25T14:42:06Z
Aliases: CVE-2021-37668

### Impact
An attacker can cause denial of service in applications serving models using `tf.raw_ops.UnravelIndex` by triggering a division by 0:

```python
import tensorflow as tf

tf.raw_ops.UnravelIndex(indices=-1, dims=[1,0,2])
```
  
The [implementation](https://github.com/tensorflow/tensorflow/blob/460e000de3a83278fb00b61a16d161b1964f15f4/tensorflow/core/kernels/unravel_index_op.cc#L36) does not check that the tensor subsumed by `dims` is not empty. Hence, if one element of `dims` is 0, the implementation does a division by 0.

### Patches
We have patched the issue in GitHub commit [a776040a5e7ebf76eeb7eb923bf1ae417dd4d233](https://github.com/tensorflow/tensorflow/commit/a776040a5e7ebf76eeb7eb923bf1ae417dd4d233).

The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.
  
### For more information
Please consult [our security guide](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions.

### Attribution
This vulnerability has been reported by members of the Aivul Team from Qihoo 360.
Data races in multiqueue2
Published: 2021-08-25T20:51:54Z
Aliases: CVE-2020-36214

Affected versions of this crate unconditionally implemented Send for types used in queue implementations (InnerSend<RW, T>, InnerRecv<RW, T>, FutInnerSend<RW, T>, FutInnerRecv<RW, T>).

This allows users to send non-Send types to other threads, which can lead to data race bugs or other undefined behavior.

The flaw was corrected in v0.1.7 by adding T: Send bound to to the Send impl of four data types explained above.
Infinite loop in TFLite
Published: 2021-08-25T14:39:58Z
Aliases: CVE-2021-37686

### Impact
The strided slice implementation in TFLite has a logic bug which can allow an attacker to trigger an infinite loop. This arises from newly introduced support for [ellipsis in axis definition](https://github.com/tensorflow/tensorflow/blob/149562d49faa709ea80df1d99fc41d005b81082a/tensorflow/lite/kernels/strided_slice.cc#L103-L122):

```cc
  for (int i = 0; i < effective_dims;) {
    if ((1 << i) & op_context->params->ellipsis_mask) {
      // ...
      int ellipsis_end_idx =
          std::min(i + 1 + num_add_axis + op_context->input_dims - begin_count,
                   effective_dims);
      // ...
      for (; i < ellipsis_end_idx; ++i) {
        // ...
      }
      continue;
    }
    // ...
    ++i;
  }
```

An attacker can craft a model such that `ellipsis_end_idx` is smaller than `i` (e.g., always negative). In this case, the inner loop does not increase `i` and the `continue` statement causes execution to skip over the preincrement at the end of the outer loop.

### Patches
We have patched the issue in GitHub commit [dfa22b348b70bb89d6d6ec0ff53973bacb4f4695](https://github.com/tensorflow/tensorflow/commit/dfa22b348b70bb89d6d6ec0ff53973bacb4f4695).

The fix will be included in TensorFlow 2.6.0. This is the only affected version.

### For more information
Please consult [our security guide](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions.

### Attribution
This vulnerability has been reported by members of the Aivul Team from Qihoo 360.
Double free in arenavec
Published: 2021-08-25T20:55:04Z
Aliases: CVE-2021-29931

Affected versions of this crate did not guard against potential panics that may happen from user-provided functions T::default() and T::drop().

Panic within T::default() leads to dropping uninitialized T, when it is invoked from common::Slice::<T, H>::new(). Panic within T::drop() leads to double drop of T, when it is invoked either from common::SliceVec::<T, H>::resize_with() or common::SliceVec::<T, H>::resize()

Either case causes memory corruption in the heap memory.