{"xen": [{"lastseen": "2021-01-21T17:26:26", "bulletinFamily": "software", "cvelist": [], "description": "#### ISSUE DESCRIPTION\nA x86 HVM guest with PCI pass through devices can force the allocation of all IDT vectors on the system by rebooting itself with MSI or MSI-X capabilities enabled and entries setup.\nSuch reboots will leak any vectors used by the MSI(-X) entries that the guest might had enabled, and hence will lead to vector exhaustion on the system, not allowing further PCI pass through devices to work properly.\n#### IMPACT\nHVM guests with PCI pass through devices can mount a Denial of Service (DoS) attack affecting the pass through of PCI devices to other guests or the hardware domain. In the latter case this would affect the entire host.\n#### VULNERABLE SYSTEMS\nXen versions 4.12.3, 4.12.4, and all versions from 4.13.1 onwards are vulnerable. Xen version 4.13.0 and all versions up to 4.12.2 are not affected.\nOnly x86 systems running HVM guests with PCI pass through devices are vulnerable.\n", "edition": 1, "modified": "2021-01-21T14:09:00", "published": "2021-01-21T14:09:00", "id": "XSA-360", "href": "http://xenbits.xen.org/xsa/advisory-360.html", "title": "IRQ vector leak on x86", "type": "xen", "cvss": {"score": 0.0, "vector": "NONE"}}], "googleprojectzero": [{"lastseen": "2021-01-21T19:55:22", "bulletinFamily": "info", "cvelist": [], "description": "Posted by James Forshaw, Project Zero\n\nThis blog is a continuation of my series of Windows exploitation tricks. This one describes an exploitation trick I\u2019ve been trying to develop for years, succeeding (mostly, more on that later) on the latest versions of Windows 10. It\u2019s a trick to trap access to virtual memory, get feedback when it occurs and delay access indefinitely. The blog will go into some of the background for why this technique is useful, an overview of the research I did to find the trick as well as an overview of the types of vulnerabilities it can be used with.\n\n## Background\n\nWhen would you need such an exploitation trick? A good example of the types of security vulnerabilities which can benefit can be found in the seminal [Bochspwn research](<https://storage.googleapis.com/pub-tools-public-publication-data/pdf/42189.pdf>) by Mateusz Jurczyk and Gynvael Coldwind. The research showed a way of automating the discovery of memory double-fetches in the Windows kernel.\n\nIf you\u2019ve not read the paper, a double-fetch is a type of Time-of-Check Time-of-Use (TOCTOU) vulnerability where code reads a value from memory, such as a buffer length, verifies that value is within bounds and then rereads the value from memory before use. By swapping the value in memory between the first and second fetches the verification is bypassed which can lead to security issues such as privilege escalation or information disclosure. The following is a simple example of a double fetch taken from the original paper.\n\nDWORD* lpInputPtr = // controlled user-mode address\n\nUCHAR LocalBuffer[256];\n\nif (*lpInputPtr > sizeof(LocalBuffer)) { \u2460\n\nreturn STATUS_INVALID_PARAMETER;\n\n}\n\nRtlCopyMemory(LocalBuffer, lpInputPtr, *lpInputPtr);\u2461 \n \n--- \n \nThis code copies a buffer from a controlled user mode address into a fixed sized stack buffer. The buffer starts with a DWORD size value which indicates the total size of the buffer. Memory corruption can occur if the size value pointed to by lpInputBuffer changes between the first read of the size value to compare against the buffer size \u2460 and the second read of the size when copying into the buffer \u2461. For example, if the first time the value is read it\u2019s 100 and the second it\u2019s 400 then the code will pass the size check as 100 is less than 256 but will then copy 400 bytes into that buffer corrupting the stack.\n\nOnce a vulnerability such as this example was discovered Mateusz and Gynvael needed to exploit it. How they achieved exploitation is detailed in section 4 of the paper. The exploit techniques that were identified were all probabilistic. Exploitation typically required two threads racing each other, with one reading and one writing. The probabilistic nature of success is due to the probability that in between the first read from a memory location and the second read the writing thread sets a new value which exploits the vulnerability.\n\nTo widen the TOCTOU window many of the techniques described abuse the behavior of virtual memory on Windows. A process on Windows can typically access a large virtual memory region up to 8TiB size. This size is likely to be significantly larger than the physical memory in the system, especially considering the limit is per-process, not per-system. Therefore to maintain the illusion of such a large memory address space the kernel uses on-demand memory paging.\n\nWhen memory is allocated in the process the CPU\u2019s page tables are set up to indicate the presence of the memory region but are marked as invalid. At this point the virtual memory region has been allocated but there is no physical memory backing it. When the process tries to access that memory region the CPU will generate an exception, generally referred to as a page-fault, which is handled by the kernel. \n\nThe kernel can look up the memory address which was accessed to cause the page-fault and try and fix the address. How the page-fault is fixed depends on the type of memory access. A simple example is if the memory was allocated but not yet used the kernel will get a physical memory page, initialize it to zeros then adjust the page tables to map that new physical memory page at the faulting address. Once the page-fault has been fixed the faulting thread can be restarted at the instruction which accessed the memory and the memory access should now succeed as if it was always present.\n\nA more complex scenario is if the page is part of a memory mapped file. In this case the kernel will need to request that the page\u2019s data is read back from disk before it can satisfy the page-fault. This can take quite a long time, at least for spinning rust disks, so it might require the faulting thread to be suspended while it waits for the page to be read. Once the page has been read the memory can be fixed up, the original thread can be resumed and the thread restarted at the faulting instruction.\n\n[](<https://1.bp.blogspot.com/-CTshtFzpZZg/YAhvVabh38I/AAAAAAAAaqw/t-S2XtYBdZYTrUdcHdXaF2Iv3EiRlHXoACNcBGAsYHQ/s602/image6.png>)\n\nThe end result is it can take a significant amount of time, relative to a CPU\u2019s native speed that is, to handle a page-fault. However, abusing these virtual memory behaviors only widens the TOCTOU window, it didn\u2019t allow for precise timing to swap values in memory. The result is the exploitation techniques still came with limitations. For example, it was very slow if not impossible in some cases to exploit on a machine with a single CPU core as it relies on having concurrent threads reading and writing. \n\nAn ideal exploit primitive would be one where the exploitation window can be made arbitrarily large so that it becomes trivial to win the race. Taking previous experience and knowledge of existing bug classes my ideal primitive would be one which meets a set of criteria:\n\n * Works on a default installation of Windows 10 20H2.\n * Gives a clear signal when memory is read or written.\n * Works when memory is accessed from both user and kernel mode.\n * Allows for delaying memory access indefinitely.\n * The data in the memory accessed is arbitrary.\n * The primitive can be set up from a range of privilege levels.\n * Can trap multiple times during the same exploit.\n\nWhile meeting all these criteria would be ideal, there\u2019s no guarantee we\u2019ll meet all or any of them. If we only meet some then the range of exploitation vulnerabilities might be limited. Let\u2019s start with a quick overview of the existing work which might give us an idea of how to proceed to find a primitive.\n\n## Existing Work\n\nHaving spoken to Mateusz and made an effort to look for any subsequent work there seems to be little novel work over and above the original Bochspwn paper on the exploitation of these types of TOCTOU issues. At least this is true for exploitation on Windows, however, novel techniques have been developed on other platforms, [specifically Linux](<https://static.sched.com/hosted_files/lsseu2019/04/LSSEU2019%20-%20Exploiting%20race%20conditions%20on%20Linux.pdf>). Both of these techniques rely on the behavior of virtual memory I previously described.\n\nThe first technique in Linux makes use of [Userfault File Descriptor (userfaultfd)](<https://man7.org/linux/man-pages/man2/userfaultfd.2.html>) to get notifications when page-faults occur in a process. With userfaultfd enabled a secondary thread in the process can read a notification and handle the page-fault in user mode. Handling the fault could be mapping memory at the appropriate location or changing page protection. The key is the faulting thread is suspended until the page-fault is handled by another thread. Therefore if a kernel function accessed the memory the request will be trapped until it's completed. This allows for a primitive where the memory access can be delayed indefinitely as well as having a timing signal for the access. Using userfaultfd also allows the fault to be distinguished between read and write faults as the memory page can be write-protected \n\nUsing userfaultdd works for in-process access such as from the kernel, but is not really useful if the code accessing the memory is in another process. To solve that problem you can use the [FUSE file system](<https://www.kernel.org/doc/html/latest/filesystems/fuse.html>) as Jann Horn demonstrated in a previous Project Zero [blog post](<https://googleprojectzero.blogspot.com/2016/06/exploiting-recursion-in-linux-kernel_20.html>). A FUSE file system is implemented entirely in user mode, but any requests for the file go through the Linux kernel\u2019s Virtual File System APIs. As a file is accessed as if it was implemented by an in-kernel file system it\u2019s possible to map that file into memory using [mmap](<https://man7.org/linux/man-pages/man2/mmap.2.html>). When a page-fault occurs on a FUSE backed memory region a request will be made to the user-mode file system daemon which can delay the read or write request indefinitely. \n\n## Remote File Systems\n\nAs far as I can tell there\u2019s nothing equivalent to Linux\u2019s userfaultd on Windows. One feature which caught my eye was [memory write watches](<https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-getwritewatch>). But those seem to just allow an application to query if memory had been written to since the last time it was checked and doesn\u2019t allow memory writes to be trapped.\n\nIf we can\u2019t just trap page-faults to virtual memory what about mapping a file on a user-mode filesystem like FUSE? Unfortunately there is no built-in FUSE driver in Windows 10 (yet?), but that doesn\u2019t mean there\u2019s no mechanism to implement a file system in user-mode. There are some efforts to make a real FUSE on Windows, such as the [WinFsp project](<http://www.secfs.net/winfsp/>), but I\u2019d expect the chances of them being installed on a real system to be vanishingly small.\n\nThe first thought I had was to try to exploit Multiple UNC Provider (MUP) clients. When you access a file via a UNC path, e.g. \\\\\\server\\share\\file.bin, this will be handled by a MUP driver in the kernel, which will pass it to one of the registered client drivers. As far as the kernel is concerned the opened file is a regular file (with some caveats) which generally means the file can be mapped into memory. However, any requests for the contents of that file will not be handled directly, but instead handled by a server over a network protocol.\n\nIdeally we should be able to implement our own server, handle the read or write requests to a file mapping which will allow us to detect or delay the request so that we can exploit any TOCTOU. The following table contains only Microsoft MUP drivers that I identified. The table contains what versions of Windows 10 the driver is supported on and whether it\u2019s something enabled by default.\n\nRemote File System\n\n| \n\nSupported Version\n\n| \n\nDefault? \n \n---|---|--- \n \n[SMB](<https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/5606ad47-5ee0-437a-817e-70c366052962>)\n\n| \n\nEverything\n\n| \n\nYes (SMBv1 might be disabled) \n \n[WebDAV](<https://tools.ietf.org/html/rfc4918>)\n\n| \n\nEverything\n\n| \n\nYes (except Server SKUs) \n \n[NFS](<https://docs.microsoft.com/en-us/windows-server/storage/nfs/nfs-overview>)\n\n| \n\nEverything\n\n| \n\nNo \n \n[P9](<https://www.tiraniddo.dev/2019/07/digging-into-wsl-p9-file-system.html>)\n\n| \n\nWindows 10 1903\n\n| \n\nNo (needs WSL) \n \n[Remote Desktop Client](<https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdsod/072543f9-4bd4-4dc6-ab97-9a04bf9d2c6a>)\n\n| \n\nEverything\n\n| \n\nYes \n \nWhile MUP was designed for remote file systems there\u2019s no requirement that the file system server is actually remote. SMB, WebDAV and NFS are IP based protocols and can be redirected to localhost. P9 uses a local Unix Socket which can\u2019t be remoted anyway. The terminal services client sends file access requests back to the client system over the RDP protocol. For all these protocols we can implement the server with varying degrees of effort and see if we can detect and delay reads and writes to the file mapping.\n\nI decided to focus only on two, SMB and WebDAV. These were the only two which are enabled by default and are trivially usable. While the Remote Desktop Client is in theory installed by default the RDP server is not normally enabled by default. Also setting up the RDP session is complex and might require valid authentication credentials therefore I decided against it.\n\n### Server Message Block\n\nSMB is almost as old as Windows itself, having been introduced in Lan Manager 1.0 back in 1987. The latest SMB version 3.1 protocol only bears a passing resemblance to that original version having shed its NetBIOS roots for a TCP/IP connection. Its lineage does mean it\u2019s the best integrated of any of the network file systems, with the MUP APIs being designed around the needs of SMB.\n\nI decided to do a simple test of the behavior of mapping a file over SMB. This is fairly easy as you can access SMB on the same machine via localhost. I first created a 1GiB file on a local disk, the rationale being if SMB supports caching file data it\u2019s unlikely to read something that large in one go. I then started [Wireshark](<https://www.wireshark.org/>) and monitored the loopback interface to capture the SMB traffic as shown below.\n\n[](<https://1.bp.blogspot.com/-vXhkSagBdBU/YAhvVDfEscI/AAAAAAAAaqo/1IIZjYYR2MULMA1tGOTBNs5a6ssC1VLLQCNcBGAsYHQ/s957/image1%2B%25281%2529.png>)\n\nI then wrote a quick PowerShell script which will map the file into memory and then reads a few bytes from memory at a few different offsets.\n\nUse-NtObject($f = Get-NtFile \"\\\\\\localhost\\c$\\root\\file.bin\" -Win32Path) {\n\nUse-NtObject($s = New-NtSection -File $f -Protection ReadWrite) {\n\nUse-NtObject($m = Add-NtSection -Section $s -Protection ReadWrite) {\n\n$m.ReadBytes(0, 4)\n\n$m.ReadBytes(256*1024*1024, 4)\n\n$m.ReadBytes(512*1024*1024, 4)\n\n$m.ReadBytes(768*1024*1024, 4)\n\n}\n\n}\n\n} \n \n--- \n \nThis just reads 4 bytes from offset, 0, 256MiB, 512MiB and 768MiB. Going back to Wireshark I filtered the output to only SMBv2 read requests using the display filter smb2.cmd == 8, and the following four packets can be observed.\n\nRead Request Len:32768 Off:0 File: root\\file.bin\n\nRead Request Len:32768 Off:268435456 File: root\\file.bin\n\nRead Request Len:32768 Off:536870912 File: root\\file.bin\n\nRead Request Len:32768 Off:805306368 File: root\\file.bin \n \n--- \n \nThis corresponds with the exact memory offsets we accessed in the script although the length is always 32KiB in size, not the 4 we requested. Note, that it\u2019s not the typical Windows memory allocation granularity of 64KiB which you might expect. In my testing I\u2019ve never seen anything other than 32KiB requested. \n\nAll the bytes we\u2019ve tested are aligned to the 32KiB block, what if the bytes were not aligned, for example if we accessed 4 bytes from address 512MiB minus 2? Changing the script to add the following allows us to check the behavior:\n\n$m.ReadBytes(512*1024*1024 - 2, 4) \n \n--- \n \nIn Wireshark we see the following read requests.\n\nRead Request Len:32768 Off:536838144 File: root\\file.bin\n\nRead Request Len:32768 Off:536870912 File: root\\file.bin \n \n--- \n \nThe accesses are still at 32KiB boundaries, however as the request straddles two blocks the kernel has fetched the preceding 32KiB of data from the file and then the following 32KiB. You might think that all makes sense, however this behavior turned out to be a fluke of testing. \n\n[Overview diagram of memory read layout. In the middle is a set of boxes representing the native 4KiB pages being read. All the boxes are contained within a single larger region which is the large page size. Above the boxes are arrows which show that from the base of the 4KiB box a 32KiB read will be made into the file which can satisfy the reads from other 4KiB pages. The final box shows that the last 32KiB of the large page size will always be read as a single page regardless of where in the box the read occurs.\" style=\"max-height: 750; max-width: 600;\" />](<https://1.bp.blogspot.com/-zjE_Vx7-iOk/YAhvVfwuRbI/AAAAAAAAaq0/DvDY-3j1fw8Qg75Z_wFlAMJctgM98jpOQCNcBGAsYHQ/s656/image5.png>)\n\nThe diagram above shows the structure of how mapped file reads are handled. When an address is read the kernel will request 32KiB from the closest 4KiB page boundary, not the 32KiB boundary. However, there\u2019s then a secondary structure on top based on the supported size of [large pages](<https://docs.microsoft.com/en-us/windows/win32/memory/large-page-support>). If the read is anywhere within 32KiB of the end of a large page the read offset is always for the last 32KiB.\n\nFor example, on my system the large page size (as queried using the [GetLargePageMinimum](<https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-getlargepageminimum>) API) is 2MiB. Therefore if you start at offset 512MiB, between 512 and 514 - 32KiB the kernel will read 32KiB from the offset truncated to the closest 4KiB boundary. Between 514 - 32KiB and 514MiB the read will always request offset 514 - 32KiB so that the 32KiB doesn\u2019t cross the large page boundary.\n\nThis allows reads at 4KiB boundaries, however the amount of data read is still 32KiB. This means that once one 4KiB page is accessed the kernel will populate the current page and 7 following pages. Is there any way to only populate a single native page? Based on a comment from Mateusz I tested returning short reads. If the SMB server returns fewer bytes than requested from the read then rather than failing it only populates the pages covered by the read. By returning these short reads we can get trap granularity down to the native page size except for the final 32KiB of a large page. If a read request is shorter than the native page size the rest of the page is zeroed.\n\nWhat about writing? Let\u2019s change the script again to call WriteBytes rather than ReadBytes, for example:\n\n$m.WriteBytes(256*1024*1024, @(0xAA, 0xBB, 0xCC, 0xDD)) \n \n--- \n \nYou will see a write request to the file in Wireshark, similar to the following:\n\nWrite Request Len:4096 Off:268435456 File: root\\file.bin \n \n--- \n \nHowever, if you dig a bit deeper you\u2019ll notice that the write only happens once the file is closed, not in response to the WriteBytes call. This makes sense, there isn\u2019t any easy way to detect when the write happened to force the page to be flushed back to the file system. Even if there was a way flushing to a network server for every write would have a massive performance impact.\n\nAll is not lost however, before the memory is safe to write it must be populated with the contents from the file. Therefore if you look before the write you\u2019ll see a corresponding read request for the 32KiB region which encompasses the write location which is synchronous with the read. You can detect a write through its corresponding read but you can\u2019t distinguish read from a write at the protocol level.\n\nAll this testing indicates if we have control over the server we can detect memory access to the mapped file. Can we delay the access as well? I wrote a simple SMB server in .NET 5 using the [SMBLibrary](<https://github.com/TalAloni/SMBLibrary>) by Tal Aloni. I implemented the server with a custom filesystem handler and added some code to the read path which delays for 10 seconds when the file offset is greater than 512MiB.\n\nif (Position >= (512 * 1024 * 1024)) {\n\nConsole.WriteLine(\"====> Delaying at Position {0:X}\", Position);\n\nThread.Sleep(10000);\n\nConsole.WriteLine(\"====> Continuing.\");\n\n} \n \n--- \n \nThe data returned by the read operation can be arbitrary, you just need to fill in the appropriate byte buffers in the read. To test the access times I wrapped the memory read requests inside a Measure-Command call to time the memory access.\n\nMeasure-Command { $m.ReadBytes(512*1024*1024 - 4, 4) }\n\nMeasure-Command { $m.ReadBytes(512*1024*1024 - 4, 4) }\n\nMeasure-Command { $m.ReadBytes(512*1024*1024, 4) }\n\nMeasure-Command { $m.ReadBytes(512*1024*1024, 4) } \n \n--- \n \nTo compare the access time a read request is made to a location 4 bytes below the 512MiB boundary and then at the 512MiB boundary. By making two requests we should be able to see if the results differ per-read. The results were as follows:\n\n# Below 512MiB (Request 1)\n\nDays : 0\n\nHours : 0\n\nMinutes : 0\n\nSeconds : 1\n\nMilliseconds : 25\n\n...\n\n# Below 512MiB (Request 2)\n\nDays : 0\n\nHours : 0\n\nMinutes : 0\n\nSeconds : 0\n\nMilliseconds : 1\n\n...\n\n# Above 512MiB (Request 1)\n\nDays : 0\n\nHours : 0\n\nMinutes : 0\n\nSeconds : 10\n\nMilliseconds : 358\n\n...\n\n# Above 512MiB (Request 2)\n\nDays : 0\n\nHours : 0\n\nMinutes : 0\n\nSeconds : 0\n\nMilliseconds : 1\n\n... \n \n--- \n \nThe first access for below 512MiB takes around a second, this is because the request still needs to be made to the server and the server is written in .NET which can have a slow startup time for running new code. The second request takes significantly less that 1 second, the memory is now cached locally and so there doesn\u2019t need to be any request.\n\nFor the accesses above 512MiB the first request takes around 10 seconds, which correlates with the added delay. The second request takes less than a second because the page is now cached locally. This is exactly what we\u2019d expect, and proves that we can at least delay for 10 seconds. In fact you can delay the request at least 60 seconds before the connection is forcibly reset. This is based on the session timeout for the SMB client. You can query the SMB client timeout using the following command in PowerShell:\n\nPS> (Get-SmbClientConfiguration).SessionTimeout\n\n60 \n \n--- \n \nA few things to note about the SMB client\u2019s behavior which came out of testing. First the client or the Windows cache manager seem to be able to do some caching of the remote file. If you request a specific access when opening the file, such as GENERIC_READ | GENERIC_WRITE for the desired access then caching is enabled. This means the read requests do not go to the server if they\u2019re previously been cached locally. However if you specify MAXIMUM_ALLOWED for the desired access the caching doesn\u2019t seem to take place. Secondly, sometimes parts of the file will be pre-cached, such as the first and last 32KiB of the file. I\u2019ve not worked out what is the cause, oddly it seems to happen more often with native code than .NET code, so perhaps it\u2019s Windows Defender peeking at memory or perhaps Superfetch. In general as long as you keep your memory accesses somewhere in the middle of a large file you should be safe.\n\nIf you\u2019ve run the example code you might notice a problem, running the example server locally fails with the following error:\n\nSystem.Net.Sockets.SocketException (10013): An attempt was made to access a socket in a way forbidden by its access permissions.\n\nBy default Windows 10 has the SMB server enabled. This takes over the TCP ports and makes them exclusive so it\u2019s not possible to bind to them from a normal user. It is possible to disable the local SMB server, but that would require administrator privileges. Still, it was worth verifying whether the SMB server approach will work even if we have to communicate with a remote server.\n\nI did do some investigation into tricks I could use to get the built-in SMB server to work for our purposes. For example I tried to use the fact that you can set an Opportunistic Lock which will trap file reads. I used this trick to exploit a [TOCTOU vulnerability](<https://bugs.chromium.org/p/project-zero/issues/detail?id=1774>) in the LUAFV driver. Unfortunately the SMB server detects the file is already in a lock and waits for the OpLock break to occur before allowing access to the file. This made it a non-starter.\n\nFor testing you can disable the LanmanServer service and its corresponding drivers. If you wanted to use this on an arbitrary system you'd almost certainly need to connect to a remote server. I\u2019ve released the example server code [here](<https://bugs.chromium.org/p/project-zero/issues/detail?id=2142>), which can be repurposed, although it is only a demonstrator. It allows for read granularity of the native page size, which is assumed to be 4KiB. The server code should work on Linux but as of version 1.4.3 of SMBLibrary on NuGet there\u2019s a bug which causes the server to fail when starting. There is a fix in the [github repository](<https://github.com/TalAloni/SMBLibrary/commit/e1d06e72daa91a4f0021707c525bcd20c805d7fc>) but at the time of writing there\u2019s no updated package.\n\nHow well does abusing the SMB client meet with our criteria from earlier? I\u2019ve crossed out all the ones we\u2019ve met.\n\n * Works on a default installation of Windows 10 20H2.\n * Gives a clear signal when memory is read or written.\n * Works when memory is accessed from both user and kernel mode.\n * Allows for delaying memory access indefinitely.\n * The data in the memory accessed is arbitrary.\n * The primitive can be set up from a range of privilege levels.\n * Can trap multiple times during the same exploit.\n\nUsing the SMB client does meet the majority of our criteria. I verified that it doesn\u2019t matter whether kernel or user mode code accesses the memory it will still trap. The biggest problem is it\u2019s hard to use this from a sandboxed application where it would perhaps be most useful. This is because MUP restricts access to remote file systems by default from restricted and low IL processes and AppContainer sandboxes need specific capabilities which are unlikely to be granted to the majority of applications. That\u2019s not to say it\u2019s completely impossible but it\u2019d be hard to do.\n\nWhile our trick doesn\u2019t really delay the memory read indefinitely, for our purposes the limit of 60 seconds based on the SMB session timeout is going to be enough for most vulnerabilities. Also once the trap has been activated you can\u2019t force the memory manager to request the same page from the server. I tried playing with memory caching flags and direct IO but at least for files over SMB nothing seemed to work. However, you can specify your own base address when mapping a file so you could map different offsets in the file to the same virtual address by unmapping the original and mapping in a new copy. This would allow you to use the same address multiple times.\n\n### WebDAV\n\nAs SMB can\u2019t be easily used locally, what about WebDAV? By default TCP port 80 is unused on Windows 10 so we can start our own web server to communicate with. Also unlike on Linux there\u2019s no requirement for having administrator privileges to bind to TCP ports under 1024. Even if either of these were not the case the WebDAV client supports a syntax to specify the TCP port of the server. For example if you use the path \\\\\\localhost@8080\\share then the WebDAV HTTP connection will be made over port 8080.\n\nHowever, does the WebDAV client expose the right read and write primitives to allow us to trap on memory access? I wrote a simple WebDAV server using the [NWebDav](<https://github.com/ramondeklein/nwebdav>) library to serve local files. Running the script but specifying the WebDAV server on port 8080 to open the 1GiB file I\u2019m immediately faced with a problem:\n\nGet-NtFile : (0xC0000904) - The file size exceeds the limit allowed and cannot be saved.\n\nJust opening the file fails with the error code STATUS_FILE_TOO_LARGE. The reason for that can be found in one of many Microsoft Knowledge Base articles such as [this one](<https://support.microsoft.com/en-us/help/900900/folder-copy-error-message-when-downloading-a-file-that-is-larger-than>). There\u2019s a default limit of 50MB (that\u2019s decimal megabytes) for any file accessed on a WebDAV share because it used to be possible to cause a denial of service by tricking a Windows system into downloading an arbitrarily large file.\n\nThe reason this size limiting behavior is in place is why WebDAV isn\u2019t suitable for this attack. If you resize the file to below 50MB you\u2019ll find the WebDAV client pulls the file in its entirety to the local disk before returning from the file open call. That file is then mapped into memory as a local file. The WebDAV server never receives a GET or PUT request for reads/writes to the memory mapping synchronously so there\u2019s no mechanism to detect or trap specific memory requests.\n\n## File System Overlay APIs\n\nAbusing the SMB client does work, but it can\u2019t be used locally on a default installation. I decided I need to look for another approach. As I was looking at Windows Filter Drivers (see [last blog post](<https://googleprojectzero.blogspot.com/2021/01/hunting-for-bugs-in-windows-mini-filter.html>)) I noticed a few of the drivers provided a mechanism to overlay another file system on top of an existing one. I trawled through MSDN to find the API documentation to see if anything would be suitable. The three I looked at are shown in the table below.\n\nFile system\n\n| \n\nSupported Version\n\n| \n\nDefault? \n \n---|---|--- \n \n[Projected File System](<https://docs.microsoft.com/en-us/windows/win32/projfs/projected-file-system>)\n\n| \n\nWindows 10 1809\n\n| \n\nNo \n \n[Windows Overlay (WOF)](<https://docs.microsoft.com/en-us/windows/win32/api/wofapi/>)\n\n| \n\nEverything\n\n| \n\nYes \n \n[Cloud Files API](<https://docs.microsoft.com/en-us/windows/win32/cfapi/cloud-files-api-portal>)\n\n| \n\nWindows 10 1709 \n\n| \n\nYes (except non-Desktop Server SKUs) \n \nBy far the most interesting one is the Projected File System. This was developed by Microsoft to provide a virtual file system for GIT. It allows placeholder files to be \u201cprojected\u201d into a directory on disk and the contents of those files are only \u201crehydrated\u201d to a full file on demand. In theory this sounds ideal, as long as it would populate the file\u2019s contents piecemeal we could add the delays when receiving the [PRJ_GET_FILE_DATA_CB callback](<https://docs.microsoft.com/en-us/windows/win32/api/projectedfslib/nc-projectedfslib-prj_get_file_data_cb>). \n\nHowever a basic implementation based on Microsoft\u2019s [ProjectedFileSystem](<https://github.com/Microsoft/Windows-classic-samples/tree/master/Samples/ProjectedFileSystem>) sample code would always rehydrate the entire file during file open, similar to WebDAV. Perhaps there\u2019s an option I missed to stream the contents rather than populate it in one go but I couldn\u2019t find it immediately. In any case the Projected File System is not installed by default making it less useful. \n\nWOF doesn\u2019t really allow you to implement your own file system semantics. Instead it allows you to overlay files from either a secondary Windows Image File (WIM) or compressed on the same volume. This really doesn\u2019t give us the control we\u2019re looking for, you might be able to finagle something to work but it seems a lot of effort.\n\nThat leaves us with the Cloud Files API. This is used by OneDrive to provide the local online filesystem but is documented and can be used to implement any file system overlay you like. It works very similar to the Projected File System, with placeholders for files and the concept of hydrating the file on demand. The contents of the files do not need to come from any online service such as OneDrive, it can all be sourced locally. Crucially after some basic testing it supports streaming the contents of the file based on what was being read and you could delay the file data requests and the reading thread would block until the read has been satisfied. This can be enabled by specifying the [CF_HYDRATION_POLICY_PRIMARY](<https://docs.microsoft.com/en-us/windows/win32/api/cfapi/ne-cfapi-cf_hydration_policy_primary>) hydration policy with the value CF_HYDRATION_POLICY_PARTIAL when configuring the base sync root. This allows the Cloud File API to only hydrate the file's parts which were accessed.\n\nThis seemed perfect, until I tested with the PowerShell file mapping script where it didn\u2019t work, my cloud file provider would always be requested to provide the entire file. Checking the Cloud Filter driver, when a request is received for mapping a placeholder file, the [IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION](<https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/flt-parameters-for-irp-mj-acquire-for-section-synchronization>) handler always fully rehydrates the file before completing. If the file is not hydrated fully then the call to NtCreateSection never returns which prevents the file being mapped into memory.\n\nI was going to go back to doing my filter research until I realized I might be able to combine the SMB client loopback with the Cloud Filter API. I already knew that the SMB client doesn\u2019t really map a file, even locally, instead it would read it on-demand via the SMB protocol. And I also knew that the Cloud Filter API would allow streaming of parts of the file on-demand as long as the file wasn\u2019t being mapped into memory. The final setup is shown in the following diagram:\n\n[](<https://1.bp.blogspot.com/-dJhd0x36tAw/YAhvU8P3e9I/AAAAAAAAaqg/9JGdVuiuW1MQGUigZ1rwXlw9oU0NTEEuwCNcBGAsYHQ/s653/image2%2B%25281%2529.png>)\n\nTo use the primitive we first setup our own cloud provider by registering the sync root directory using the [CfRegisterSyncRoot](<https://docs.microsoft.com/en-us/windows/win32/api/cfapi/nf-cfapi-cfregistersyncroot>) API configuring it with the partial hydration policy. Then a 1GiB placeholder can be created in the directory using [CfCreatePlaceholders](<https://docs.microsoft.com/en-us/windows/win32/api/cfapi/nf-cfapi-cfcreateplaceholders>). At this point the file does not have any contents on disk. If we now open and map the placeholder file via the SMB loopback client the file will not be rehydrated immediately. \n\nAny memory access into the mapping will cause the SMB client to make a request for a 32KiB block, which will be passed to our user-mode cloud provider, which we can detect and delay as necessary. It goes without saying that the contents of the file can also be arbitrary. Based on testing it doesn\u2019t seem like you can force the read granularity down to the native page size like when implementing a custom SMB server, however you can still make requests at native page size boundaries within the large page size constraint. It might be possible to modify the file size to trick the SMB server into doing short reads but this behavior has not been tested. A sample implementation of the cloud provider is available [here](<https://bugs.chromium.org/p/project-zero/issues/detail?id=2142>).\n\n## Usage Examples\n\nWe now have an exploitation trick which allows us to trap and delay virtual memory reads and writes. The big question is, does this improve the exploitation of vulnerabilities such as double fetches? The answer depends on the actual vulnerability. A quick note, when I use the word page I\u2019m meaning the unit of memory which will cause a request to the SMB server, e.g. 32KiB not the native page size such as 4KiB.\n\nLet\u2019s take the example given at the start of this blog post. This vulnerability reads the value from the same memory address, lpInputPtr, twice. First for the comparison, then for the size to copy. The problem for exploitation is one of the limitations of the technique is the memory trap is one shot. Once the trap has fired to read the size for the comparison you can delay it indefinitely. However, once you provide the requested memory page and the faulting thread is resumed it won\u2019t fire on the second read, it\u2019ll just be read from memory as if it was always there. \n\nYou might wonder if you could remap the memory page when you detect the first read? Unfortunately this doesn\u2019t work. When the thread is resumed it restarts at the faulting instruction and will perform the read again, therefore what would happen is the following:\n\n[](<https://1.bp.blogspot.com/-WVLs6UIJ2nA/YAhvVJHpyHI/AAAAAAAAaqk/4K6BkSBi5-gC6MG3QoUx5Xi-8tr_5T1cQCNcBGAsYHQ/s428/image3%2B%25281%2529.png>)\n\nAs you can tell from the diagram you end up trapped in an infinite loop, as you remap a fresh page which just triggers another page fault ad infinitum. If you don\u2019t perform step \u2462 then the operation will complete and there is a time window between resuming the thread, reading the now valid memory for the size comparison and the second read. However, in this example the time window is likely to be the order of a couple of instructions so using our exploitation trick isn\u2019t better than the existing probabilistic approaches. That said one advantage is you do know when the read occurs which allows you to target the brute force window more accurately.\n\nThis example is the worst case, what if there was more time between the reads? Another example from a the Bochspwn paper is shown below:\n\nPDWORD BufferSize = // controlled user-mode address\n\nPUCHAR BufferPtr = // controlled user-mode address\n\nPUCHAR LocalBuffer;\n\nLocalBuffer = ExAllocatePool(PagedPool, *BufferSize);\u2460\n\nif (LocalBuffer != NULL) {\n\nRtlCopyMemory(LocalBuffer, BufferPtr, *BufferSize);\u2461\n\n} else {\n\n// bail out\n\n} \n \n--- \n \nThe same double fetch behavior is present, however what\u2019s different is the value is passed to another function, in this case ExAllocatePool which allocates kernel memory. Depending of the current memory configuration or how large the allocation requested there might be a significant time delay between \u2460 and \u2461. Is there any way we can win the race?\n\nWell not that I know of, at least not deterministically. But we can exploit one behavior to try to synchronize the reading and writing threads a little. Recall that in order to write to an unresolved page the contents of the page must first be read from the server. Therefore, to maintain consistency any thread writes to the unresolved page must generate a page fault and wait on the same lock as another thread which is just reading from the page, as shown in the following diagram:\n\n[](<https://1.bp.blogspot.com/-JIlrPsYa0Ls/YAhvVvHql8I/AAAAAAAAaq4/kmvHiIOto0gI-yZLYt9TL4j8tgZXoMrKACNcBGAsYHQ/s546/image7.png>)\n\nBy synchronizing the reading and writing threads you\u2019re giving yourself a reasonable chance of causing a write to happen during the time window for exploitation. This is still a probabilistic approach, it depends on the scheduler. For example, it\u2019s possible that the write thread is woken before the read thread which will cause the pointer to always take the final value. Or the read thread could run to completion before the write thread is ever scheduled to run making the value never change. It\u2019s possible there\u2019s some scheduler magic such as using multiple reader or writer threads or by selecting appropriate priorities which you could exploit to guarantee read and write ordering. I\u2019d be surprised if something is reliable across multiple Windows 10 systems. I\u2019d be very interested in anyone who\u2019s got better ideas on how to improve the reliability of this.\n\nOne approach you might be wondering about is unaligned access, say splitting the value across two separate pages. From a microarchitecture perspective it\u2019s likely that the read will be split up into two parts, first touching one page then another. However, remember how the page fault works, it generates an exception which causes a handler to execute in the kernel. At this point any work the instruction has already done will have been retired while the kernel deals with the page fault. When the thread is resumed it will restart the faulting instruction, which will reissue the appropriate micro operations to read from the unaligned address. Unless the compiler generated two loads for the unaligned access (which might happen on some architectures) then there is no way I know of to restart the memory access instruction part of the way through. \n\nThis all seems slightly downbeat on the usefulness of the exploitation trick. Thing is, there\u2019s as many different types of vulnerability as there are fish in the sea (if you\u2019re reading this in 2100, I apologize for the acidification of the seas which killed all marine life, choose your own apocalypse-appropriate proverb instead). For example if we modify the original example as follows:\n\nPDWORD lpInputPtr = // controlled user-mode address\n\nUCHAR LocalBuffer[256];\n\nif (lpInputPtr[0] > sizeof(LocalBuffer) || lpInputPtr[1] != 2) {\n\nreturn STATUS_INVALID_PARAMETER;\n\n}\n\nRtlCopyMemory(LocalBuffer, lpInputPtr, *lpInputPtr); \n \n--- \n \nThe check now ensures the buffer is large enough and a second DWORD in the buffer is not set to 2. The second field might represent the buffer type, and type 2 isn\u2019t valid for this request. If you check the compiler output for this code, such as on [Godbolt](<https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAM1QDsCBlZAQwBtMQBGAFlICsupVs1qhkAUgBMAISnTSAZ0ztkBPHUqZa6AMKpWAVwC2tEJNJb0AGTy1MAOWMAjTMS4AOUgAdUCwuto9QxMzb19/Ohs7RyMXN05PJRU1OgYCZmICIONTcyTMVQC0jIIoh2dXD0V0zOyQvJrS23LYyoSASkVUA2JkDgByAgBPL0wsKgBqA1o/YDt0CdsCCYARAHUAeQAlFfEAZlkABgBBYdHxiYA3fWY1divUPHQAKgmABQA1DYBJXYPxE5nMaYSbTWbzCbIBAZCYAVR0AAljlt9kdTiNgZNrsI7phVpsdq83uttn80QDjtcnhMtgRWHovEMALKYIwkIYQT4/FarTAKAikd5fX4TBjdXqYQUknaivAAL0w7VRFK0xgm9gAKgwNccNbCGBNxAB2NETUU6vUMAD633sH2OVl%2BVreyOOTOwGuwW0Nex5hwAHjpDsGQ9gKcayeGTprtbr9atuk52AAxTAEKGc6U81heb60LwGAhvAjEdqGk0Us3wpHeiZWVAsVjSAxUKiucQAVmkkg7ADZO5GToah4tJhBnjm8wWiyWfdgJn4FagqBB643m63XO0y8bTWaJsQ0z1aOa49bbfbHStna73Z6Uf8RxHKzS6Qzmaz2auG2wN22yBMk75oWxYAROubATOpbKicEb9J0rAgP0Hb9KQpj9IcqGoEhOhyHIC7in0hqSHsnCoQQSGYZ0EBIGgWC4IQJDkJQND0EwbAcDw/ChMIogoHhMiKMoBQpKYECWHUuQWNoZQxHEVQ%2BH4omSaEikRLQskVPEiTCYUqSNCpeS6aJxSZJprTadUJSGVZZnNHJbTuJ0CiEQMQIXGCeBzGMiz0PipIwei5wgg8OJ4PcVIvEK3KBe5IWed5CxQjC1bIrFGIXNitzhXiWZElmgUUpFr70qgjIsmyxAclyIorHyArRSKYo9H0UoEjyDDyoqgWqkY6paha8a7i%2BsaWjadoOk6LpbG6Hpej6fqBiGobhkag7HBSMaDQaKyJimaYZsS7WARB06gTuFYjqltZrr%2BLb/p23Z9gOgXDscZp4GOQFnSWj2HAOc4Ll1y7fuu91buWuFGjoJ1TiBv1dpwANgGA%2Bw8pIF17mah4EMep5jRek3XtNs33q95a7COtKleVn5VaDd2bgB33w2BLNQUqj4bWt8FCEhKFoZRWE4QJ0gES1eJSHskjkUL26kAA1iAex7AAdCrGua1rvZ8/03CoehmGkNh/SoQoICHKQFEYbzcCwLRqBGF4OVkBQEBoE7LsgJcyBeF4VqXJwACcVqSO4Vr%2Br2vBUOFBCuObEBOELpBOLYGRDEhZGkB7RhaAQGy0KwGc26QWBGCIwDsMn%2BCHoUlx8snmD%2BgUhYDFnSzKMnrB4E4xDp3oWCZ%2BRxB4EYQ%2BdKxjCNpxvACJwQgV/xMhyEIPfm5AnRlaJ5v9AA9AA4gwAC0Ey7xsMtCckASaNoKnz5Y5nyfPanKfoOSCC/ASP20l8iUUBlvxCPPfIelaCmSaNELSgh%2BTWUAaYYBjRv7xGcq5LgCF%2BYG2TibSO3AJhGAUD7K4wdVZhwmBABiRBiDEVIoKPQnt2BUKlpwMsuFl4yFljbeWSsVbqy1nwlWOtEJ60wSXE2ZsLZWzlqQO2iAUCO2dgw5i7t5Fex9n7AOwdQ7hxwaQGOrA47EATknEuqdaDpyHtnR2ud6AFyLtXVkFcq4lxrn/euO8jZNxbnHCxHchFG27r3fuGA27D1HuPXRdAp4cS4LPHii8JBsPkAE9eEBN5eG3khA%2Bx9T7nzNsZa%2B4lb5wMEA/eyUDn7hFfsEeBYQlJfzKRZaB%2BT9KwOqU0q%2BLS7KQMaQg1p79eldJaE/FBEszDoOQiIo22Co54IIcgIhQcSHuDIRQkg1DzATDoQo1w6yWGiw4VRTo3C1b8P4brfWgtRFIXEZba2hzdYX0NsLU2kjOGdHroY6%2B3AgA%3D>), the difference in native code is 2 or 3 instructions. This would seem to not materially improve the odds of winning the TOCTOU race when using a na\u00efve probabilistic approach. But with our exploitation trick we can now build a deterministic exploit.\n\n[](<https://1.bp.blogspot.com/-E0iJP4Et5zU/YAhvV3TyHNI/AAAAAAAAaq8/ny3Vf8s66_Qd7b0bOFeXExRHMk46CJ8dACNcBGAsYHQ/s864/image8.png>)\n\nThe diagram above shows how we can achieve this deterministic exploit. We can place the Size field on a different page to the rest of the input buffer, although the buffer is still contiguous in virtual memory. The first page (N-1) should already be faulted into memory and contain the Size field which is smaller than the LocalBuffer size. We can let the read for the size \u2460 complete normally.\n\nNext the code will read the Type field which is on page N \u2461. This page isn\u2019t currently in memory and so when it\u2019s accessed a page fault will occur \u2462. This requires the kernel to read the contents from the file, which we can detect and delay. When the read is detected we have as long as we need to modify the Size field to contain a value larger than the LocalBuffer size \u2463. Finally we complete the read, which will restart the thread back at the Type field read instruction \u2464. The code can continue and will now read the overly large Size field and cause memory corruption.\n\nThe key takeaway is that if between the double fetch points the code touches any user mode memory under your control which is not the one being double fetched it should be possible to convert that into a deterministic exploit. It doesn\u2019t matter if the target system only has a single CPU, what the scheduling algorithm is in the kernel, how many instructions are between the double fetch points or what day of the week it is etc, it should \u201cjust work\u201d.\n\nThe followup [blog post](<https://j00ru.vexillium.org/2013/06/kernel-double-fetch-race-condition-exploitation-on-x86-further-thoughts/>) on double-fetch exploitation gives some figures for exploitability. The examples shown up to now, when the right timing window is chosen the chance of success can hit 100% after some number of seconds. However, as shown here we can get 100% reliability on some classes of the same bug, but in the best case this isn\u2019t an improvement other than it being deterministic. \n\nAll examples up to now only demonste the exploitation of what the blog post refers to as arithmetic races. The blog also mentions a second class of bug, binary races, which are harder to exploit and never reach 100% success. Let\u2019s look at the example in the blog and see if our exploitation trick would do better.\n\nPVOID* UserPointer = // controlled user-mode address\n\n__try {\n\nProbeForWrite(*UserPointer, sizeof(STRUCTURE), 1);\u2460\n\nRtlCopyMemory(*UserPointer, LocalPointer, sizeof(STRUCTURE));\u2461\n\n} __except {\n\nreturn GetExceptionCode();\n\n} \n \n--- \n \nOn the face of it this doesn\u2019t look massively different to previous examples, however in this case the destination pointer is being changed rather than the size. The [ProbeForWrite](<https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-probeforwrite>) kernel API which checks the pointer is both at a user-mode address and the memory is writable. This is a commonly used idiom to verify a user supplied pointer is not pointing into kernel memory. \n\nIf the pointer value is changed between \u2460 and \u2461 from a user mode address to a kernel mode address the example would overwrite kernel memory. The behavior is harder to exploit with a probabilistic exploit as there are only two valid values of the pointer, either a user-mode address or a kernel mode address. If you\u2019re brute forcing the pointer value then it\u2019s possible to end up where both fetches read a user-mode pointer even though it might change to a kernel pointer in between the fetches.\n\nFortunately, due to the call to ProbeForWrite this is trivial to exploit if you can trap on user memory access as shown in the following diagram:\n\n[](<https://1.bp.blogspot.com/-ODNsY-JRbDY/YAhvVXjUGfI/AAAAAAAAaqs/ZZNOS4mlZpUhZVWXL4igruFFMVRFdbYPQCNcBGAsYHQ/s875/image4%2B%25281%2529.png>)\n\nFrom the diagram the first read from UserPointer is made \u2460 and the resulting pointer value passed to ProbeForWrite. The ProbeForWrite API first checks if the pointer is in the user-mode address space, then probes each page of memory up to the size of the length parameter \u2461. If the page is invalid or is not writable then an exception will be generated and caught by the example's __except block. This gives us our exploit opportunity, we can use the exploitation trick on the one of the user-mode pages which is being probed which will cause ProbeForWrite to generate a page fault we can trap \u2462. However as the address being probed is not the same as the one storing the pointer we can modify it to contain a kernel mode address while the request is trapped \u2463. The result is we can deterministically win the race.\n\nOf course I\u2019ve been focussing on kernel double fetches as it\u2019s what originally drew me to look for this behavior. There are many scenarios where this can be used to aid exploitation of user-mode applications. The most obvious one is where a service is sharing memory with a lower privileged application. An example of this sort of issue was a [double-fetch in the DfMarshal COM marshaler](<https://bugs.chromium.org/p/project-zero/issues/detail?id=1648>). The COM marshaler shared a memory section between processes so it was possible to provide a section which exploited our trick. In the end this trick wasn\u2019t necessary as the logic of the vulnerable code allowed me to create an infinite loop to extend the double fetch window. However if that didn't exist we could use this trick to detect and delay when the code was at the point where the handle could be switched.\n\nAnother more subtle use is where a privileged process reads memory from a less privileged process. This might be explicit use of APIs such as [ReadProcessMemory](<https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-readprocessmemory>) or it could be indirect, for example querying for the process\u2019 command line using NtQueryInformationProcess will read out memory locations under our control.\n\nThe thing to remember with this exploitation trick is it can be used to open up the window to win a timing race. In this case it\u2019s similar to my previous work on oplocks, but instead for memory access. In fact the access to memory might be incidental to the vulnerable code, it doesn\u2019t have to be a memory double fetch or necessarily even a TOCTOU vulnerability. For example you might be trying to win a race between two file paths with symbolic links. As long as the vulnerable code can be made to probe a user mode address we control then you can use it as a timing signal and to widen the exploitation window.\n\n## Conclusions\n\nI\u2019ve described an exploitation trick by combining SMB and the Cloud File API which can aid in demonstrating exploitation of certain types of the application and kernel vulnerabilities. It\u2019s possible that there are other ways of achieving a similar result with APIs I haven\u2019t looked at, but for now this is the best approach I\u2019ve come up with. It allows you to trap on reads from user-mode memory, detect when the access occurs and delay the read for at least 60 seconds. Examples of code to implement the SMB and Cloud File API tricks are available [here](<https://bugs.chromium.org/p/project-zero/issues/detail?id=2142>).\n\nIt\u2019s worth just reiterating some more of the limitations of this exploitation trick before we conclude.\n\n * Can\u2019t be used in a sandbox, only from a normal user privilege.\n * Only allows a one shot for any page mapped from the file. If something else (such as AV) tries to read that page or from the file then the trap may fire early.\n * Can\u2019t detect the exact location of a read, limited to a granularity of 4KiB. For local access via the Cloud File API this will always populate the next 7 pages as well as part of the 32KiB read. If accessing a custom SMB server the read size can be reduced to 4KiB. Would prevent exploitation of certain bugs which require precise trapping only on a small area within a larger structure.\n * Can only detect writes indirectly, can\u2019t specifically trap on a write.\n\nFrom a practical perspective the trick presented here doesn\u2019t significantly improve the win rates for traditional kernel double fetches outlined in the Bochspwn paper. Realistically for most of those classes of vulnerability you\u2019d probably want to use a probabilistic approach, if anything due to its simplicity of implementation. However the trick is applicable to other bug classes where the memory trap is used as a deterministic timing signal adjunct to the vulnerability.\n\nThe one shot nature of the trick also makes it of no real benefit to exploiting simple double fetch code paths. Also more complex code which might read and write to a memory address more than once before you get to the vulnerable code which might make managing traps more difficult.\n", "modified": "2021-01-21T00:00:00", "published": "2021-01-21T00:00:00", "id": "GOOGLEPROJECTZERO:BFBEB0B84486038227C0C8638C4D68A5", "href": "https://googleprojectzero.blogspot.com/2021/01/windows-exploitation-tricks-trapping.html", "type": "googleprojectzero", "title": "\nWindows Exploitation Tricks: Trapping Virtual Memory Access\n", "cvss": {"score": 0.0, "vector": "NONE"}}], "rst": [{"lastseen": "2021-01-20T00:00:00", "bulletinFamily": "ioc", "cvelist": [], "description": "Found **https://insignificantfinecore[.]testmail4.repl.co/x86** in [RST Threat Feed](https://rstcloud.net/profeed) with score **52**.\n First seen: 2021-01-05T03:00:00, Last seen: 2021-01-20T03:00:00.\n IOC tags: **malware**.\nIt was found that the IOC is used by: **bashlite**.\n[https://rstcloud.net/](https://rstcloud.net/)", "edition": 1, "modified": "2021-01-05T00:00:00", "id": "RST:9344C42A-523D-33EA-887F-20C09A03C2E9", "href": "", "published": "2021-01-21T00:00:00", "title": "RST Threat feed. IOC: https://insignificantfinecore.testmail4.repl.co/x86", "type": "rst", "cvss": {}}, {"lastseen": "2021-01-20T00:00:00", "bulletinFamily": "ioc", "cvelist": [], "description": "Found **http://85[.]204.116.43/sbidiot/x86** in [RST Threat Feed](https://rstcloud.net/profeed) with score **21**.\n First seen: 2021-01-18T03:00:00, Last seen: 2021-01-20T03:00:00.\n IOC tags: **malware**.\nIOC could be a **False Positive** (Resource unavailable).\n[https://rstcloud.net/](https://rstcloud.net/)", "edition": 1, "modified": "2021-01-18T00:00:00", "id": "RST:6CBE3CAB-C440-37B8-A03B-964930E8C5CC", "href": "", "published": "2021-01-21T00:00:00", "title": "RST Threat feed. IOC: http://85.204.116.43/sbidiot/x86", "type": "rst", "cvss": {}}, {"lastseen": "2021-01-20T00:00:00", "bulletinFamily": "ioc", "cvelist": [], "description": "Found **http://t[.]honker.info:8/x86.exe** in [RST Threat Feed](https://rstcloud.net/profeed) with score **52**.\n First seen: 2021-01-05T03:00:00, Last seen: 2021-01-20T03:00:00.\n IOC tags: **malware**.\n[https://rstcloud.net/](https://rstcloud.net/)", "edition": 1, "modified": "2021-01-05T00:00:00", "id": "RST:34320B0B-C1DB-3B39-A82D-1276433E2A50", "href": "", "published": "2021-01-21T00:00:00", "title": "RST Threat feed. IOC: http://t.honker.info:8/x86.exe", "type": "rst", "cvss": {}}, {"lastseen": "2021-01-20T00:00:00", "bulletinFamily": "ioc", "cvelist": [], "description": "Found **http://185[.]239.242.88/x0ox0ox0oxdefault/z0r0.x86** in [RST Threat Feed](https://rstcloud.net/profeed) with score **61**.\n First seen: 2021-01-19T03:00:00, Last seen: 2021-01-20T03:00:00.\n IOC tags: **malware**.\n[https://rstcloud.net/](https://rstcloud.net/)", "edition": 1, "modified": "2021-01-19T00:00:00", "id": "RST:04E854C3-36BD-3706-A803-41218E9E4761", "href": "", "published": "2021-01-21T00:00:00", "title": "RST Threat feed. IOC: http://185.239.242.88/x0ox0ox0oxdefault/z0r0.x86", "type": "rst", "cvss": {}}, {"lastseen": "2021-01-20T00:00:00", "bulletinFamily": "ioc", "cvelist": [], "description": "Found **https://damagedessentialtelecommunications[.]testmail4.repl.co/src/x86** in [RST Threat Feed](https://rstcloud.net/profeed) with score **52**.\n First seen: 2021-01-05T03:00:00, Last seen: 2021-01-20T03:00:00.\n IOC tags: **malware**.\nIt was found that the IOC is used by: **bashlite**.\n[https://rstcloud.net/](https://rstcloud.net/)", "edition": 1, "modified": "2021-01-05T00:00:00", "id": "RST:FD843859-E07F-3CD0-937A-3A164A942FAA", "href": "", "published": "2021-01-21T00:00:00", "title": "RST Threat feed. IOC: https://damagedessentialtelecommunications.testmail4.repl.co/src/x86", "type": "rst", "cvss": {}}, {"lastseen": "2021-01-20T00:00:00", "bulletinFamily": "ioc", "cvelist": [], "description": "Found **http://45[.]148.120.88/bins/x86** in [RST Threat Feed](https://rstcloud.net/profeed) with score **72**.\n First seen: 2021-01-19T03:00:00, Last seen: 2021-01-20T03:00:00.\n IOC tags: **malware**.\nIt was found that the IOC is used by: **mirai**.\n[https://rstcloud.net/](https://rstcloud.net/)", "edition": 1, "modified": "2021-01-19T00:00:00", "id": "RST:7A5E8E46-33F6-3CBE-A009-B2DFF200CE6D", "href": "", "published": "2021-01-21T00:00:00", "title": "RST Threat feed. IOC: http://45.148.120.88/bins/x86", "type": "rst", "cvss": {}}, {"lastseen": "2021-01-20T00:00:00", "bulletinFamily": "ioc", "cvelist": [], "description": "Found **http://45[.]148.120.88/sbidiot/x86** in [RST Threat Feed](https://rstcloud.net/profeed) with score **21**.\n First seen: 2021-01-20T03:00:00, Last seen: 2021-01-20T03:00:00.\n IOC tags: **malware**.\nIOC could be a **False Positive** (Resource unavailable).\n[https://rstcloud.net/](https://rstcloud.net/)", "edition": 1, "modified": "2021-01-20T00:00:00", "id": "RST:3F11DCFE-38E5-3282-AF4B-3B5EF4CB6BAB", "href": "", "published": "2021-01-21T00:00:00", "title": "RST Threat feed. IOC: http://45.148.120.88/sbidiot/x86", "type": "rst", "cvss": {}}, {"lastseen": "2021-01-20T00:00:00", "bulletinFamily": "ioc", "cvelist": [], "description": "Found **http://5[.]2.64.199/x86** in [RST Threat Feed](https://rstcloud.net/profeed) with score **70**.\n First seen: 2021-01-18T03:00:00, Last seen: 2021-01-20T03:00:00.\n IOC tags: **malware**.\nIt was found that the IOC is used by: **bashlite**.\n[https://rstcloud.net/](https://rstcloud.net/)", "edition": 1, "modified": "2021-01-18T00:00:00", "id": "RST:8B1FB07A-FDA7-3993-8C56-FD76CAE7B8EA", "href": "", "published": "2021-01-21T00:00:00", "title": "RST Threat feed. IOC: http://5.2.64.199/x86", "type": "rst", "cvss": {}}, {"lastseen": "2021-01-20T00:00:00", "bulletinFamily": "ioc", "cvelist": [], "description": "Found **http://104[.]140.242.38/sbidiot/x86** in [RST Threat Feed](https://rstcloud.net/profeed) with score **15**.\n First seen: 2021-01-05T03:00:00, Last seen: 2021-01-20T03:00:00.\n IOC tags: **malware**.\nIOC could be a **False Positive** (Resource unavailable).\n[https://rstcloud.net/](https://rstcloud.net/)", "edition": 1, "modified": "2021-01-05T00:00:00", "id": "RST:406BECDF-453F-3C34-BF18-A276E35883EA", "href": "", "published": "2021-01-21T00:00:00", "title": "RST Threat feed. IOC: http://104.140.242.38/sbidiot/x86", "type": "rst", "cvss": {}}, {"lastseen": "2021-01-20T00:00:00", "bulletinFamily": "ioc", "cvelist": [], "description": "Found **http://194[.]15.36.208/bins/oblivion121.x86** in [RST Threat Feed](https://rstcloud.net/profeed) with score **18**.\n First seen: 2021-01-17T03:00:00, Last seen: 2021-01-20T03:00:00.\n IOC tags: **malware**.\nIOC could be a **False Positive** (Resource unavailable).\n[https://rstcloud.net/](https://rstcloud.net/)", "edition": 1, "modified": "2021-01-17T00:00:00", "id": "RST:9A088DCD-4EBC-3300-89F5-51CA11AE83A3", "href": "", "published": "2021-01-21T00:00:00", "title": "RST Threat feed. IOC: http://194.15.36.208/bins/oblivion121.x86", "type": "rst", "cvss": {}}], "nessus": [{"lastseen": "2021-01-21T13:45:58", "description": "SunOS 5.10_x86: Apache 2.4 Patch.\nDate this patch was last updated by Sun : Jan/18/21", "edition": 1, "cvss3": {}, "published": "2021-01-20T00:00:00", "title": "Solaris 10 (x86) : 152644-10", "type": "nessus", "bulletinFamily": "scanner", "cvelist": [], "modified": "2021-01-20T00:00:00", "cpe": ["p-cpe:/a:oracle:solaris:10:152644", "cpe:/o:oracle:solaris:10"], "id": "SOLARIS10_X86_152644-10.NASL", "href": "https://www.tenable.com/plugins/nessus/145096", "sourceData": "#\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text in this plugin was\n# extracted from the Oracle SunOS Patch Updates.\n#\ninclude(\"compat.inc\");\n\nif (description)\n{\n script_id(145096);\n script_version(\"1.1\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/01/20\");\n\n script_name(english:\"Solaris 10 (x86) : 152644-10\");\n script_summary(english:\"Check for patch 152644-10\");\n\n script_set_attribute(\n attribute:\"synopsis\",\n value:\"The remote host is missing Sun Security Patch number 152644-10\"\n );\n script_set_attribute(\n attribute:\"description\",\n value:\n\"SunOS 5.10_x86: Apache 2.4 Patch.\nDate this patch was last updated by Sun : Jan/18/21\"\n );\n script_set_attribute(\n attribute:\"see_also\",\n value:\"https://getupdates.oracle.com/readme/152644-10\"\n );\n script_set_attribute(attribute:\"solution\", value:\"Install patch 152644-10 or higher\");\n script_set_attribute(attribute:\"risk_factor\", value:\"High\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:oracle:solaris:10:152644\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:oracle:solaris:10\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2021/01/18\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2021/01/18\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2021/01/20\");\n script_set_attribute(attribute:\"generated_plugin\", value:\"current\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_copyright(english:\"This script is Copyright (C) 2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n script_family(english:\"Solaris Local Security Checks\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/Solaris/showrev\");\n\n exit(0);\n}\n\n\ninclude(\"audit.inc\");\ninclude(\"global_settings.inc\");\ninclude(\"misc_func.inc\");\ninclude(\"solaris.inc\");\n\nshowrev = get_kb_item(\"Host/Solaris/showrev\");\nif (empty_or_null(showrev)) audit(AUDIT_OS_NOT, \"Solaris\");\nos_ver = pregmatch(pattern:\"Release: (\\d+.(\\d+))\", string:showrev);\nif (empty_or_null(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, \"Solaris\");\nfull_ver = os_ver[1];\nos_level = os_ver[2];\nif (full_ver != \"5.10\") audit(AUDIT_OS_NOT, \"Solaris 10\", \"Solaris \" + os_level);\npackage_arch = pregmatch(pattern:\"Application architecture: (\\w+)\", string:showrev);\nif (empty_or_null(package_arch)) audit(AUDIT_UNKNOWN_ARCH);\npackage_arch = package_arch[1];\nif (package_arch != \"i386\") audit(AUDIT_ARCH_NOT, \"i386\", package_arch);\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\n\nif (solaris_check_patch(release:\"5.10_x86\", arch:\"i386\", patch:\"152644-10\", obsoleted_by:\"\", package:\"SUNWapch2S\", version:\"11.10.0,REV=2005.01.08.01.09\") < 0) flag++;\nif (solaris_check_patch(release:\"5.10_x86\", arch:\"i386\", patch:\"152644-10\", obsoleted_by:\"\", package:\"SUNWapch2d\", version:\"11.10.0,REV=2005.01.08.01.09\") < 0) flag++;\nif (solaris_check_patch(release:\"5.10_x86\", arch:\"i386\", patch:\"152644-10\", obsoleted_by:\"\", package:\"SUNWapch2r\", version:\"11.10.0,REV=2005.01.08.01.09\") < 0) flag++;\nif (solaris_check_patch(release:\"5.10_x86\", arch:\"i386\", patch:\"152644-10\", obsoleted_by:\"\", package:\"SUNWapch2u\", version:\"11.10.0,REV=2005.01.08.01.09\") < 0) flag++;\n\nif (flag) {\n security_report_v4(\n port : 0,\n severity : SECURITY_HOLE,\n extra : solaris_get_report()\n );\n} else {\n patch_fix = solaris_patch_fix_get();\n if (!empty_or_null(patch_fix)) audit(AUDIT_PATCH_INSTALLED, patch_fix, \"Solaris 10\");\n tested = solaris_pkg_tests_get();\n if (!empty_or_null(tested)) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n audit(AUDIT_PACKAGE_NOT_INSTALLED, \"SUNWapch2S / SUNWapch2d / SUNWapch2r / SUNWapch2u\");\n}\n", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2021-01-21T13:45:56", "description": "SunOS 5.10_x86: SunFreeware ntp patch.\nDate this patch was last updated by Sun : Jan/18/21", "edition": 1, "cvss3": {}, "published": "2021-01-20T00:00:00", "title": "Solaris 10 (x86) : 143726-14", "type": "nessus", "bulletinFamily": "scanner", "cvelist": [], "modified": "2021-01-20T00:00:00", "cpe": ["p-cpe:/a:oracle:solaris:10:143726", "p-cpe:/a:oracle:solaris:10:143728", "cpe:/o:oracle:solaris:10"], "id": "SOLARIS10_X86_143726-14.NASL", "href": "https://www.tenable.com/plugins/nessus/145172", "sourceData": "#\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text in this plugin was\n# extracted from the Oracle SunOS Patch Updates.\n#\ninclude(\"compat.inc\");\n\nif (description)\n{\n script_id(145172);\n script_version(\"1.1\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/01/20\");\n\n script_name(english:\"Solaris 10 (x86) : 143726-14\");\n script_summary(english:\"Check for patch 143726-14\");\n\n script_set_attribute(\n attribute:\"synopsis\",\n value:\"The remote host is missing Sun Security Patch number 143726-14\"\n );\n script_set_attribute(\n attribute:\"description\",\n value:\n\"SunOS 5.10_x86: SunFreeware ntp patch.\nDate this patch was last updated by Sun : Jan/18/21\"\n );\n script_set_attribute(\n attribute:\"see_also\",\n value:\"https://getupdates.oracle.com/readme/143726-14\"\n );\n script_set_attribute(attribute:\"solution\", value:\"Install patch 143726-14 or higher\");\n script_set_attribute(attribute:\"risk_factor\", value:\"High\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:oracle:solaris:10:143726\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:oracle:solaris:10:143728\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:oracle:solaris:10\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2021/01/18\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2021/01/18\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2021/01/20\");\n script_set_attribute(attribute:\"generated_plugin\", value:\"current\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_copyright(english:\"This script is Copyright (C) 2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n script_family(english:\"Solaris Local Security Checks\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/Solaris/showrev\");\n\n exit(0);\n}\n\n\ninclude(\"audit.inc\");\ninclude(\"global_settings.inc\");\ninclude(\"misc_func.inc\");\ninclude(\"solaris.inc\");\n\nshowrev = get_kb_item(\"Host/Solaris/showrev\");\nif (empty_or_null(showrev)) audit(AUDIT_OS_NOT, \"Solaris\");\nos_ver = pregmatch(pattern:\"Release: (\\d+.(\\d+))\", string:showrev);\nif (empty_or_null(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, \"Solaris\");\nfull_ver = os_ver[1];\nos_level = os_ver[2];\nif (full_ver != \"5.10\") audit(AUDIT_OS_NOT, \"Solaris 10\", \"Solaris \" + os_level);\npackage_arch = pregmatch(pattern:\"Application architecture: (\\w+)\", string:showrev);\nif (empty_or_null(package_arch)) audit(AUDIT_UNKNOWN_ARCH);\npackage_arch = package_arch[1];\nif (package_arch != \"i386\") audit(AUDIT_ARCH_NOT, \"i386\", package_arch);\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\n\nif (solaris_check_patch(release:\"5.10_x86\", arch:\"i386\", patch:\"143726-14\", obsoleted_by:\"\", package:\"SUNWntp4S\", version:\"11.10.0,REV=2009.07.02.12.26\") < 0) flag++;\nif (solaris_check_patch(release:\"5.10_x86\", arch:\"i386\", patch:\"143726-14\", obsoleted_by:\"\", package:\"SUNWntp4r\", version:\"11.10.0,REV=2009.07.02.12.26\") < 0) flag++;\nif (solaris_check_patch(release:\"5.10_x86\", arch:\"i386\", patch:\"143726-14\", obsoleted_by:\"\", package:\"SUNWntp4u\", version:\"11.10.0,REV=2009.07.02.12.26\") < 0) flag++;\n\nif (flag) {\n security_report_v4(\n port : 0,\n severity : SECURITY_HOLE,\n extra : solaris_get_report()\n );\n} else {\n patch_fix = solaris_patch_fix_get();\n if (!empty_or_null(patch_fix)) audit(AUDIT_PATCH_INSTALLED, patch_fix, \"Solaris 10\");\n tested = solaris_pkg_tests_get();\n if (!empty_or_null(tested)) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n audit(AUDIT_PACKAGE_NOT_INSTALLED, \"SUNWntp4S / SUNWntp4r / SUNWntp4u\");\n}\n", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2021-01-21T10:31:56", "description": " - x86: Check IFUNC definition in unrelocated executable\n [BZ #20019]\n\n - x86: Set header.feature_1 in TCB for always-on CET [BZ\n #27177]\n\n - x86-64: Avoid rep movsb with short distance [BZ #27130]\n\n - Fix for CVE-2019-25013 buffer overrun in EUC-KR\n conversion module (bz #24973)\n\n - Add NEWS entry for CVE-2020-29562 (BZ #26923)\n\n - iconv: Fix incorrect UCS4 inner loop bounds (BZ#26923)\n\n - tests-mcheck: New variable to run tests with\n MALLOC_CHECK_=3\n\n - iconv: Accept redundant shift sequences in IBM1364 [BZ\n #26224]\n\n - sh: Add sh4 fpu Implies folder\n\n - aarch64: Fix DT_AARCH64_VARIANT_PCS handling [BZ #26798]\n\n - x86: Optimizing memcpy for AMD Zen architecture.\n\n - Reversing calculation of\n __x86_shared_non_temporal_threshold\n\n - AArch64: Use __memcpy_simd on Neoverse N2/V1\n\n - [AArch64] Improve integer memcpy\n\n - AArch64: Rename IS_ARES to IS_NEOVERSE_N1\n\n - AArch64: Improve backwards memmove performance\n\n - AArch64: Add optimized Q-register memcpy\n\n - AArch64: Align ENTRY to a cacheline\n\n - intl: Handle translation output codesets with suffixes\n [BZ #26383]\n\n - Add NEWS entry for CVE-2016-10228 (bug 19519)\n\n - Rewrite iconv option parsing [BZ #19519]\n\n - powerpc: Fix incorrect cache line size load in memset\n (bug 26332)\n\n - nptl: Zero-extend arguments to SETXID syscalls [BZ\n #26248]\n\n - Disable warnings due to deprecated libselinux symbols\n used by nss and nscd\n\n - Add NEWS entry for CVE-2020-6096 (bug 25620)\n\nNote that Tenable Network Security has extracted the preceding\ndescription block directly from the Fedora update system website.\nTenable has attempted to automatically clean and format it as much as\npossible without introducing additional issues.", "edition": 1, "cvss3": {"score": 8.1, "vector": "AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H"}, "published": "2021-01-20T00:00:00", "title": "Fedora 32 : glibc (2021-6e581c051a)", "type": "nessus", "bulletinFamily": "scanner", "cvelist": ["CVE-2020-29562", "CVE-2016-10228", "CVE-2020-6096", "CVE-2019-25013"], "modified": "2021-01-20T00:00:00", "cpe": ["p-cpe:/a:fedoraproject:fedora:glibc", "cpe:/o:fedoraproject:fedora:32"], "id": "FEDORA_2021-6E581C051A.NASL", "href": "https://www.tenable.com/plugins/nessus/145196", "sourceData": "#\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were \n# extracted from Fedora Security Advisory FEDORA-2021-6e581c051a.\n#\n\ninclude(\"compat.inc\");\n\nif (description)\n{\n script_id(145196);\n script_version(\"1.1\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/01/20\");\n\n script_cve_id(\"CVE-2016-10228\", \"CVE-2019-25013\", \"CVE-2020-29562\", \"CVE-2020-6096\");\n script_xref(name:\"FEDORA\", value:\"2021-6e581c051a\");\n\n script_name(english:\"Fedora 32 : glibc (2021-6e581c051a)\");\n script_summary(english:\"Checks rpm output for the updated package.\");\n\n script_set_attribute(\n attribute:\"synopsis\",\n value:\"The remote Fedora host is missing a security update.\"\n );\n script_set_attribute(\n attribute:\"description\",\n value:\n\" - x86: Check IFUNC definition in unrelocated executable\n [BZ #20019]\n\n - x86: Set header.feature_1 in TCB for always-on CET [BZ\n #27177]\n\n - x86-64: Avoid rep movsb with short distance [BZ #27130]\n\n - Fix for CVE-2019-25013 buffer overrun in EUC-KR\n conversion module (bz #24973)\n\n - Add NEWS entry for CVE-2020-29562 (BZ #26923)\n\n - iconv: Fix incorrect UCS4 inner loop bounds (BZ#26923)\n\n - tests-mcheck: New variable to run tests with\n MALLOC_CHECK_=3\n\n - iconv: Accept redundant shift sequences in IBM1364 [BZ\n #26224]\n\n - sh: Add sh4 fpu Implies folder\n\n - aarch64: Fix DT_AARCH64_VARIANT_PCS handling [BZ #26798]\n\n - x86: Optimizing memcpy for AMD Zen architecture.\n\n - Reversing calculation of\n __x86_shared_non_temporal_threshold\n\n - AArch64: Use __memcpy_simd on Neoverse N2/V1\n\n - [AArch64] Improve integer memcpy\n\n - AArch64: Rename IS_ARES to IS_NEOVERSE_N1\n\n - AArch64: Improve backwards memmove performance\n\n - AArch64: Add optimized Q-register memcpy\n\n - AArch64: Align ENTRY to a cacheline\n\n - intl: Handle translation output codesets with suffixes\n [BZ #26383]\n\n - Add NEWS entry for CVE-2016-10228 (bug 19519)\n\n - Rewrite iconv option parsing [BZ #19519]\n\n - powerpc: Fix incorrect cache line size load in memset\n (bug 26332)\n\n - nptl: Zero-extend arguments to SETXID syscalls [BZ\n #26248]\n\n - Disable warnings due to deprecated libselinux symbols\n used by nss and nscd\n\n - Add NEWS entry for CVE-2020-6096 (bug 25620)\n\nNote that Tenable Network Security has extracted the preceding\ndescription block directly from the Fedora update system website.\nTenable has attempted to automatically clean and format it as much as\npossible without introducing additional issues.\"\n );\n script_set_attribute(\n attribute:\"see_also\",\n value:\"https://bodhi.fedoraproject.org/updates/FEDORA-2021-6e581c051a\"\n );\n script_set_attribute(attribute:\"solution\", value:\"Update the affected glibc package.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:N/I:N/A:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:fedoraproject:fedora:glibc\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:fedoraproject:fedora:32\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2017/03/02\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2021/01/20\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2021/01/20\");\n script_set_attribute(attribute:\"generated_plugin\", value:\"current\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_copyright(english:\"This script is Copyright (C) 2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n script_family(english:\"Fedora Local Security Checks\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/RedHat/release\", \"Host/RedHat/rpm-list\");\n\n exit(0);\n}\n\n\ninclude(\"audit.inc\");\ninclude(\"global_settings.inc\");\ninclude(\"rpm.inc\");\n\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nrelease = get_kb_item(\"Host/RedHat/release\");\nif (isnull(release) || \"Fedora\" >!< release) audit(AUDIT_OS_NOT, \"Fedora\");\nos_ver = pregmatch(pattern: \"Fedora.*release ([0-9]+)\", string:release);\nif (isnull(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, \"Fedora\");\nos_ver = os_ver[1];\nif (! preg(pattern:\"^32([^0-9]|$)\", string:os_ver)) audit(AUDIT_OS_NOT, \"Fedora 32\", \"Fedora \" + os_ver);\n\nif (!get_kb_item(\"Host/RedHat/rpm-list\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\n\ncpu = get_kb_item(\"Host/cpu\");\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\") audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, \"Fedora\", cpu);\n\n\nflag = 0;\nif (rpm_check(release:\"FC32\", reference:\"glibc-2.31-5.fc32\")) flag++;\n\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_HOLE,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, \"glibc\");\n}\n", "cvss": {"score": 7.1, "vector": "AV:N/AC:M/Au:N/C:N/I:N/A:C"}}, {"lastseen": "2021-01-21T10:31:56", "description": " - x86: Check IFUNC definition in unrelocated executable\n [BZ #20019]\n\n - x86: Set header.feature_1 in TCB for always-on CET [BZ\n #27177]\n\n - Update for [BZ #27130] fix\n\n - x86-64: Avoid rep movsb with short distance [BZ #27130]\n\n - Fix for CVE-2019-25013 buffer overrun in EUC-KR\n conversion module (bz #24973)\n\n - tests-mcheck: New variable to run tests with\n MALLOC_CHECK_=3\n\n - iconv: Accept redundant shift sequences in IBM1364 [BZ\n #26224]\n\n - sh: Add sh4 fpu Implies folder\n\n - struct _Unwind_Exception alignment should not depend on\n compiler flags\n\nNote that Tenable Network Security has extracted the preceding\ndescription block directly from the Fedora update system website.\nTenable has attempted to automatically clean and format it as much as\npossible without introducing additional issues.", "edition": 1, "cvss3": {"score": 5.9, "vector": "AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H"}, "published": "2021-01-20T00:00:00", "title": "Fedora 33 : glibc (2021-6feb090c97)", "type": "nessus", "bulletinFamily": "scanner", "cvelist": ["CVE-2019-25013"], "modified": "2021-01-20T00:00:00", "cpe": ["p-cpe:/a:fedoraproject:fedora:glibc", "cpe:/o:fedoraproject:fedora:33"], "id": "FEDORA_2021-6FEB090C97.NASL", "href": "https://www.tenable.com/plugins/nessus/145122", "sourceData": "#\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were \n# extracted from Fedora Security Advisory FEDORA-2021-6feb090c97.\n#\n\ninclude(\"compat.inc\");\n\nif (description)\n{\n script_id(145122);\n script_version(\"1.1\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/01/20\");\n\n script_cve_id(\"CVE-2019-25013\");\n script_xref(name:\"FEDORA\", value:\"2021-6feb090c97\");\n\n script_name(english:\"Fedora 33 : glibc (2021-6feb090c97)\");\n script_summary(english:\"Checks rpm output for the updated package.\");\n\n script_set_attribute(\n attribute:\"synopsis\",\n value:\"The remote Fedora host is missing a security update.\"\n );\n script_set_attribute(\n attribute:\"description\",\n value:\n\" - x86: Check IFUNC definition in unrelocated executable\n [BZ #20019]\n\n - x86: Set header.feature_1 in TCB for always-on CET [BZ\n #27177]\n\n - Update for [BZ #27130] fix\n\n - x86-64: Avoid rep movsb with short distance [BZ #27130]\n\n - Fix for CVE-2019-25013 buffer overrun in EUC-KR\n conversion module (bz #24973)\n\n - tests-mcheck: New variable to run tests with\n MALLOC_CHECK_=3\n\n - iconv: Accept redundant shift sequences in IBM1364 [BZ\n #26224]\n\n - sh: Add sh4 fpu Implies folder\n\n - struct _Unwind_Exception alignment should not depend on\n compiler flags\n\nNote that Tenable Network Security has extracted the preceding\ndescription block directly from the Fedora update system website.\nTenable has attempted to automatically clean and format it as much as\npossible without introducing additional issues.\"\n );\n script_set_attribute(\n attribute:\"see_also\",\n value:\"https://bodhi.fedoraproject.org/updates/FEDORA-2021-6feb090c97\"\n );\n script_set_attribute(attribute:\"solution\", value:\"Update the affected glibc package.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:N/I:N/A:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:fedoraproject:fedora:glibc\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:fedoraproject:fedora:33\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2021/01/04\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2021/01/18\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2021/01/20\");\n script_set_attribute(attribute:\"generated_plugin\", value:\"current\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_copyright(english:\"This script is Copyright (C) 2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n script_family(english:\"Fedora Local Security Checks\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/RedHat/release\", \"Host/RedHat/rpm-list\");\n\n exit(0);\n}\n\n\ninclude(\"audit.inc\");\ninclude(\"global_settings.inc\");\ninclude(\"rpm.inc\");\n\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nrelease = get_kb_item(\"Host/RedHat/release\");\nif (isnull(release) || \"Fedora\" >!< release) audit(AUDIT_OS_NOT, \"Fedora\");\nos_ver = pregmatch(pattern: \"Fedora.*release ([0-9]+)\", string:release);\nif (isnull(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, \"Fedora\");\nos_ver = os_ver[1];\nif (! preg(pattern:\"^33([^0-9]|$)\", string:os_ver)) audit(AUDIT_OS_NOT, \"Fedora 33\", \"Fedora \" + os_ver);\n\nif (!get_kb_item(\"Host/RedHat/rpm-list\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\n\ncpu = get_kb_item(\"Host/cpu\");\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\") audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, \"Fedora\", cpu);\n\n\nflag = 0;\nif (rpm_check(release:\"FC33\", reference:\"glibc-2.32-3.fc33\")) flag++;\n\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_HOLE,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, \"glibc\");\n}\n", "cvss": {"score": 7.1, "vector": "AV:N/AC:M/Au:N/C:N/I:N/A:C"}}]}
