Xiaohei

A vulnerability was detected in stilleshan ServerStatus 1.0/2.0. Impacted is an unknown function of the file server/src/main.cpp of the component Stats Generation. Performing a manipulation of the argument custom results in cross site scripting. It is possible to initiate the attack remotely. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

**Nome do Software Vulnerável e Versões Afetadas** fit2cloud Halo versão 2.21.10 **Descrição** Existe uma vulnerabilidade de falsificação de solicitação entre sites no fit2cloud Halo versão 2.21.10. O problema está relacionado a uma função desconhecida. O ataque pode ser iniciado remotamente e o exploit foi divulgado publicamente. O fornecedor foi informado sobre a divulgação, mas não respondeu. **Recomendações** Atualmente, não há informações sobre uma versão mais recente que contenha uma correção para esta vulnerabilidade.

**Name of the Vulnerable Software and Affected Versions** FFmpeg version 3.3.3 **Description** The issue is related to a lack of an End of File (EOF) check in the `read tfra()` function, which can cause huge CPU and memory consumption. This occurs when a crafted MOV file with a large `item count` field in the header but insufficient backing data is processed, leading to a loop that consumes significant resources. The vulnerability can be exploited by a remote attacker to cause a denial of service. **Recommendations** For FFmpeg version 3.3.3, consider applying a patch or updating to a newer version that includes a fix for the `read tfra()` function to add an EOF check and prevent excessive resource consumption. As a temporary workaround, consider restricting the processing of MOV files with large `item count` fields to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** FFmpeg versions 2.4 through 3.3.3 **Description** The issue is related to errors in resource management in the `mxf read index entry array` function of the FFmpeg library. It can be exploited by a remote attacker to cause consumption of computational resources and denial of service using a specially crafted MXF file. This file requires a large value in the `nb index entries` field in the header but does not contain sufficient backing data. As a result, the loop consumes significant CPU resources due to the lack of an End of File (EOF) check. If there are multiple applicable data segments in the crafted MXF file, this large loop can be invoked multiple times. **Recommendations** For FFmpeg versions 2.4 through 3.3.3, consider disabling the `mxf read index entry array` function until a patch is available to prevent potential denial of service attacks. Restrict access to MXF files with large `nb index entries` fields in the header to minimize the risk of exploitation. Avoid using the `nb index entries` field in the affected API endpoint until the issue is resolved. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** FFmpeg version 3.3.3 **Description** The issue is related to a lack of an End of File (EOF) check in the asf build simple index() function, which can cause huge CPU consumption. This occurs when a crafted ASF file with a large "ict" field in the header but insufficient backing data is processed, leading to a loop that consumes significant CPU and memory resources. **Recommendations** For FFmpeg version 3.3.3, consider applying a patch or fix that adds an EOF check to the asf build simple index() function to prevent excessive CPU consumption. As a temporary workaround, consider restricting the processing of ASF files with large "ict" fields in the header to minimize the risk of exploitation. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** ImageMagick versions 7.0.7-0 Q16 **Description** The issue is related to errors in resource management in the ReadPSDLayersInternal function of the ImageMagick console graphic editor. Exploitation of this issue may allow a remote attacker to cause significant CPU consumption and denial of service using a specially crafted PSD file. This file requires a large length field in the header but does not contain sufficient backing data, leading to a loop that consumes significant CPU resources due to the lack of an End of File (EOF) check. **Recommendations** For ImageMagick version 7.0.7-0 Q16, consider disabling the ReadPSDLayersInternal function as a temporary workaround until a patch is available. Restrict access to PSD files that may trigger this issue to minimize the risk of exploitation. Avoid using PSD files with large length fields in the header that do not contain sufficient backing data until the issue is resolved. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** FFmpeg versions 2.4 through 3.3.3 **Description** The issue is related to the read data function in libavformat/hls.c, which does not restrict reload attempts for an insufficient list. This allows remote attackers to cause a denial of service by creating an infinite loop. **Recommendations** For FFmpeg version 2.4, update to a version later than 3.3.3 to resolve the issue. For FFmpeg version 3.3.3, update to a version later than 3.3.3 to resolve the issue. As a temporary workaround, consider disabling the `read data` function in libavformat/hls.c until a patch is available.

