Currently browsing: Security

Overview
The uClibc and uClibc-ng libraries are vulnerable to DNS cache poisoning due to the use of predicatble DNS transaction IDs when making DNS requests. This vulnerability can allow an attacker to perform DNS cache poisoning attacks against a vulnerable environment.
Description
The uClibc and the Uclibc-ng software are lightweight C standard libraries intended for use in embedded systems and mobile devices. The uClibc library has not been updated since May of 2012. The newer uClibc-ng is the currently maintained fork of uClibc, as announced on the OpenWRT mailing list in July 2014.
Researchers at the Nozomi Networks Security Research Team discovered that all existing versions of uClibc and uClibc-ng libraries are vulnerable to DNS cache poisoning. These libraries do not employ any randomization in the DNS Transaction ID (DNS TXID) field when creating a new DNS request. This can allow an attacker to send maliciously crafted DNS packets to corrupt the DNS cache with invalid entries and redirect users to arbitrary sites. As uClibc and uClibc-ng are used in devices such as home routers and firewalls, an attacker can perform attacks against multiple users in a shared network environment that relies on DNS responses from the vulnerable device.
The DNS cache poisoning scenarios and defenses are discussed in IETF RFC5452.
Impact
The lack of DNS response validation can allow an attacker to use unsolicited DNS responses to poison the DNS cache and redirect users to malicious sites.
Solution
Apply a patch
If your vendor has developed a patched version of uClibc or uClibc-ng to address this issue, apply the updates provided by your vendor.
Product Developers
If you have a forked or customized version of uClibc or uClibc-ng, develop or adopt a patch to ensure the dns_lookup function provides adequate randomization of DNS TXID’s while making DNS requests. Review and consider applying the patch has been made available in patchwork repository of uClibc-ng with VU#638879 tag.
Follow security best practices
Consider the following security best-practices to protect DNS infrastructure:
Prevent direct exposure of IoT devices and lightweight devices over the Internet to minimize attacks against a caching DNS server.
Provide secure DNS recursion service with features such as DNSSEC validation and the interim 0x20-bit encoding as part of enterprise DNS recursion services where applicable.
Implement a Secure By Default configuration suitable for your operating environment (e.g., disable caching on embedded IoT devices when an upstream caching resolver is available).
Acknowledgements
Thanks to the Nozomi Networks Security Research Team for this report
This document was written by Vijay Sarvepalli and Timur Snoke.

Overview
Tychon contains a privilege escalation vulnerability due to the use of an OPENSSLDIR variable that specifies a location where an unprivileged Windows user may be able to place files.
Description
Tychon includes an OpenSSL component that specifies an OPENSSLDIR variable as a subdirectory that my be controllable by an unprivileged user on Windows. Tychon contains a privileged service that uses this OpenSSL component. A user who can place a specially-crafted openssl.cnf file at an appropriate path may be able to achieve arbitrary code execution with SYSTEM privileges.
Impact
By placing a specially-crafted openssl.cnf in a location used by Tychon, an unprivileged user may be able to execute arbitrary code with SYSTEM privileges on a Windows system with the vulnerable Tychon software installed.
Solution
Apply an update
This issue is addressed in Tychon 1.7.857.82
Acknowledgements
This document was written by Will Dormann.

Overview
Prior to version 5.14, Qt hard-codes the qt_prfxpath value to a fixed value, which may lead to privilege escalation vulnerabilities in Windows software that uses Qt.
Description
Prior to version 5.14, Qt hard-codes the qt_prfxpath value to a value that reflects the path where Qt exists on the system that was used to build Qt. For example, it may refer to a specific subdirectory within C:Qt, which is the default installation location for Qt on Windows. If software that is built with Qt runs with privileges on a Windows system, this may allow for privilege escalation due to the fact that Windows by default allows unprivileged users to create subdirectories off of the root C: drive location.
In 2015, a patch was made to windeployqt to strip out any existing qt_prfxpath value from Qt5Core.dll. If Windows software that uses Qt prior to version 5.14 is not properly packaged using windeployqt, then it may be vulnerable to privilege escalation.
Impact
By placing a file in an appropriate location on a Windows system, an unprivileged attacker may be able to execute arbitrary code with the privileges of the software that uses Qt.
Solution
Apply an update
This issue is addressed in Qt 5.14. Starting with this version, Qt no longer hard-codes the qt_prfxpath value in Qt5Core.dll.
Run windeployqt to prepare Windows Qt software for deployment
The windeployqt utility will replace the qt_prfxpath value in the Qt core DLL with the value of ., which helps prevent this path from being used to achieve privilege escalation.
Acknowledgements
This document was written by Will Dormann.

Overview
The Spring Framework insecurely handles PropertyDescriptor objects, which may allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable system.
Description
The Spring Framework is a Java framework that can be used to create applications such as web applications. Due to improper handling of PropertyDescriptor objects used with data binding, Java applications written with Spring may allow for the execution of arbitrary code.
Exploit code that targets affected WAR-packaged Java code for tomcat servers is publicly available.
NCSC-NL has a list of products and their statuses with respect to this vulnerability.
Impact
By providing crafted data to a Spring Java application, such as a web application, an attacker may be able to execute arbitrary code with the privileges of the affected application. Depending on the application, exploitation may be possible by a remote attacker without requiring authentication.
Solution
Apply an update
This issue is addressed in Spring Framework 5.3.18 and 5.2.20. Please see the Spring Framework RCE Early Announcement for more details.
Acknowledgements
This issue was publicly disclosed by heige.
This document was written by Will Dormann