The Microsoft GDI+ implementation of the EMF format supports records corresponding to the ExtTextOutA() and PolyTextOutA() API functions. Both CEmfPlusEnumState::ExtTextOutA and CEmfPlusEnumState::PolyTextOutA handlers suffer from a security vulnerability in the handling of the 'offDx' record field, which is described in the format specification. The offset is supposed to address an array of 'Chars' (another field in the text records, specifying the number of characters to be displayed) double words, taking up a total of 4 * N bytes. However, instead of verifying that the provided record is sufficiently large to contain 4 * N bytes at the specified offset, it only checks if it can fit 4 bytes (completely ignoring the actual number of characters in the message, which can be larger than 1). This means that if the MultiByteToWideChar() function fails to convert the entire string, the function returns without calling CEmfPlusEnumState::PlayExtTextOut(), which is the function that actually performs the out-of-bound read.
The GDI+ library can handle bitmaps originating from untrusted sources through a variety of attack vectors, like EMF files, which may embed bitmaps in records such as EMR_PLGBLT, EMR_BITBLT, EMR_STRETCHBLT, EMR_STRETCHDIBITS etc. Even though there are some dependencies between the various fields that must be met, the attacker still has almost full control over the values of both bytes_per_row_signed and biHeight. If the bytes_per_row_signed variable holds a negative value and biHeight is larger than 1, then we can get the first_row pointer to point at a nearly arbitrary location relative to the address of pixels_buffer. The exploitation of this bug is additionally facilitated by a flaw in the gdiplus!GetBitmapFromRecord function, which is supposed to check that the EMF record is sufficiently large to fully contain the bitmap data, and is called at the beginning of the BMP-related EMF record handlers, before any BMP parsing actually takes place.
SIEMENS IP-Camera (CVMS2025-IR + CCMS2025) allows to unauthenticated user disclose the username & password remotely by simple request which made by browser. Simply go to the following url: http://host:port/cgi-bin/readfile.cgi?query=ADMINID Should return some javascript variable which contain the credentials and other configuration vars: var Adm_ID="admin"; var Adm_Pass1=“admin”; var Adm_Pass2=“admin”; var Language=“en”; var Logoff_Time="0";
A use-after-free vulnerability exists in the FileReader and Blob objects in the Google Chrome browser. The vulnerability is caused by the improper handling of the FileReader and Blob objects. The vulnerability can be exploited by an attacker to execute arbitrary code in the context of the browser.
Multiple command injection vulnerabilities exist within the incident report file generation functionality as user input is passed to system shell calls without validation. A limited non-administrative user, who by default does not have permissions to add custom MIME types for incident file attachments, can exploit these vulnerabilities to obtain remote code execution on the Incident Manager system as the ‘apache’ user. Multiple SQL injection vulnerabilities exist within the application as user input is passed to database queries without validation. A limited non-administrative user can exploit these vulnerabilities to obtain remote code execution on the Incident Manager system as the ‘apache’ user. Multiple stored cross-site scripting vulnerabilities exist within the application as user input is stored in the database without validation. A limited non-administrative user can exploit these vulnerabilities to obtain remote code execution on the Incident Manager system as the ‘apache’ user.
Authentication for the Nagios Network Analyzer web management interface can be bypassed due to an insecure implementation of the function validating session cookies within the ‘Session.php’ file. As shown below, the application uses a base64 encoded serialized PHP string along with a SHA1 HMAC checksum as the cookie to authenticate and manage user sessions. A sample cookie format is shown below: a:15:{s:10:"session_id";s:32:"325672f137d4e3747a0f9e61a4c867b2";s:10:"ip_address";s:15:"192.168.xxx.xxx"; s:10:"user_agent";s:72:"Mozilla/5.0 (Windows NT 6.3; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0";s:13:"last_activity"; i:1463165417;s:9:"user_data";s:0:"";s:8:"identity";s:11:"nagiosadmin";s:8:"username";s:11:"nagiosadmin";s:5:"email"; s:30:"xxxxxx@security-assessment.com";s:7:"user_id";s:1:"1";s:14:"old_last_login";s:10:"1463163525";s:9:"apiaccess"; s:1:"1";s:6:"apikey";s:40:"6ba11d3f6e84011b3332d7427d0655de64f11d5e";s:8:"lang_code";s:2:"en";s:7:"is_admin";s:1:"1";} The application does not validate the HMAC checksum, allowing an attacker to modify the cookie and bypass authentication.
Authentication for the Nagios Log Server web management interface can be bypassed due to an insecure implementation of the function validating session cookies within the ‘Session.php’ file. As shown below, the application uses a base64 encoded serialized PHP string along with a SHA1 HMAC checksum as the cookie to authenticate and manage user sessions. A sample cookie format is shown below: a:11:{s:10:"session_id";s:32:"4a6dad39cec8d6a5ef5a1a1d231bf9fa";s:10:"ip_address";s:15:"123.123.123.123"; s:10:"user_agent";s:72:"Mozilla/5.0 (Windows NT 6.3; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0"; s:13:"last_activity";i:1463700310;s:9:"user_data";s:0:"";s:7:"user_id";s:1:"1";s:8:"username";s:4:"user"; s:5:"email";s:16:"test@example.com";s:12:"ls_logged_in";i:1;s:10:"apisession";i:1;s:8:"language";s:7:"default";}<SHA1-HMAC-CHECKSUM> The application relies on the validation against the SHA1 HMAC to recognize and destroy invalid session cookies when the cheksum does not match. However, due to an insecure implementation of the HMAC validation, it is possible to bypass the authentication by simply removing the HMAC checksum from the cookie.
A stored XSS vulnerability exists in the Pi-Hole Web Interface, which allows an attacker to inject malicious JavaScript code into the white/black list file. This code will be executed when a user visits the list.php page with the malicious code in the URL parameter.
Lepton CMS versions 2.2.0 and 2.2.1 are vulnerable to PHP Code Injection. The vulnerability exists due to insufficient input validation on the "Database User" input field when entering Lepton CMS setup information using the Install Wizard. A malicious user can input malicious code in the "Database User" field, which is then written to the "config.php" file. This can allow for PHP Remote Command Execution on the Host system. An attacker can make an HTTP GET request to "http://victim-server/upload/install/save.php" to execute the malicious code, or request "http://victim-server/config.php" to view the injected code.
Lepton has feature that lets users install new modules, if malicious user uploads an archive and the module is not valid it will generate an error. However, the malicious archive will still get decompressed and no check is made for ../ characters in the file name allowing in arbitrary PHP files to be placed outside the intended target directory for installed modules. This can then be used to execute remote commands on the affected host system.
Services By CQR