#linux

Chainguard provides DevSecOps teams with a library of "secure-by-default" container images so that they don't have to worry about software supply chain vulnerabilities. The startup is expanding its focus to include Java and Linux, as well.

A newly disclosed set of security flaws in NVIDIA's Triton Inference Server for Windows and Linux, an open-source platform for running artificial intelligence (AI) models at scale, could be exploited to take over susceptible servers. "When chained together, these flaws can potentially allow a remote, unauthenticated attacker to gain complete control of the server, achieving remote code execution

Cybersecurity researchers have flagged a previously undocumented Linux backdoor dubbed Plague that has managed to evade detection for a year. "The implant is built as a malicious PAM (Pluggable Authentication Module), enabling attackers to silently bypass system authentication and gain persistent SSH access," Nextron Systems researcher Pierre-Henri Pezier said. Pluggable Authentication Modules

### Summary Nested imports of MaterialX files can lead to a crash via stack memory exhaustion, due to the lack of a limit on the "import chain" depth. ### Details The MaterialX [specification](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/documents/Specification/MaterialX.Specification.md#mtlx-file-format-definition) supports importing other files by using `XInclude` tags. When parsing file imports, recursion is used to process nested files in the form of a tree with the root node being the first MaterialX files parsed. However, there is no limit imposed to the depth of files that can be parsed by the library, therefore, by building a sufficiently deep chain of MaterialX files one referencing the next, it is possible to crash the process using the MaterialX library via stack exhaustion. ### PoC This test is going to employ Windows UNC paths, in order to make the Proof Of Concept more realistic. In fact, by using windows network shares, an attacker would be able t...

### Summary The OpenEXR file format defines many information about the final image inside of the file header, such as the size of data/display window. The application trusts the value of `dataWindow` size provided in the header of the input file, and performs computations based on this value. This may result in unintended behaviors, such as excessively large number of iterations and/or huge memory allocations. ### Details A concrete example of this issue is present in the function `readScanline()` in `ImfCheckFile.cpp` at line 235, that performs a for-loop using the `dataWindow min.y` and `max.y` coordinates that can be arbitrarily large. ```cpp in.setFrameBuffer (i); int step = 1; // // try reading scanlines. Continue reading scanlines // even if an exception is encountered // for (int y = dw.min.y; y <= dw.max.y; y += step) // <-- THIS LOOP IS EXCESSIVE BECAUSE OF DW.MAX { try { in.readPixels (y); } catch (...) { threw = true; // ...

### Summary When reading a deep scanline image with a large sample count in `reduceMemory` mode, it is possible to crash a target application with a NULL pointer dereference in a write operation. ### Details In the `ScanLineProcess::run_fill` function, implemented in `src/lib/OpenEXR/ImfDeepScanLineInputFile.cpp`, the following code is used to write the `fillValue` in the sample buffer: ```cpp switch (fills.type) { case OPENEXR_IMF_INTERNAL_NAMESPACE::UINT: { unsigned int fillVal = (unsigned int) (fills.fillValue); unsigned int* fillptr = static_cast<unsigned int*> (dest); for ( int32_t s = 0; s < samps; ++s ) fillptr[s] = fillVal; // <--- POTENTIAL CRASH HERE break; } ``` However, when `reduceMemory` mode is enabled in the `readDeepScanLine` function in `src/lib/Open...

### Summary The OpenEXRCore code is vulnerable to a heap-based buffer overflow during a read operation due to bad pointer math when decompressing DWAA-packed scan-line EXR files with a maliciously forged chunk. ### Details In the `LossyDctDecoder_execute` function (from `src/lib/OpenEXRCore/internal_dwa_decoder.h`, when SSE2 is enabled), the following code is used to copy data from the chunks: ```cpp // no-op conversion to linear for (int y = 8 * blocky; y < 8 * blocky + maxY; ++y) { __m128i* restrict dst = (__m128i *) chanData[comp]->_rows[y]; __m128i const * restrict src = (__m128i const *)&rowBlock[comp][(y & 0x7) * 8]; for (int blockx = 0; blockx < numFullBlocksX; ++blockx) { _mm_storeu_si128 (dst, _mm_loadu_si128 (src)); // src += 8 * 8; // <--- si128 pointer incremented as a uint16_t dst += 8; } } ``` The issue arises because the `src` pointer, which is a `si128` pointer, is incremented by `8*8`, as if it were a `uint16_t` pointer...

### Summary The OpenEXRCore code is vulnerable to a heap-based buffer overflow during a write operation when decompressing ZIPS-packed deep scan-line EXR files with a maliciously forged chunk header. ### Details When parsing `STORAGE_DEEP_SCANLINE` chunks from an EXR file, the following code (from `src/lib/OpenEXRCore/chunk.c`) is used to extract the chunk information: ```cpp if (part->storage_mode == EXR_STORAGE_DEEP_SCANLINE) // SNIP... cinfo->sample_count_data_offset = dataoff; cinfo->sample_count_table_size = (uint64_t) ddata[0]; cinfo->data_offset = dataoff + (uint64_t) ddata[0]; cinfo->packed_size = (uint64_t) ddata[1]; cinfo->unpacked_size = (uint64_t) ddata[2]; // SNIP... ``` By storing this information, the code that will later decompress and reconstruct the chunk bytes, will know how much space the uncompressed data will occupy. This size is carried along in the chain of decoding/decompression...

The EVE X1 server suffers from an unauthenticated OS command injection vulnerability. This can be exploited to inject and execute arbitrary shell commands through the 'passwd' HTTP POST parameter in /ajax/php/login.php script.

The controller suffers from an unauthenticated file disclosure vulnerability. Using the 'db_log' POST parameter, attackers can disclose arbitrary files on the affected device and disclose sensitive and system information.