Siemens

UltraVNC revision 1211 contains multiple memory leaks (CWE-665) in VNC server code, which allows an attacker to read stack memory and can be abused for information disclosure. Combined with another vulnerability, it can be used to leak stack memory and bypass ASLR. This attack appears to be exploitable via network connectivity. These vulnerabilities have been fixed in revision 1212.Show less

UltraVNC revision 1211 has a stack buffer overflow vulnerability in VNC server code inside file transfer request handler, which can result in Denial of Service (DoS). This attack appears to be exploitable via network connectivity. This vulnerability has been fixed in revision 1212.Show less

UltraVNC revision 1211 has multiple improper null termination vulnerabilities in VNC server code, which result in out-of-bound data being accessed by remote users. This attack appears to be exploitable via network connectivity. These vulnerabilities have been fixed in revision 1212.Show less

UltraVNC revision 1211 has a heap buffer overflow vulnerability in VNC server code inside file transfer offer handler, which can potentially in result code execution. This attack appears to be exploitable via network connectivity. This vulnerability has been fixed in revision 1212.Show less

UltraVNC revision 1211 has a heap buffer overflow vulnerability in VNC server code inside file transfer request handler, which can potentially result in code execution. This attack appears to be exploitable via network connectivity. This vulnerability has been fixed in revision 1212.Show less

UltraVNC revision 1211 has multiple off-by-one vulnerabilities in VNC server code, which can potentially result in code execution. This attack appears to be exploitable via network connectivity. These vulnerabilities have been fixed in revision 1212.Show less

UltraVNC revision 1211 has a heap buffer overflow vulnerability in VNC server code inside file transfer handler, which can potentially result code execution. This attack appears to be exploitable via network connectivity. This vulnerability has been fixed in revision 1212.Show less

UltraVNC revision 1206 has stack-based Buffer overflow vulnerability in VNC client code inside FileTransfer module, which leads to a denial of service (DoS) condition. This attack appear to be exploitable via network connectivity. This vulnerability has been fixed in revision 1207.Show less

UltraVNC revision 1206 has multiple off-by-one vulnerabilities in VNC client code connected with improper usage of ClientConnection::ReadString function, which can potentially result code execution. This attack appears to be exploitable via network connectivity. These vulnerabilities have been fixed in revision 1207.Show less

UltraVNC revision 1205 has stack-based buffer overflow vulnerability in VNC client code inside ShowConnInfo routine, which leads to a denial of service (DoS) condition. This attack appear to be exploitable via network connectivity. User interaction is required to trigger this vulnerability. This vulnerability has been fixed in revision 1206.Show less

UltraVNC revision 1203 has multiple heap buffer overflow vulnerabilities in VNC client code inside Ultra decoder, which results in code execution. This attack appears to be exploitable via network connectivity. These vulnerabilities have been fixed in revision 1204.Show less

UltraVNC revision 1198 contains multiple memory leaks (CWE-655) in VNC client code, which allow an attacker to read stack memory and can be abused for information disclosure. Combined with another vulnerability, it can be used to leak stack memory and bypass ASLR. This attack appears to be exploitable via network connectivity. These vulnerabilities have been fixed in revision 1199.Show less

UltraVNC revision 1198 has a heap buffer overflow vulnerability in VNC client code which results code execution. This attack appears to be exploitable via network connectivity. This vulnerability has been fixed in revision 1199.Show less

libcurl versions from 7.36.0 to before 7.64.0 are vulnerable to a stack-based buffer overflow. The function creating an outgoing NTLM type-3 header (`lib/vauth/ntlm.c:Curl_auth_create_ntlm_type3_message()`), generates the request HTTP header contents based on previously received data. The check that exists to prevent the local buffer from getting overflowed is implemented wrongly (using unsigned math) and as such it does not prevent the overflow from happening. This output data can grow larger than the local buffer if very large 'nt response' data is extracted from a previous NTLMv2 header provided by the malicious or broken HTTP server. Such a 'large value' needs to be around 1000 bytes or more. The actual payload data copied to the target buffer comes from the NTLMv2 type-2 response header.Show less

libcurl versions from 7.36.0 to before 7.64.0 is vulnerable to a heap buffer out-of-bounds read. The function handling incoming NTLM type-2 messages (`lib/vauth/ntlm.c:ntlm_decode_type2_target`) does not validate incoming data correctly and is subject to an integer overflow vulnerability. Using that overflow, a malicious or broken NTLM server could trick libcurl to accept a bad length + offset combination that would lead to a buffer read out-of-bounds.Show less

An exploitable heap overflow vulnerability exists in the WkbProgramLow function of WibuKey Network server management, version 6.40.2402.500. A specially crafted TCP packet can cause a heap overflow, potentially leading to remote code execution. An attacker can send a malformed TCP packet to trigger this vulnerability.Show less

An issue was discovered in OpenSSH 7.9. Due to the scp implementation being derived from 1983 rcp, the server chooses which files/directories are sent to the client. However, the scp client only performs cursory validation of the object name returned (only directory traversal attacks are prevented). A malicious scp server (or Man-in-The-Middle attacker) can overwrite arbitrary files in the scp client target directory. If recursive operation (-r) is performed, the server can manipulate subdirectories as well (for example, to overwrite the .ssh/authorized_keys file).Show less

In OpenSSH 7.9, due to accepting and displaying arbitrary stderr output from the server, a malicious server (or Man-in-The-Middle attacker) can manipulate the client output, for example to use ANSI control codes to hide additional files being transferred.Show less

An issue was discovered in OpenSSH 7.9. Due to missing character encoding in the progress display, a malicious server (or Man-in-The-Middle attacker) can employ crafted object names to manipulate the client output, e.g., by using ANSI control codes to hide additional files being transferred. This affects refresh_progress_meter() in progressmeter.c.Show less