**Name of the Vulnerable Software and Affected Versions** ImageMagick version 7.0.6-1 Q16 **Description** The issue is related to a lack of an EOF (End of File) check in the ReadXBMImage() function, which can cause huge CPU consumption. This occurs when a crafted XBM file with large rows and columns fields in the header but insufficient backing data is provided, leading to a loop over the rows that consumes significant CPU resources. **Recommendations** For ImageMagick version 7.0.6-1 Q16, consider disabling the ReadXBMImage() function until a patch is available to prevent potential denial of service attacks. Restrict access to XBM files to minimize the risk of exploitation. Avoid using the `ReadXBMImage()` function with untrusted input files until the issue is resolved. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** ImageMagick version 7.0.7-0 Q16 **Description** The issue is related to a lack of an EOF (End of File) check in the ReadPSImage() function, which can cause huge CPU consumption. This occurs when a crafted PSD file with a large "extent" field in the header but insufficient backing data is provided, leading to a loop that consumes significant CPU resources. The vulnerability can be exploited by a remote attacker to cause a denial of service by consuming computational resources. **Recommendations** For ImageMagick version 7.0.7-0 Q16, consider disabling the ReadPSImage() function as a temporary workaround until a patch is available to prevent the exploitation of this issue. Restrict access to PSD files to minimize the risk of exploitation. Avoid using the `length` variable in the affected loop until the issue is resolved. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** GraphicsMagick version 1.3.26 **Description** The issue is related to a denial of service in the `ReadXBMImage()` function, specifically in the "Read hex image data" version==10 case, which can cause large amounts of CPU and memory consumption. This can lead to resource exhaustion, allowing a remote attacker to cause a denial of service. **Recommendations** For GraphicsMagick version 1.3.26, consider disabling the `ReadXBMImage()` function as a temporary workaround to prevent potential denial of service attacks until a patch is available.

**Name of the Vulnerable Software and Affected Versions** FFmpeg version 3.3.3 **Description** The issue is related to a lack of an EOF check in the `cine read header()` function, which can cause huge CPU and memory consumption. This occurs when a crafted CINE file with a large "duration" field in the header but insufficient backing data is provided, leading to excessive resource usage by the image-offset parsing loop. The vulnerability can be exploited by a remote attacker to cause a denial of service. **Recommendations** For FFmpeg version 3.3.3, consider disabling the `cine read header()` function until a patch is available to prevent potential denial of service attacks. Restrict access to CINE files with large "duration" fields to minimize the risk of exploitation. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** FFmpeg versions 3.3.3 **Description** The issue is related to the `ivr read header` function in the FFmpeg multimedia library, specifically in `libavformat/rmdec.c`, and is caused by resource management errors. Exploitation of this issue can allow a remote attacker to cause memory exhaustion and denial of service using a specially crafted IVR file. This file would claim a large `len` field in the header but not contain sufficient backing data, leading to significant CPU resource consumption due to the lack of an End of File (EOF) check in the loop. **Recommendations** For FFmpeg version 3.3.3, as a temporary workaround, consider disabling the `ivr read header` function until a patch is available. Restrict access to files that could potentially exploit this issue to minimize the risk of denial of service. Avoid using crafted IVR files that claim large `len` fields without sufficient backing data until the issue is resolved. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** FFmpeg version 3.3.3 **Description** The issue is related to a lack of an End of File (EOF) check in the `mv read header()` function, which can cause huge CPU and memory consumption. This occurs when a crafted MV file with a large `nb frames` field in the header but insufficient backing data is provided, leading to a loop that consumes significant resources. The exploitation of this issue may allow a remote attacker to cause a denial of service by exhausting memory and CPU resources. **Recommendations** For FFmpeg version 3.3.3, consider applying a patch or updating to a newer version that includes a fix for the `mv read header()` function to add an EOF check, preventing excessive resource consumption. As a temporary workaround, consider restricting the use of the `mv read header()` function or limiting the processing of MV files with large `nb frames` fields to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** FFmpeg version 3.3.3 **Description** The issue is related to a lack of an EOF (End of File) check in the `rl2 read header()` function, which can cause huge CPU and memory consumption. This occurs when a crafted RL2 file with a large `frame count` field in the header but insufficient backing data is provided. The loops for offset and size tables consume significant CPU and memory resources due to the absence of an EOF check. **Recommendations** For FFmpeg version 3.3.3, consider applying a patch or updating to a newer version that includes a fix for the `rl2 read header()` function to add an EOF check and prevent excessive resource consumption. As a temporary workaround, consider restricting the use of the `rl2 read header()` function or limiting the processing of RL2 files with large `frame count` fields to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** FFmpeg version 3.3.3 **Description** The issue is related to a lack of an End of File (EOF) check in the `asf read marker()` function, which can cause significant CPU and memory consumption. This occurs when a crafted ASF file with a large "name len" or "count" field in the header but insufficient backing data is processed, leading to loops over the name and markers consuming huge resources. **Recommendations** For FFmpeg version 3.3.3, consider disabling the `asf read marker()` function as a temporary workaround until a patch is available to prevent potential denial-of-service attacks. Restrict access to ASF files with large "name len" or "count" fields to minimize the risk of exploitation. Avoid using the `name len` and `count` fields in the ASF file header until the issue is resolved.