An issue was discovered in the Linux kernel before 5.7.3, related to mm/gup.c and mm/huge_memory.c. The get_user_pages (aka gup) implementation, when used for a copy-on-write page, does not properly consider the semantics of read operations and therefore can grant unintended write access, aka CID-17839856fd58.

CVE-2020-29374

IBM Power9 (AIX 7.1, 7.2, and VIOS 3.1) processors could allow a local user to obtain sensitive information from the data in the L1 cache under extenuating circumstances. IBM X-Force ID: 189296.

CVE-2020-4788: IBM AIX and VIOS information disclosure CVE-2020-4788 Vulnerability Report

Improper input validation in the Auto-Discovery component of Nagios XI before 5.7.5 allows an authenticated attacker to execute remote code.

CVE-2020-28648: Nagios XI Change Log - Nagios

A heap overflow vulnerability exists in Pixar OpenUSD 20.05 when the software parses compressed sections in binary USD files. To trigger this vulnerability, the victim needs to open an attacker-provided malformed file in an instance USDC file format path element token index.

CVE-2020-6147, CVE-2020-6148, CVE-2020-6149, CVE-2020-6150, CVE-2020-6156, CVE-2020-13493

**Summary**

A heap overflow vulnerability exists in Pixar OpenUSD 20.05 when the software parses compressed sections in binary USD files. A specially crafted malformed file can trigger a heap overflow which can result in remote code execution. To trigger this vulnerability, the victim needs to open an attacker-provided malformed file.

**Tested Versions**

Pixar OpenUSD 20.05  
Apple macOS Catalina 10.15.3

**Product URLs**

https://openusd.org

**CVSSv3 Score**

8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

**CWE**

CWE-122 - Heap-based Buffer Overflow

**Details**

OpenUSD stands for “Open Universal Scene Descriptor” and is a software suite by Pixar that facilitates, among other things, the interchange of arbitrary 3-D scenes that may be composed of many elemental assets.

Most notably, USD and its backing file format usd are used on Apple iOS and macOS as part of the ModelIO framework in support of SceneKit and ARKit for sharing and displaying 3-D scenes in, for example, augmented reality applications. On macOS, these files are automatically rendered to generate thumbnails, while on iOS they can be shared via iMessage and opened with user interaction.

USD binary file format consists of a header pointing to a table of contents that in turn points to individual sections that comprise the whole file. Format specifies that if the format version is 4 or higher, sections content is compressed. Four instances of a heap overflow vulnerability exist in a way USD processes compressed data of specific sections. These are FIELDS,FIELDSETS, PATHS and SPECS.

**CVE-2020-6147 - USDC file format FIELDS section decompression heap overflow**

Following code is responsible for decoding the FIELDS section data (from pxr/usd/usd/crateFile.cpp):

    if (auto fieldsSection = _toc.GetSection(_FieldsSectionName)) {
        reader.Seek(fieldsSection->start);                              [1]
        if (Version(_boot) < Version(0,4,0)) {                          [2]
            _fields = reader.template Read<decltype(_fields)>();
        } else {
            // Compressed fields in 0.4.0.
            auto numFields = reader.template Read<uint64_t>();          [3]
            _fields.resize(numFields);
    
            // Create temporary space for decompressing.
            std::unique_ptr<char[]> compBuffer(
                new char[Usd_IntegerCompression::
                         GetCompressedBufferSize(numFields)]);          [4]
            vector<uint32_t> tmp(numFields);
            auto fieldsSize = reader.template Read<uint64_t>();         [5]
            reader.ReadContiguous(compBuffer.get(), fieldsSize);        [6]
    

In the above code, parser navigates to the beginning of the FIELDS section at \[1\]. If version check at \[2\] resolves that compressed fields are used, a 64 bit value of numFields is read at \[3\] and is subsequently used to calculate the size of the buffer at \[4\]. Another 64 bit value , fieldSize is read at \[5\] which is subsequently used to initiate a buffer read at \[6\]. Data from the file is read into buffer that is sized based on numFields, but is bounded by fieldsSize. Both values are under direct control and no check is performed to insure fieldsSize bytes can fit into the allocated buffer. This can result in buffer overflow on the heap.

**CVE-2020-6148 - USDC file format FIELDSETS section decompression heap overflow**

Following code is responsible for decoding the FIELDSETS section data (from pxr/usd/usd/crateFile.cpp):

    // Compressed fieldSets in 0.4.0.
    auto numFieldSets = reader.template Read<uint64_t>();           [7]
    _fieldSets.resize(numFieldSets);
    
    // Create temporary space for decompressing.
    std::unique_ptr<char[]> compBuffer(
        new char[Usd_IntegerCompression::
                 GetCompressedBufferSize(numFieldSets)]);           [8]
    vector<uint32_t> tmp(numFieldSets);
    std::unique_ptr<char[]> workingSpace(
        new char[Usd_IntegerCompression::
                 GetDecompressionWorkingSpaceSize(numFieldSets)]);
    
    auto fsetsSize = reader.template Read<uint64_t>();              [9]
    reader.ReadContiguous(compBuffer.get(), fsetsSize);             [10]
    

Like in the previous vulnerability, parsing the FIELDSETS section starts with reading numFiledSets at \[7\] which is used to allocate a properly sized buffer at \[8\]. Then, fsetsSize 64 bit value is read at \[9\] and used as a read size argument to a file buffer read at \[10\]. Destination buffer size is calculated based on numFieldSets, but file read at \[10\] reads fsetsSize bytes. This constitutes an buffer overflow on the heap.

**CVE-2020-6149 - USDC file format PATHS section decompression heap overflow**

Following code is responsible for decoding the PATHS section data (from pxr/usd/usd/crateFile.cpp):

    _paths.resize(reader.template Read<uint64_t>());                    [11]
    std::fill(_paths.begin(), _paths.end(), SdfPath());
    
    WorkArenaDispatcher dispatcher;
    // VERSIONING: PathItemHeader changes size from 0.0.1 to 0.1.0.
    Version fileVer(_boot);
    if (fileVer == Version(0,0,1)) {  
        _ReadPathsImpl<_PathItemHeader_0_0_1>(reader, dispatcher);
    } else if (fileVer < Version(0,4,0)) {                             
        _ReadPathsImpl<_PathItemHeader>(reader, dispatcher);
    } else {                                                            [12]
        // 0.4.0 has compressed paths.
        _ReadCompressedPaths(reader, dispatcher);
    }
    

First, a 64 bit value of number of paths is read at \[11\] and a familiar file version check is performed. If the file version is 4 or higher, code at \[12\] proceeds to call _ReadCompressedPaths :

    size_t numPaths = reader.template Read<uint64_t>();                 [13]
    
    pathIndexes.resize(numPaths);
    elementTokenIndexes.resize(numPaths);
    jumps.resize(numPaths);
    
    // Create temporary space for decompressing.
    std::unique_ptr<char[]> compBuffer(
        new char[Usd_IntegerCompression::GetCompressedBufferSize(numPaths)]);      [14]
    std::unique_ptr<char[]> workingSpace(
        new char[Usd_IntegerCompression::
                 GetDecompressionWorkingSpaceSize(numPaths)]);
    
    // pathIndexes.
    auto pathIndexesSize = reader.template Read<uint64_t>();                [15]
    reader.ReadContiguous(compBuffer.get(), pathIndexesSize);               [16]
    

Again, a 64 bit value of numPaths is read into a size_t typed variable at \[13\] and is then used to calculate the size of buffer allocation at \[14\]. Another 64 bit value of pathIndexesSize is read at \[15\] and is subsequently used as a buffer read size value at \[16\]. Since the destination buffer size is based on numPaths value, but file read size on pathIndexesSize, buffer can be made too small to fit the whole read which will result in a buffer overflow on the heap.

**CVE-2020-6150 - USDC file format SPECS section decompression heap overflow**

Following code is responsible for decoding the SPECS section data (from pxr/usd/usd/crateFile.cpp):

    // Version 0.4.0 specs are compressed
    auto numSpecs = reader.template Read<uint64_t>();               [17]
    _specs.resize(numSpecs);
    
    // Create temporary space for decompressing.
    std::unique_ptr<char[]> compBuffer(
        new char[Usd_IntegerCompression::
                 GetCompressedBufferSize(numSpecs)]);               [18]
    vector<uint32_t> tmp(_specs.size());
    std::unique_ptr<char[]> workingSpace(
        new char[Usd_IntegerCompression::
                 GetDecompressionWorkingSpaceSize(numSpecs)]);
    
    // pathIndexes.
    auto pathIndexesSize = reader.template Read<uint64_t>();        [19]
    reader.ReadContiguous(compBuffer.get(), pathIndexesSize);       [20]
    

As with previous vulnerabilities, a 64 bit value is read into numSpecs at \[17\] which is used to calculate the size of the buffer at \[18\]. Actual size of the section data is read at \[19\] into a 64 bit value pathIndexesSize. Notice the reuse of variable name, indicating code copy/pasting. This size value is used as a file read size at \[20\] and can result in a heap based buffer overflow if buffer allocated at \[18\] is too small.

**CVE-2020-6156 - USDC file format path element token index decompression heap overflow**

Section PATHS in the USDC binary file contains three arrays, each encoding parts of a path value. Similarly to already reported CVE-2020-6149, a heap buffer overflow vulnerability exists in a way compressed path elements are processed. Following code is invoked :

    // Read number of encoded paths.
    size_t numPaths = reader.template Read<uint64_t>();                              [1]
    
    pathIndexes.resize(numPaths);
    elementTokenIndexes.resize(numPaths);
    jumps.resize(numPaths);
    
    // Create temporary space for decompressing.
    std::unique_ptr<char[]> compBuffer(
        new char[Usd_IntegerCompression::GetCompressedBufferSize(numPaths)]);        [2]
    std::unique_ptr<char[]> workingSpace(
        new char[Usd_IntegerCompression::
                 GetDecompressionWorkingSpaceSize(numPaths)]);
    
    // pathIndexes.
    auto pathIndexesSize = reader.template Read<uint64_t>();
    reader.ReadContiguous(compBuffer.get(), pathIndexesSize);                                               
    Usd_IntegerCompression::DecompressFromBuffer(
        compBuffer.get(), pathIndexesSize, pathIndexes.data(), numPaths,
        workingSpace.get());
    
    // elementTokenIndexes.
    auto elementTokenIndexesSize = reader.template Read<uint64_t>();                  [3]
    reader.ReadContiguous(compBuffer.get(), elementTokenIndexesSize);                 [4]
    Usd_IntegerCompression::DecompressFromBuffer(
        compBuffer.get(), elementTokenIndexesSize,
        elementTokenIndexes.data(), numPaths, workingSpace.get());
    

First, at \[1\] , a total number of paths to be reconstructed is read. This value is used to calculate the size of compressed buffer at \[2\]. Then, at \[3\] , a compressed size of element token indices is read at \[3\] and a large buffer read at \[4\]. Notice that while the compBuffer is sized based on value read from \[1\], the value in elementTokenIndexSize is used as a read size argument. Both of these value come directly frome the file and, if mismatched, can result in a heap buffer overflow where both allocation and overflow size , as well as overflow contents are under direct control.

**CVE-2020-13493 - USDC file format path jumps decompression heap overflow**

Similarly to above, a heap buffer overflow vulnerability exists in a way path jumps are processed. Following code is invoked right after the previously discussed:

    // jumps.
    auto jumpsSize = reader.template Read<uint64_t>();                                               [5]
    reader.ReadContiguous(compBuffer.get(), jumpsSize);                                           [6]
    Usd_IntegerCompression::DecompressFromBuffer(
        compBuffer.get(), jumpsSize, jumps.data(), numPaths,
        workingSpace.get());
    

As in the previous case, destination buffer compBuffer size is calculated based on calculation at \[2\], but a second value read at \[5\] is used as a size argument to a ReadContiguous call at \[6\]. If the allocated buffer is smaller than the size read at \[6\], this will lead to a heap based buffer overflow.

In this case , the potential attacker controls both the size of allocated memory buffer, the size of the overflow as well as all the data of the overflow which comes directly from the file being read. With proper memory manipulation and control, this can lead to arbitrary code execution.

**Crash Information**

Including crash context for only one instance of the vulnerability. Tested on latest version of macOS Catalina 10.15.3.

        thread #2, queue = 'com.apple.quicklook.thumbnailservicecontext.thumbnailgeneration', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
              frame #0: 0x00007fff6f4f0930 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 496
                frame #1: 0x00007fff3ded2644 ModelIO`___lldb_unnamed_symbol96151$$ModelIO + 158
                frame #2: 0x00007fff3ded1d67 ModelIO`___lldb_unnamed_symbol96148$$ModelIO + 341
                frame #3: 0x00007fff3debf7ef ModelIO`___lldb_unnamed_symbol95659$$ModelIO + 867
                frame #4: 0x00007fff3debf273 ModelIO`___lldb_unnamed_symbol95658$$ModelIO + 517
                frame #5: 0x00007fff3debee89 ModelIO`___lldb_unnamed_symbol95657$$ModelIO + 417
                frame #6: 0x00007fff3debe40d ModelIO`___lldb_unnamed_symbol95646$$ModelIO + 599
                frame #7: 0x00007fff3dfc558d ModelIO`___lldb_unnamed_symbol101370$$ModelIO + 261
                frame #8: 0x00007fff3df7177e ModelIO`___lldb_unnamed_symbol100320$$ModelIO + 258
                frame #9: 0x00007fff3d95c195 ModelIO`___lldb_unnamed_symbol34985$$ModelIO + 1221
                frame #10: 0x00007fff3d95b321 ModelIO`___lldb_unnamed_symbol34982$$ModelIO + 2545
                frame #11: 0x00007fff3d95a593 ModelIO`___lldb_unnamed_symbol34979$$ModelIO + 867
                frame #12: 0x00007fff3df85979 ModelIO`___lldb_unnamed_symbol100531$$ModelIO + 209
                frame #13: 0x00007fff3df85ae0 ModelIO`___lldb_unnamed_symbol100532$$ModelIO + 200
                frame #14: 0x00007fff3d61231a ModelIO`___lldb_unnamed_symbol2606$$ModelIO + 386
                frame #15: 0x00007fff3d592ed6 ModelIO`___lldb_unnamed_symbol670$$ModelIO + 794
                frame #16: 0x00007fff3d592b17 ModelIO`___lldb_unnamed_symbol669$$ModelIO + 97
                frame #17: 0x00007fff43f488d4 SceneKit`loadMDLAssetWithURL + 113
                frame #18: 0x00007fff43dbe878 SceneKit`-[SCNSceneSource _createSceneRefWithOptions:statusHandler:] + 788
                frame #19: 0x00007fff43dbe4a5 SceneKit`-[SCNSceneSource _sceneWithClass:options:statusHandler:] + 1525
                frame #20: 0x00007fff43dbdcd6 SceneKit`-[SCNSceneSource sceneWithClass:options:statusHandler:] + 117
                frame #21: 0x00007fff43dbdc45 SceneKit`-[SCNSceneSource sceneWithClass:options:error:] + 88
                frame #22: 0x0000000102ab25c9 SceneKitQLThumbnailExtension`___lldb_unnamed_symbol1$$SceneKitQLThumbnailExtension + 414
                frame #23: 0x00007fff438e8fb2 QuickLookThumbnailing`__145-[QLThumbnailServiceContext generateThumbnailOfSize:minimumSize:scale:badgeType:withFileURLHandler:additionalResourcesWrapper:completionHandler:]_block_invoke + 432
                frame #24: 0x00007fff6f2a0583 libdispatch.dylib`_dispatch_call_block_and_release + 12
    
            Nearby code:
            libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell:
            ->  0x7fff6f4f0930 <+496>: c5 fc 10 46 e0     vmovups ymm0, ymmword ptr [rsi - 0x20]
                0x7fff6f4f0935 <+501>: 49 89 fb           mov    r11, rdi
                0x7fff6f4f0938 <+504>: 48 83 ef 01        sub    rdi, 0x1
                0x7fff6f4f093c <+508>: 48 83 e7 e0        and    rdi, -0x20
                0x7fff6f4f0940 <+512>: 4c 89 d9           mov    rcx, r11
                0x7fff6f4f0943 <+515>: 48 29 f9           sub    rcx, rdi
                0x7fff6f4f0946 <+518>: 48 29 ce           sub    rsi, rcx
                0x7fff6f4f0949 <+521>: 48 29 ca           sub    rdx, rcx
                0x7fff6f4f094c <+524>: c5 fc 10 4e e0     vmovups ymm1, ymmword ptr [rsi - 0x20]
                0x7fff6f4f0951 <+529>: c4 c1 7c 11 43 e0  vmovups ymmword ptr [r11 - 0x20], ymm0
    
                rax = 0x00007ffa0b55eb10
                rbx = 0x0000000000000000
                rcx = 0x4141414141414141
                rdx = 0x4141414141414141
                rsi = 0x414141424400d36f
                rdi = 0x4141c13b4c972c51
                 r8 = 0x4141414141414141
                 r9 = 0x0000000000000000
                r10 = 0x00000000fffbffff
                r11 = 0x00007ff9089658e2
                r12 = 0x0000700008c499a8
                r13 = 0x0000700008c499a8
                r14 = 0x4141414141414141
                r15 = 0x00007ffa0b55eb10
                rsp = 0x0000700008c498e0
                rbp = 0x0000700008c498e0
                rip = 0x00007fff6f4f0930 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 496
                fla = o d I t s z a p c
    

**Timeline**

2020-07-01 - Vendor Disclosure to Pixar & Apple

2020-11-12 - Public Release

Discovered by Aleksandar Nikolic of Cisco Talos.

CVE-2020-6156: TALOS-2020-1094 || Cisco Talos Intelligence Group

A heap overflow vulnerability exists in the Pixar OpenUSD 20.05 while parsing compressed value rep arrays in binary USD files. A specially crafted malformed file can trigger a heap overflow, which can result in remote code execution. To trigger this vulnerability, the victim needs to access an attacker-provided malformed file.

**Summary**

A heap overflow vulnerability exists in the Pixar OpenUSD 20.05 while parsing compressed value rep arrays in binary USD files. A specially crafted malformed file can trigger a heap overflow, which can result in remote code execution. To trigger this vulnerability, the victim needs to access an attacker-provided malformed file.

**Tested Versions**

Pixar OpenUSD 20.05  
Apple macOS Catalina 10.15.3

**Product URLs**

https://openusd.org

**CVSSv3 Score**

8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

**CWE**

CWE-122 - Heap-based Buffer Overflow

**Details**

OpenUSD stands for open Universal Scene Descriptor and is a software suite by Pixar that facilitates, among other things, interchange of arbitrary 3-D scenes that may be composed of many elemental assets.

Most notably, USD and its backing file format usd are used on Apple iOS and macOS as part of ModelIO framework in support of SceneKit and ARKit for sharing and displaying 3D scenes in, for example, augmented reality applications. On macOS, these files are automatically rendered to generate thumbnails, while on iOS they can be shared via iMessage and opened with user interaction.

The USD binary file format consists of a header pointing to a table of contents that, in turn, points to individual sections that comprise the whole file. Section FIELDS contains two arrays, the second one labeled as reps. Compressed in binary, this array holds an array of 64-bit integers which encode references to extra data. Encoding consists of three top bits specifying whether the value is inline, compressed or array. Inlined values are directly represented in the first 48 bits, otherwise those 48 bits represent an offset into the file where the actual value can be found. Besides three most significant bits, five are unused and next eight encode one of 54 different value types (ints, floats, matrices, vectors , special types…). Two distinct paths of triggering this heap overflow are present in the way referenced values are accessed and decoded.

When a value from reps array is referenced, if that particular value happens to be an array and is compressed, the following code is invoked for integer types:

    template <class Reader, class T>
    static inline
    typename std::enable_if<
        std::is_same<T, int>::value ||
        std::is_same<T, unsigned int>::value ||
        std::is_same<T, int64_t>::value ||
        std::is_same<T, uint64_t>::value>::type
    _ReadPossiblyCompressedArray(
        Reader reader, ValueRep rep, VtArray<T> *out, CrateFile::Version ver, int)
    {
        // Version 0.5.0 introduced compressed int arrays.
        if (ver < CrateFile::Version(0,5,0) || !rep.IsCompressed()) {
            _ReadUncompressedArray(reader, rep, out, ver);
        }
        else {
            // Read total elements.
                out->resize(ver < CrateFile::Version(0,7,0) ?                     [0]
                        reader.template Read<uint32_t>() :
                        reader.template Read<uint64_t>());
            if (out->size() < MinCompressedArraySize) {
                reader.ReadContiguous(out->data(), out->size());                                  
            } else {
                _ReadCompressedInts(reader, out->data(), out->size());            [1]
            }
        }
    }
    

At \[0\] above, depending on the file version type (greater than 5, but either less or more than 7) either a 32 bit or 64 bit integer size is read from the file. If the size is larger than a minimum compressed size this indicates that the data is indeed compressed so _readCompressedInts is invoked at \[1\]. Following the code:

    template <class Reader, class Int>
    static inline void
    _ReadCompressedInts(Reader reader, Int *out, size_t size)
    {
        using Compressor = typename std::conditional<
            sizeof(Int) == 4,
            Usd_IntegerCompression,
            Usd_IntegerCompression64>::type;
        std::unique_ptr<char[]> compBuffer(
            new char[Compressor::GetCompressedBufferSize(size)]);
                auto compSize = reader.template Read<uint64_t>();                         [3]
        reader.ReadContiguous(compBuffer.get(), compSize);                                [4]
            Compressor::DecompressFromBuffer(compBuffer.get(), compSize, out, size);   
    }
    

In the above code, at \[3\] another 64 bit size value is read from the file and is then directly used as a size of a read operation at \[4\]. Notice that the destination size buffer is allocated based on previously read argument from \[0\]. If the latter size value is bigger than the one calculated from the first, this will lead to a heap buffer overflow.

To trigger this vulnerability, first a specific reps entry needs to be placed in the reps array inside FIELDS section. Here is an example of such entry, decoded:

    580000000000 - offset into file where the value is encoded
    03 - type (int)
    a0 - flags (1010 0000 binary , is array, not inline, is compressed)
    

The specific referenced value to be placed at offset 0x58 into the file can be:

    44 00 00 00 00 00 00 00 - read as size value at [0]
    41 41 00 00 00 00 00 00 - read as size value at [3]
    00 00 00 00 00 00 00 00 - start of buffer
    00 00 00 00 00 00 00 00 - ...
    

Another path to this vulnerability lies in the way other types, like floats, are parsed. If the type specified in the encoded rep entry is 0x8 for float, instead of 0x3 for int, the following code is invoked:

    template <class Reader, class T>
    static inline
    typename std::enable_if<
        std::is_same<T, GfHalf>::value ||
        std::is_same<T, float>::value ||
        std::is_same<T, double>::value>::type
    _ReadPossiblyCompressedArray(
        Reader reader, ValueRep rep, VtArray<T> *out, CrateFile::Version ver, int)
    {
        // Version 0.6.0 introduced compressed floating point arrays.
        if (ver < CrateFile::Version(0,6,0) || !rep.IsCompressed()) {
            _ReadUncompressedArray(reader, rep, out, ver);
            return;
        }
    
        out->resize(ver < CrateFile::Version(0,7,0) ?                                     [4]
                    reader.template Read<uint32_t>() :
                    reader.template Read<uint64_t>());
        auto odata = out->data();
        auto osize = out->size();
    
        if (osize < MinCompressedArraySize) {
            // Not stored compressed.
            reader.ReadContiguous(odata, osize);
            return;
        }
    
        // Read the code
        char code = reader.template Read<int8_t>();
        if (code == 'i') {                                                                [5]
            // Compressed integers.
            vector<int32_t> ints(osize);
            _ReadCompressedInts(reader, ints.data(), ints.size());                        [6]
            std::copy(ints.begin(), ints.end(), odata);
        }
    

Similarly as before, a version check is performed at \[4\] and size is read. Additionally, a type of value is encoded by a char literal (either i or t) which is checked at \[5\]. If this literal is i, the same _ReadCompressedInts function is invoked which can lead to heap buffer overflow.

In this case, the potential attacker controls both the size of allocated memory buffer, the size of the overflow as well as all the data of the overflow which comes directly from the file being read. With proper memory manipulation and control, this can lead to arbitrary code execution.

**Timeline**

2020-07-01 - Vendor Disclosure

2020-07-14 - Talos tested and confirmed fix with latest beta of macOS Catalina 10.15.6  
2020-11-12 - Public Release

Discovered by Aleksandar Nikolic of Cisco Talos.

CVE-2020-6155: TALOS-2020-1101 || Cisco Talos Intelligence Group

Improper input validation in BIOS firmware for some Intel(R) Processors may allow an authenticated user to potentially enable escalation of privilege via local access.

**Select Your Region**

Sign In to access restricted content

**Using Intel.com Search**

You can easily search the entire Intel.com site in several ways.

*   Brand Name: **Core i9**
*   Document Number: **123456**
*   Code Name: **Alder Lake**
*   Special Operators: **“Ice Lake”, Ice AND Lake, Ice OR Lake, Ice\***

**Quick Links**

You can also try the quick links below to see results for most popular searches.

*   Product Information
*   Support
*   Drivers & Software

**Recent Searches**

Sign In to access restricted content

**Advanced Search**

**Only search in**

Title Description Content ID

Sign in to access restricted content.

The browser version you are using is not recommended for this site.  
Please consider upgrading to the latest version of your browser by clicking one of the following links.

*   Safari
*   Chrome
*   Edge
*   Firefox

**2020.2 IPU – BIOS Advisory**

Intel ID:

INTEL-SA-00358

Advisory Category:

Firmware

Impact of vulnerability:

Escalation of Privilege, Denial of Service

Severity rating:

HIGH

Original release:

11/10/2020

Last revised:

11/10/2020

**Summary: **

Potential security vulnerabilities in the BIOS firmware for some Intel® Processors may allow escalation of privilege or denial of service.  Intel is releasing firmware updates to mitigate this potential vulnerability.

**Vulnerability Details:**

CVEID:  CVE-2020-0590

Description: Improper input validation in BIOS firmware for some Intel(R) Processors may allow an authenticated user to potentially enable escalation of privilege via local access.

CVSS Base Score: 7.7 High

CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:L/I:H/A:H

CVEID:  CVE-2020-0587

Description: Improper conditions check in BIOS firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.

CVSS Base Score: 6.7 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:L/I:H/A:L

CVEID:  CVE-2020-0591

Description: Improper buffer restrictions in BIOS firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.

CVSS Base Score: 6.7 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

CVEID:  CVE-2020-0593

Description: Improper buffer restrictions in BIOS firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.

CVSS Base Score: 4.7 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:L

CVEID:  CVE-2020-0588

Description: Improper conditions check in BIOS firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.

CVSS Base Score: 3.8 Low

CVSS Vector: CVSS:3.1/AV:P/AC:H/PR:H/UI:R/S:U/C:N/I:H/A:N

CVEID:  CVE-2020-0592

Description: Out of bounds write in BIOS firmware for some Intel(R) Processors may allow an authenticated user to potentially enable escalation of privilege and/or denial of service via local access.

CVSS Base Score: 3.0 Low

CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:L

**Affected Products:**

2nd Generation Intel® Xeon® Scalable and Intel® Xeon® Scalable Processors

*   CVE-2020-0590
*   CVE-2020-0591
*   CVE-2020-0592
*   CVE-2020-0593
*   CVE-2020-0587
*   CVE-2020-0588

Intel® Xeon® Processor D Family,  Intel® Xeon® Processor E5 v4 Family and Intel® Xeon® Processor E5 v3 Family              

*   CVE-2020-0591
*   CVE-2020-0592

10th Generation Intel® Core™ processors, 9th Generation Intel® Core™ processors, 8th Generation Intel® Core™ processors, 7th Generation Intel® Core™ processors, 6th Generation Intel® Core™ processors and

Intel® Core™ Processors with Intel® Hybrid Technology  

*   CVE-2020-0593

Intel® Xeon® Processor E7 v4 Family and Intel® Xeon® Processor E7 v2 Family      

*   CVE-2020-0592

Intel® Core™ X-series Processors and Intel® Xeon® Processor W Family   

*   CVE-2020-0587
*   CVE-2020-0591
*   CVE-2020-0592
*   CVE-2020-0593

Intel® Xeon® Processor D Family, Intel® Xeon® W Processor and Intel® Core™ X-series Processors

*   CVE-2020-0591
*   CVE-2020-0592
*   CVE-2020-0593

**Recommendations:  
**

Intel recommends that users of the affected products update to the latest BIOS firmware provided by the system manufacturer that addresses these issues.

**Acknowledgements:**

These issues were found internally by Intel employees.  Intel would like to thank, Nagaraju N Kodalapura and Hareesh Khattri for CVE-2020-0590, Jorge E Gonzalez Diaz for CVE-2020-0588, Nicholas Armour for CVE-2020-0587, and Brent Holtsclaw for CVE-2020-0591 and CVE-2020-0591.

Intel, and nearly the entire technology industry, follows a disclosure practice called Coordinated Disclosure, under which a cybersecurity vulnerability is generally publicly disclosed only after mitigations are available.

**Revision History**

Revision

Date

Description

1.0

11/10/2020

Initial Release

1.1

03/15/2021

Updated affected products for CVE-2020-0591/0592

**Legal Notices and Disclaimers**

Intel provides these materials as-is, with no express or implied warranties.

All products, dates, and figures specified are preliminary based on current expectations, and are subject to change without notice.

Intel products and services described may contain design defects or errors known as errata, which may cause the product to deviate from published specifications. Current characterized errata are available on request.

Intel products that have met their End of Servicing Updates may no longer receive functional and security updates. For additional details on support and servicing, please see this help article. 

Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. No product or component can be absolutely secure. Check with your system manufacturer or retailer or learn more at http://intel.com.

Some results have been estimated or simulated using internal Intel analysis or architecture simulation or modeling, and provided to you for informational purposes. Any differences in your system hardware, software or configuration may affect your actual performance.

Intel and the Intel logo are trademarks of Intel Corporation or its subsidiaries in the United States and other countries.

\*Other names and brands may be claimed as the property of others.  

Copyright © Intel Corporation 2022

**Report a Vulnerability**

If you have information about a security issue or vulnerability with an **Intel branded product or technology**, please send an e-mail to secure@intel.com. Encrypt sensitive information using our PGP public key.

Please provide as much information as possible, including:

*   The products and versions affected
*   Detailed description of the vulnerability
*   Information on known exploits

A member of the Intel Product Security Team will review your e-mail and contact you to collaborate on resolving the issue. For more information on how Intel works to resolve security issues, see:

*   Vulnerability handling guidelines

For issues related to Intel's external web presence (Intel.com and related subdomains), please contact Intel's External Security Research team.

**Need product support?**

If you...

*   Have questions about the security features of an Intel product
*   Require technical support
*   Want product updates or patches

  
Please visit Support & Downloads.

*   Report a Vulnerability
*   Product Support

CVE-2020-0590: INTEL-SA-00358

Improper conditions check in Intel BIOS platform sample code for some Intel(R) Processors before may allow a privileged user to potentially enable escalation of privilege via local access.

**Select Your Region**

The browser version you are using is not recommended for this site.  
Please consider upgrading to the latest version of your browser by clicking one of the following links.

*   Safari
*   Chrome
*   Edge
*   Firefox

**Intel BIOS Platform Sample Code Advisory**

**Summary: **

Potential security vulnerabilities in Intel BIOS platform sample code for some Intel® Processors may allow escalation of privilege.  Intel is releasing BIOS platform sample code updates to mitigate these potential vulnerabilities.

**Vulnerability Details:**

CVEID: CVE-2020-8764

Description: Improper access control in BIOS firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.

CVSS Base Score: 8.2 High

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

CVEID: CVE-2020-8738

Description: Improper conditions check in Intel BIOS platform sample code for some Intel(R) Processors before may allow a privileged user to potentially enable escalation of privilege via local access.

CVSS Base Score: 7.5 High

CVSS Vector: CVSS:3.0/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H

CVEID: CVE-2020-8740

Description: Out of bounds write in Intel BIOS platform sample code for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.

CVSS Base Score: 6.7 Medium

CVSS Vector: CVSS:3.0/AV:L/AC:H/PR:H/UI:N/S:C/C:L/I:H/A:L

CVEID: CVE-2020-8739

Description: Use of potentially dangerous function in Intel BIOS platform sample code for some Intel(R) Processors may allow an authenticated user to potentially enable escalation of privilege via local access.

CVSS Base Score: 4.6 Medium

CVSS Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:C/C:N/I:L/A:L

**Affected Products:**

2nd Generation Intel® Xeon® Scalable Processors, Intel® Core™ X-series Processors, Intel® Xeon® Processor W Family and Intel® Xeon® Scalable Processors     

*   CVE-2020-8738
*   CVE-2020-8739
*   CVE-2020-8740
*   CVE-2020-8764

Intel® Xeon® Processor D Family, Intel® Xeon® Processor E7 v4 Family and Intel® Xeon® Processor E5 v3 Family, Intel® Xeon® Processor E5 v4 Family

*   CVE-2020-8738
*   CVE-2020-8740
*   CVE-2020-8764

Intel® Xeon® Processor D Family               

*   CVE-2020-8739
*   CVE-2020-8740
*   CVE-2020-8764

Intel® Xeon® Processor E7 v3 Family

*   CVE2020-8764

Intel® Atom® Processor C3XXX

*   CVE-2020-8738

Intel recommends that users of the affected products update to the latest BIOS firmware provided by the system manufacturer that addresses these issues.  

**Acknowledgements:**

Intel would like to thank Dmitry Frolov (CVE-2020-8738) for reporting this issue.

The following issues were found internally by Intel, CVE-2020-8739 and CVE-2020-8764.  Intel would like to thank Brent Holtsclaw for CVE-2020-8740.

Intel, and nearly the entire technology industry, follows a disclosure practice called Coordinated Disclosure, under which a cybersecurity vulnerability is generally publicly disclosed only after mitigations are available.

**Revision History**

Revision

Date

Description

1.0

11/10/2020

Initial Release

**Legal Notices and Disclaimers**

Intel provides these materials as-is, with no express or implied warranties.

All products, dates, and figures specified are preliminary based on current expectations, and are subject to change without notice.

Intel, processors, chipsets, and desktop boards may contain design defects or errors known as errata, which may cause the product to deviate from published specifications. Current characterized errata are available on request.

Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. No product or component can be absolutely secure. Check with your system manufacturer or retailer or learn more at https://intel.com.

Some results have been estimated or simulated using internal Intel analysis or architecture simulation or modeling, and provided to you for informational purposes. Any differences in your system hardware, software or configuration may affect your actual performance.

Intel and the Intel logo are trademarks of Intel Corporation in the United States and other countries.

\*Other names and brands may be claimed as the property of others.  
Copyright © Intel Corporation 2022

**Report a Vulnerability**

If you have information about a security issue or vulnerability with an **Intel branded product or technology**, please send an e-mail to secure@intel.com. Encrypt sensitive information using our PGP public key.

Please provide as much information as possible, including:

*   The products and versions affected
*   Detailed description of the vulnerability
*   Information on known exploits

A member of the Intel Product Security Team will review your e-mail and contact you to collaborate on resolving the issue. For more information on how Intel works to resolve security issues, see:

*   Vulnerability handling guidelines

For issues related to Intel's external web presence (Intel.com and related subdomains), please contact Intel's External Security Research team.

**Need product support?**

If you...

*   Have questions about the security features of an Intel product
*   Require technical support
*   Want product updates or patches

  
Please visit Support & Downloads.

*   Report a Vulnerability
*   Product Support

CVE-2020-8738: INTEL-SA-00390

Improper buffer restrictions in BIOS firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.

**Select Your Region**

The browser version you are using is not recommended for this site.  
Please consider upgrading to the latest version of your browser by clicking one of the following links.

*   Safari
*   Chrome
*   Edge
*   Firefox

**2020.2 IPU – BIOS Advisory**

Intel ID:

INTEL-SA-00358

Advisory Category:

Firmware

Impact of vulnerability:

Escalation of Privilege, Denial of Service

Severity rating:

HIGH

Original release:

11/10/2020

Last revised:

11/10/2020

**Summary: **

Potential security vulnerabilities in the BIOS firmware for some Intel® Processors may allow escalation of privilege or denial of service.  Intel is releasing firmware updates to mitigate this potential vulnerability.

**Vulnerability Details:**

CVEID:  CVE-2020-0590

Description: Improper input validation in BIOS firmware for some Intel(R) Processors may allow an authenticated user to potentially enable escalation of privilege via local access.

CVSS Base Score: 7.7 High

CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:L/I:H/A:H

CVEID:  CVE-2020-0587

Description: Improper conditions check in BIOS firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.

CVSS Base Score: 6.7 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:L/I:H/A:L

CVEID:  CVE-2020-0591

Description: Improper buffer restrictions in BIOS firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.

CVSS Base Score: 6.7 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

CVEID:  CVE-2020-0593

Description: Improper buffer restrictions in BIOS firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.

CVSS Base Score: 4.7 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:L

CVEID:  CVE-2020-0588

Description: Improper conditions check in BIOS firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.

CVSS Base Score: 3.8 Low

CVSS Vector: CVSS:3.1/AV:P/AC:H/PR:H/UI:R/S:U/C:N/I:H/A:N

CVEID:  CVE-2020-0592

Description: Out of bounds write in BIOS firmware for some Intel(R) Processors may allow an authenticated user to potentially enable escalation of privilege and/or denial of service via local access.

CVSS Base Score: 3.0 Low

CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:L

**Affected Products:**

2nd Generation Intel® Xeon® Scalable and Intel® Xeon® Scalable Processors

*   CVE-2020-0590
*   CVE-2020-0591
*   CVE-2020-0592
*   CVE-2020-0593
*   CVE-2020-0587
*   CVE-2020-0588

Intel® Xeon® Processor D Family,  Intel® Xeon® Processor E5 v4 Family and Intel® Xeon® Processor E5 v3 Family              

*   CVE-2020-0591
*   CVE-2020-0592

10th Generation Intel® Core™ processors, 9th Generation Intel® Core™ processors, 8th Generation Intel® Core™ processors, 7th Generation Intel® Core™ processors, 6th Generation Intel® Core™ processors and

Intel® Core™ Processors with Intel® Hybrid Technology  

*   CVE-2020-0593

Intel® Xeon® Processor E7 v4 Family and Intel® Xeon® Processor E7 v2 Family      

*   CVE-2020-0592

Intel® Core™ X-series Processors and Intel® Xeon® Processor W Family   

*   CVE-2020-0587
*   CVE-2020-0591
*   CVE-2020-0592
*   CVE-2020-0593

Intel® Xeon® Processor D Family, Intel® Xeon® W Processor and Intel® Core™ X-series Processors

*   CVE-2020-0591
*   CVE-2020-0592
*   CVE-2020-0593

**Recommendations:  
**

Intel recommends that users of the affected products update to the latest BIOS firmware provided by the system manufacturer that addresses these issues.

**Acknowledgements:**

These issues were found internally by Intel employees.  Intel would like to thank, Nagaraju N Kodalapura and Hareesh Khattri for CVE-2020-0590, Jorge E Gonzalez Diaz for CVE-2020-0588, Nicholas Armour for CVE-2020-0587, and Brent Holtsclaw for CVE-2020-0591 and CVE-2020-0591.

Intel, and nearly the entire technology industry, follows a disclosure practice called Coordinated Disclosure, under which a cybersecurity vulnerability is generally publicly disclosed only after mitigations are available.

**Revision History**

Revision

Date

Description

1.0

11/10/2020

Initial Release

1.1

03/15/2021

Updated affected products for CVE-2020-0591/0592

**Legal Notices and Disclaimers**

Intel provides these materials as-is, with no express or implied warranties.

All products, dates, and figures specified are preliminary based on current expectations, and are subject to change without notice.

Intel, processors, chipsets, and desktop boards may contain design defects or errors known as errata, which may cause the product to deviate from published specifications. Current characterized errata are available on request.

Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. No product or component can be absolutely secure. Check with your system manufacturer or retailer or learn more at https://intel.com.

Some results have been estimated or simulated using internal Intel analysis or architecture simulation or modeling, and provided to you for informational purposes. Any differences in your system hardware, software or configuration may affect your actual performance.

Intel and the Intel logo are trademarks of Intel Corporation in the United States and other countries.

\*Other names and brands may be claimed as the property of others.  
Copyright © Intel Corporation 2022

**Report a Vulnerability**

If you have information about a security issue or vulnerability with an **Intel branded product or technology**, please send an e-mail to secure@intel.com. Encrypt sensitive information using our PGP public key.

Please provide as much information as possible, including:

*   The products and versions affected
*   Detailed description of the vulnerability
*   Information on known exploits

A member of the Intel Product Security Team will review your e-mail and contact you to collaborate on resolving the issue. For more information on how Intel works to resolve security issues, see:

*   Vulnerability handling guidelines

For issues related to Intel's external web presence (Intel.com and related subdomains), please contact Intel's External Security Research team.

**Need product support?**

If you...

*   Have questions about the security features of an Intel product
*   Require technical support
*   Want product updates or patches

  
Please visit Support & Downloads.

*   Report a Vulnerability
*   Product Support

CVE-2020-0591: INTEL-SA-00358

Xen through 4.14.x allows guest OS administrators to obtain sensitive information (such as AES keys from outside the guest) via a side-channel attack on a power/energy monitoring interface, aka a "Platypus" attack. NOTE: there is only one logically independent fix: to change the access control for each such interface in Xen.

![](https://platypusattack.com/static/logo.svg)

**PLATYPUS**

With **PLATYPUS**, we present novel software-based **power side-channel attacks** on Intel server, desktop and laptop CPUs. We exploit the **unprivileged access** to the Intel RAPL interface exposing the processor's power consumption to **infer data** and **extract cryptographic keys**.

**PLATYPUS in Action**

**The Power Meter within the CPU. Intel RAPL.**

With classical power side-channel attacks, an adversary typically attaches an oscilloscope to monitor the energy consumption of a device. Since Intel Sandy Bridge CPUs, the Intel Running Average Power Limit (RAPL) interface allows **monitoring** and controlling the **power consumption** of the CPU and DRAM **in software**. Hence, the CPU basically comes with its own power meter. With the current implementation of the Linux driver, every **unprivileged user** has access to its measurements.

Luckily, the update interval of the RAPL interface is low compared to real oscilloscopes. The RAPL interface has a bandwidth of 20 kHz, whereas oscilloscopes are in the range of multiple GHz. Moreover, the values are filtered using a running average, making it harder to infer secrets.

![](https://platypusattack.com/static/oscilloscope-cpu.svg)

Intel RAPL integrates power meter capabilities in the CPU.

![](https://platypusattack.com/static/cpu-dark.svg)

PLATYPUS can recover cryptographic keys from Intel SGX and the kernel.

**PLATYPUS. Finding Secrets in the Dark.**

Platypuses are fascinating animals: While they are mammals, they also lay eggs, and males can **detect electrical signals** with their bill. Likewise to the Platypus that uses its ability to find food even in complete darkness, we **sense secrets** in the processor's energy measurements using Intel RAPL.

Using PLATYPUS, we demonstrate that we can observe variations in the power consumption to distinguish different instructions and different Hamming weights of operands and memory loads, allowing inference of loaded values. PLATYPUS can further infer **intra-cacheline control flow** of applications, **break KASLR**, **leak AES-NI keys** from Intel SGX enclaves and the Linux kernel, and establish a timing-independent covert channel.

With SGX, Intel released a security feature to create isolated environments, so-called enclaves, that are secure even if the **operating system is compromised**. In our work, we combine PLATYPUS with precise execution control of SGX-Step. As a result, we overcome the hurdle of the limited measuring capabilities of Intel RAPL by repeatedly executing single instructions inside the SGX enclave. Using this technique, we **recover RSA keys** processed by mbed TLS from an SGX enclave.

**Protecting against PLATYPUS. Fixing RAPL.**

On Linux, the powercap framework provides unprivileged access to the Intel RAPL counters. With a recent **security update**, this access is revoked, and an unprivileged attacker can not retrieve power measurements anymore.

However, this update does not protect against a privileged attacker, e.g., a compromised operating system targeting Intel SGX. To mitigate attacks in this scenario, Intel released **microcode updates** to affected processors. These updates ensure that the reported energy consumption hinders the ability to distinguish the same instructions with different data or operands if Intel SGX is enabled on the system.

Please make sure to **get the latest updates** for your operating system and BIOS.

![](https://platypusattack.com/static/cpu-shield.svg)

Update your system to protect against PLATYPUS.

![](https://platypusattack.com/static/discovery.svg)

**Who is behind PLATYPUS?**

**Questions & Answers**

Intel provides a list with all **affected products here**.

We disclosed the problem to AMD and ARM as well. However, currently, we are not aware of any official statement regarding affected products from these vendors.

With classical power side-channel attacks, an attacker typically has physical access to a victim device. Using an oscilloscope, the attacker monitors the energy consumption of the device. With interfaces like Intel RAPL, **physical access is not required** anymore as the measurements can be accessed directly from software. Previous work already showed limited information leakage caused by the Intel RAPL interface. Mantel et al. showed that it is possible to distinguish if different cryptographic keys have been processed by the CPU. Paiva et al. established a covert channel by modulating the energy consumption of the DRAM.

Our research shows that the Intel RAPL interface can be exploited in way more threatening scenarios. We show that in addition to distinguishing different keys, it is possible to **reconstruct entire cryptographic keys**. We demonstrate this by **recovering AES** keys from the **side-channel resilient AES-NI** implementation, as well as RSA keys from an Intel SGX enclave. In addition, we distinguish different Hamming weights of operands or memory loads, **threatening constant-time implementations of cryptographic algorithms**. To mitigate PLATYPUS, the unprivileged access to the energy consumption has been revoked with an update to the operating system. With Intel SGX, however, a compromised operating system is within the threat model, rendering this mitigation insufficient. Therefore, Intel released microcode updates that change the way the energy consumption is reported if Intel SGX is enabled on the system. Instead of actual energy measurements, it falls back to a model-based approach, such that same instructions with different data or operands can not be distinguished.

Within our research, we focused on Intel's RAPL implementation as the threat model of Intel SGX allows a privileged attacker to achieve a more precise execution control of the victim. However, starting with the Zen microarchitecture, **AMD CPUs also provide a RAPL interface** that even allows measuring the energy consumption per individual core. With Linux kernel 5.8, this interface also grants access to unprivileged applications, however, currently limited to AMD Rome CPUs.

Furthermore, other processor vendors like **ARM** and **NVIDIA** have on-board energy meters that can be used. **Marvell** and **Ampere** also provide kernel drivers to provide unprivileged access to hardware sensors. However, as we do not or have only limited access to these devices, we were not able to conduct any experiments on these devices.

On Linux, the _powercap_ framework provides unprivileged access to Intel RAPL **by default**. On Windows and macOS, the Intel Power Gadget needs to be installed. Therefore, the presented attacks exploiting the unprivileged access only work on Linux.

For a privileged attacker targeting Intel SGX, the operating system used does not matter.

Platypuses are fascinating animals: While they are mammals, they also lay eggs. They have a bill like a duck, a tail like a beaver and a fur like an otter. Males are venomous, but more importantly, they can **detect electrical signals** with their bill. Likewise to the Platypus that uses its ability to find food even in complete darkness, we **sense secrets** in the energy measurements of the processor using Intel RAPL.

In addition, PLATYPUS is an acronym for "**P**ower **L**eakage **A**ttacks: **T**argeting **Y**our **P**rotected **U**ser **S**ecrets".

As the Linux driver provides unrestricited access to the Intel RAPL interface, a **security update** makes this access privileged.

However, in a setting where the victim is an Intel SGX enclave, this patch does not prevent a compromised operating system from accessing the Intel RAPL counters directly. Therefore, Intel **released microcode updates** that change the way the energy consumption is reported if Intel SGX is enabled on the system. Instead of actual energy measurements, it falls back to a model-based approach, such that same instructions with different data or operands can not be distinguished. Thus, if the enclave follows the Intel guide lines and uses constant-time cryptographic implementations, an adversary should not be able to recover any secrets of the enclave.

Yes, there is an **academic research paper** that can be downloaded here.

Additionally, **Intel** released a Security Advisory that can be accessed here. **XEN**'s security advisory can be accssed here.

Intel Software Guard eXtensions (SGX) is an innovative processor technology released in 2015 to create isolated environments in the computer's memory, so-called enclaves. SGX acts like a **secure vault in the processor** itself, combining strong encryption and hardware-level isolation to safeguard enclave programs, and the data they operate on, even against very advanced types of malware that compromise the operating system, hypervisor, or firmware (BIOS).

CVE-2020-8694 and CVE-2020-8695 are the **official references** to PLATYPUS. CVE is the Standard for Information Security Vulnerability Names maintained by MITRE.

The logo is free to use, rights waived via CC0. Logo designed by Natascha Eibl.

SVG

PNG

Logo (Color)

Logo (Outline, black)

Logo (Outline, white)

**Acknowledgements**

The research presented in this paper was supported by the Austrian Research Promotion Agency (FFG) via the K-project DeSSnet, which is funded in the context of COMET - Competence Centers for Excellent Technologies by BMVIT, BMWFW, Styria, and Carinthia. It was also supported by the European Research Council (ERC) under the European Union's Horizon 2020 research and innovation programme (grant agreement No 681402). It has also been supported by the Austrian Research Promotion Agency (FFG) via the project ESPRESSO, which is funded by the province of Styria and the Business Promotion Agencies of Styria and Carinthia. It is partially funded by the Engineering and Physical Sciences Research Council (EPSRC) under grants EP/R012598/1, EP/S030867/1 and by the European Union's Horizon 2020 research and innovation programme under grant agreement No. 779391 (FutureTPM). Additional funding was provided by generous gifts from Intel, ARM, Amazon and Red Hat. Further, we would like to thank Equinix Metal for providing us access to bare metal instances to run our experiments.

CVE-2020-28368: With Great Power comes Great Leakage

Axios NPM package 0.21.0 contains a Server-Side Request Forgery (SSRF) vulnerability where an attacker is able to bypass a proxy by providing a URL that responds with a redirect to a restricted host or IP address.

**Describe the bug**

In cases where axios is used by servers to perform http requests to user-supplied urls, a proxy is commonly used to protect internal networks from unauthorized access and SSRF. This bug enables an attacker to bypass the proxy by providing a url that responds with a redirect to a restricted host/ip.

**To Reproduce**

The following code spawns a proxy server that _always_ responds with a 302 redirect, so requests should never reach the target url, however, axios is only reaching the proxy once, and bypassing the proxy after the redirect response.

https://runkit.com/embed/1df5qy8lbgnc

const axios \= require('axios')
const http \= require('http')

const PROXY\_PORT \= 8080

// A fake proxy server
http.createServer(function (req, res) { 
    res.writeHead(302, {location: 'http://example.com'})
    res.end()
  }).listen(PROXY\_PORT)

axios({
  method: "get",
  url: "http://www.google.com/",
  proxy: {
    host: "localhost",
    port: PROXY\_PORT,
  },
})
.then((r) \=> console.log(r.data))
.catch(console.error)

The response is the rendered html of _http://example.com_

**Expected behavior**

_All_ the requests should pass via the proxy. In the provided scenario, there should be a redirect loop.

**Environment**

*   Axios Version \[0.21.0\]
*   Node.js Version \[v12.18.2\]

**Additional context/Screenshots**

Add any other context about the problem here. If applicable, add screenshots to help explain.

Tag

#ios