Feliratkozás hírcsatorna csatornájára
CERT publishes vulnerability advisories called "Vulnerability Notes." Vulnerability Notes include summaries, technical details, remediation information, and lists of affected vendors. Many vulnerability notes are the result of private coordination and disclosure efforts.
Frissítve: 29 perc 1 másodperc

VU#174059: GRUB2 bootloader is vulnerable to buffer overflow

sze, 07/29/2020 - 19:02

The GRUB2 boot loader is vulnerable to buffer overflow, which results in arbitrary code execution during the boot process, even when Secure Boot is enabled.


GRUB2 is a multiboot boot loader that replaced GRUB Legacy in 2012. A boot loader is the first program that runs upon boot and loads the operating system. Many vendors also use a shim, a signed software package that contains the vendor’s certificate and code that verifies and runs the boot loader. This means that firmware Certificate Authority providers can just sign the shim as opposed to all of the other supported programs.

GRUB2 is vulnerable to a buffer overflow when parsing content from the GRUB2 configuration file (grub.cfg). This configuration file is an external file commonly located in the EFI System Partition and can therefore be modified by an attacker with administrator privileges without altering the integrity of the signed vendor shim and GRUB2 boot loader executables. This could allow an authenticated, local attacker to modify the contents of the GRUB2 configuration file to ensure that the attacker's chosen code is run before the operating system is loaded. This could allow the attacker to gain persistence on the device, even with Secure Boot enabled. All versions of GRUB2 that load commands from an external grub.cfg configuration file are vulnerable.


An authenticated, local attacker could modify the contents of the GRUB2 configuration file to execute arbitrary code that bypasses signature verification. This could allow the attacker to gain persistence on the device, even with Secure Boot enabled. Because the attacker's code runs before the operating system, the attacker could control how the operating system is loaded, directly patch the operating system, or even direct the bootloader to alternate OS images. All versions of GRUB2 that load commands from an external grub.cfg configuration file are vulnerable.


Apply an update

Update GRUB2 to the latest version to address this vulnerability. Linux distributions and other vendors using GRUB2 will need to update their installers, boot loaders, and shims. New shims will need to be signed by the Microsoft 3rd Party UEFI Certificate Authority. Administrators of affected devices will need to update installed versions of operating systems as well as installer images, including disaster recovery media. Until all affected versions are added to the dbx revocation list, an attacker would be able to use a vulnerable version of shim and GRUB2. Eventually the UEFI revocation list (dbx) needs to be updated in the firmware of each affected system to prevent running this vulnerable code during boot.


Thanks to Mickey Shkatov and Jesse Michael from Eclypsium for reporting this vulnerability.

This document was written by Madison Oliver.

Kategóriák: Biztonsági hírek

VU#290915: F5 BIG-IP contains multiple vulnerabilities including unauthenticated remote command execution

sze, 07/08/2020 - 22:03

F5 BIG-IP provides a Traffic Management User Interface (TMUI), also referred to as the Configuration utility, that has multiple vulnerabilities including a remotely exploitable command injection vulnerability that can be used to execute arbitrary commands and subsequently take control of a vulnerable system.


F5 BIG-IP devices provide load-balancing capability to application services such as HTTP and DNS. The F5 BIG-IP TMUI management web interface improperly neutralizes untrusted user input and can be abused by unauthenticated remote attackers to perform malicious activities such as cross-site scripting (XSS), cross-site request forgery (CSRF), and command injection CWE-74. F5 has also announced that BIG-IP devices do not properly enforce access controls to sensitive configuration files that be read and overwritten by an authenticated user via Secure Copy (SCP). The vulnerability identified by CVE-2020-0592 can be abused to achieve arbitrary code execution on the target device with root privileges.

Underlying causes and factors in these vulnerabilities include:

F5 recommends that the TMUI web interface should be accessible only from a secure or an out-of-band network and not directly from the Internet (K13092). However, many installations, as observed by Bad Packets, do not seem to follow this recommendation.


An unauthenticated attacker with network access to the TMUI may be able to execute arbitrary system commands, create or delete files, disable services, and subsequently execute arbitrary code with high privileges such as root. An authenticated user is also be able to perform unexpected activities such as changing configuration files on a vulnerable device.

Solution Apply updates

F5 has provided updated software for the several impacted versions of BIG-IP devices. Note that BIG-IP appliances as well as virtual instances are also vulnerable as identified by F5 advisories. It is highly recommended that you upgrade to the latest secure and stable software provided by F5. These updates are essential to your device's security, even if the TMUI is not accessible over the Internet. The upgrade reduces the risk to your device being compromised using CSRF or XSS attacks.


In many cases, an attack against BIG-IP's recent vulnerabilities require access to TMUI. Blocking or disabling access to TMUI from untrusted networks is highly recommended. F5 has also provided multiple temporary workaround options in their advisory.


Several of these vulnerabilities were reported by Mikhail Klyuchnikov of Positive Technologies, who worked with F5 on a coordinated disclosure.

This document was written by Vijay Sarvepalli.

Kategóriák: Biztonsági hírek

VU#576779: Netgear httpd upgrade_check.cgi stack buffer overflow

p, 06/26/2020 - 21:20

Multiple Netgear devices contain a stack buffer overflow in the httpd web server's handling of upgrade_check.cgi, which may allow for unauthenticated remote code execution with root privileges.


Many Netgear devices contain an embedded web server, which is provided by the httpd process, to provide administrative capabilities. On multiple Netgear devices, this code fails to properly validate the header size provided to the upgrade_check.cgi handler. Despite copying the header to a fixed-size buffer on the stack, the vulnerable code copies an attacker-provided count of bytes from attacker-provided data. This allows for remote code execution by way of stack buffer overflow. This vulnerability is exacerbated by a number of issues:

  1. The httpd process runs with root privileges.
  2. Stack cookies, which can help prevent exploitation of stack buffer overflows, are not universally used in Netgear devices.
  3. Authentication is not required to reach the vulnerable code.
  4. The vulnerability occurs before Cross-Site Request Forgery (CSRF) token checking occurs.
  5. Target device fingerprinting can occur by visiting the /currentsetting.htm page on an affected device.

Exploit code that targets 79 different Netgear devices is publicly available.


By convincing a user to visit a malicious or compromised website, a remote, unauthenticated attacker may be able to execute arbitrary code on a vulnerable device with root privileges.

Solution Apply an update

Netgear has provided updates for several vulnerable devices. Note that Netgear does not indicate when devices have reached an end of life (EOL) state. This may be difficult to determine if a vulnerable device may receive an update in the future.

The CERT/CC has made a spreadsheet to more clearly indicate which devices have updates, and which devices may either be receiving an update in the future, or may possibly be unsupported.

As outlined in the blog post It's Time to Retire Your Unsupported Things, you should factor the vendor's support life span into purchasing decisions. Vendors that indicate how long products will be supported should be preferred over those that do not clearly indicate how long a device will be supported. Similarly, vendors that clearly indicate when a product has reached EOL state should be preferred over vendors that do not.


This vulnerability was publicly disclosed by ZDI, who in turn credit d4rkn3ss from VNPT ISC. Additional analysis was provided by GRIMM.

This document was written by Will Dormann.

Kategóriák: Biztonsági hírek

VU#257161: Treck IP stacks contain multiple vulnerabilities

k, 06/16/2020 - 19:35

Treck IP stack implementations for embedded systems are affected by multiple vulnerabilities. This set of vulnerabilities was researched and reported by JSOF who calls them Ripple20.


Treck IP network stack software is designed for and used in a variety of embedded systems. The software can be integrated in various ways (compiled, included, and as a linked library). Multiple vulnerabilities were found in Treck IP software. Most of the vulnerabilites are caused by memory corruption bugs. For more details, see Vulnerability Response Information from Treck and the Ripple20 advisory from JSOF.

Historically-related KASAGO TCP/IP middleware from Zuken Elmic (formerly Elmic Systems) is also affected by some of these vulnerabilities.

These vulnerabilities likely affect industrial control systems and medical devices. Please see ICS-CERT Advisory ICSA-20-168-01 for more information.


The impact of these vulnerabilities will vary due to the combination of build and runtime options used while developing different embedded systems. A remote, unauthenticated attacker may be able to use specially-crafted network packets to cause a denial of service, disclose information, and execute arbitrary code.

Solution Apply updates

Update to the latest stable version of Treck IP stack software ( or later). Please contact Treck at Downstream users of embedded systems that incorporate Treck IP stacks should contact their embbeded system vendor.

Block anomalous IP traffic

Consider blocking network attacks via deep packet inspection. In some cases, modern routers and firewalls will drop malformed packets with no additional configuration. Below is the list of possible mitigations that can be applied as appropriate to your network environment.

  • Normalize or reject IP fragmented packets (IP Fragments) if not supported in your environment
  • Disable or block IP tunneling, both IPv6-in-IPv4 or IP-in-IP tunneling if not required
  • Block IP source routing and any IPv6 deprecated features like routing headers VU#267289
  • Enforced TCP inspection and reject malformed TCP packets
  • Block unused ICMP control messages such MTU Update and Address Mask updates
  • Normalize DNS through a secure recursive server or application layer firewall
  • Provide reliable OSI layer 2 networking including Ethernet
  • Provide DHCP/DHCPv6 security with feature like DHCP snooping
  • Disable or block IPv6 multicast if not used in switching infrastructure

Further recommendations are available here.

Detect anomalous IP traffic

Surricata IDS has built-in decoder-event rules which can be customized to detect attempts to exploit these vulnerabilities. See the rule below for an example. A larger set of selected vu-257161.rules are available from the CERT/CC Github repository.

#IP-in-IP tunnel with fragments
alert ip any any -> any any (msg:"VU#257161:CVE-2020-11896, CVE-2020-11900 Fragments inside IP-in-IP tunnel"; ip_proto:4; fragbits:M; sid:1367257161; rev:1;)


Moshe Kol and Shlomi Oberman of JSOF researched and reported these vulnerabilities. Treck worked closely with us and other stakeholders to coordinate the disclosure of these vulnerabilities.

This document was written by Vijay Sarvepalli.

Kategóriák: Biztonsági hírek

VU#782301: pppd vulnerable to buffer overflow due to a flaw in EAP packet processing

h, 06/15/2020 - 15:40

pppd (Point to Point Protocol Daemon) versions 2.4.2 through 2.4.8 are vulnerable to buffer overflow due to a flaw in Extensible Authentication Protocol (EAP) packet processing in eap_request and eap_response subroutines.


PPP is the protocol used for establishing internet links over dial-up modems, DSL connections, and many other types of point-to-point links including Virtual Private Networks (VPN) such as Point to Point Tunneling Protocol (PPTP). The pppd software can also authenticate a network connected peer and/or supply authentication information to the peer using multiple authentication protocols including EAP.

Due to a flaw in the Extensible Authentication Protocol (EAP) packet processing in the Point-to-Point Protocol Daemon (pppd), an unauthenticated remote attacker may be able to cause a stack buffer overflow, which may allow arbitrary code execution on the target system. This vulnerability is due to an error in validating the size of the input before copying the supplied data into memory. As the validation of the data size is incorrect, arbitrary data can be copied into memory and cause memory corruption possibly leading to execution of unwanted code.

The vulnerability is in the logic of the eap parsing code, specifically in the eap_request() and eap_response() functions in eap.c that are called by a network input handler. These functions take a pointer and length as input using the the first byte as a type. If the type is EAPT_MD5CHAP(4), it looks at an embedded 1-byte length field. The logic in this code is intended to makes sure that embedded length is smaller than the whole packet length. After this verification, it tries to copy provided data (hostname) that is located after the embedded length field into a local stack buffer. This bounds check is incorrect and allows for memory copy to happen with an arbitrary length of data.

An additional logic flaw causes the eap_input() function to not check if EAP has been negotiated during the Link Control Protocol (LCP) phase. This allows an unauthenticated attacker to send an EAP packet even if ppp refused the authentication negotiation due to lack of support for EAP or due to mismatch of an agreed pre-shared passphrase in the LCP phase. The vulnerable pppd code in eap_input will still process the EAP packet and trigger the stack buffer overflow. This unverified data with an unknown size can be used to corrupt memory of the target system. The pppd often runs with high privileges (system or root) and works in conjunction with kernel drivers. This makes it possible for an attacker to potentially execute arbitrary code with system or root level privileges.

The pppd software is also adopted into lwIP (lightweight IP) project to provide pppd capabilities for small devices. The default installer and packages of lwIP are not vulnerable to this buffer overflow. However if you have used the lwIP source code and configured specifically to enable EAP at compile time, your software is likely vulnerable to the buffer overflow. The recommended update is available from Git repoistory

This type of weakness is commonly associated in Common Weakness Enumeration (CWE) with CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'). A Proof-of-Concept exploit for PPTP VPN Servers with additional tools are available in the by CERT/CC PoC repository.


By sending an unsolicited EAP packet to a vulnerable ppp client or server, an unauthenticated remote attacker could cause memory corruption in the pppd process, which may allow for arbitrary code execution.

Solution Apply updates

Update your software with the latest available patches provided by your software vendor. It is incorrect to assume that pppd is not vulnerable if EAP is not enabled or EAP has not been negotiated by a remote peer using a secret or passphrase. This is due to the fact that an authenticated attacker may still be able to send unsolicited EAP packet to trigger the buffer overflow.

If your software is packaged and created from the ppp source code, please obtain the latest software from github pppd repository.
Patch referenced :

In case of lwIP package that is compiled from source with EAP enabled at compile time, obtain the latest software from github
Patch referenced:

Note: the latest software also includes ignoring out-of-order or unsolicited EAP packets from being processed as an additional precautionary measure. It is recommended that you use the latest available software from the appropriate Git repository that includes this fix.

Proof of Concept (PoC)

A proof-of-concept for testing if a PPTP server is vulnerable to cve-2020-8597 is available in the CERT/CC PoC respository

Detection Signature (IDS)

A Snort/Surricata IDS rule to detect cve-2020-8597 buffer overflow attempts against PPTP servers is also available in the CERT/CC PoC respository.


There is no viable work around except to patch the software with updated software made available by the software vendors.


Thanks to Ilja Van Sprundel from IOActive for reporting this vulnerability.

This document was written by Vijay Sarvepalli.

Kategóriák: Biztonsági hírek

VU#872016: Microsoft SMBv3 compression remote code execution vulnerability

cs, 06/04/2020 - 23:26

Microsoft SMBv3 contains a vulnerability in the handling of compression, which may allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable system. This vulnerability is being referred to as "SMBGhost and CoronaBlue."


Microsoft Server Message Block 3.1.1 (SMBv3) contains a vulnerability in the way that it handles connections that use compression. This vulnerability may allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable system. It has been reported that this vulnerability is "wormable."


By connecting to a vulnerable Windows machine using SMBv3, or by causing a vulnerable Windows system to initiate a client connection to a SMBv3 server, a remote, unauthenticated attacker may be able to execute arbitrary code with SYSTEM privileges on a vulnerable system.


Apply an update

This issue has been addressed in the Microsoft update for CVE-2020-0796. Please also consider the following workarounds:

Disable SMBv3 compression

According to Microsoft Security Advisory ADV200005 :

    You can disable compression to block unauthenticated attackers from exploiting the vulnerability against an SMBv3 Server with the PowerShell command below.

    Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 1 -Force


    1. No reboot is needed after making the change.
    2. This workaround does not prevent exploitation of SMB clients.

    You can disable the workaround with the PowerShell command below.

    Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 0 -Force

Block inbound and outbound SMB

Consider blocking outbound SMB connections (TCP port 445 for SMBv3) from the local network to the WAN. Also ensure that SMB connections from the internet are not allowed to connect inbound to an enterprise LAN.


This document was written by Will Dormann.

Kategóriák: Biztonsági hírek

VU#425163: Machine learning classifiers trained via gradient descent are vulnerable to arbitrary misclassification attack

cs, 06/04/2020 - 21:14

Machine learning models trained using gradient descent can be forced to make arbitrary misclassifications by an attacker that can influence the items to be classified. The impact of a misclassification varies widely depending on the ML model's purpose and of what systems it is a part.


This vulnerability results from using gradient descent to determine classification of inputs via a neural network. As such, it is a vulnerability in the algorithm. In plain terms, this means that the currently-standard usage of this type of machine learning algorithm can always be fooled or manipulated if the adversary can interact with it. What kind or amount of interaction an adversary needs is not always clear, and some attacks can be successful with only minor or indirect interaction. However, in general more access or more interaction options reduce the effort required to fool the machine learning algorithm. If the adversary has information about some part of the machine learning process (training data, training results, model, or operational/testing data), then with sufficient effort the adversary can craft an input that will fool the machine learning tool to yield a result of the adversary's choosing. In instantiations of this vulnerability that we are currently aware of, "sufficient effort" ranges widely, between seconds and weeks of commodity compute time.

Within the taxonomy by Kumar et al., such misclassifications are either perturbation attacks or adversarial examples in the physical domain. There are other kinds of failures or attacks related to ML systems, and other ML systems besides those trained via gradient descent. However, this note is restricted to this specific algorithm vulnerability. Formally, the vulnerability is defined for the following case of classification.

Let \(x\) be a feature vector and \(y\) be a class label. Let \(L\) be a loss function, such as cross entropy loss. We wish to learn a parameterization vector \(\theta\) for a given class of functions \(f\) such that the expected loss is minimized. Specifically, let

\[\theta_{\star} = min_\theta \mathop{\mathbb{E}}_{x,y} L\left(f\left(\theta, x\right), y\right) \]

In the case where \(f\left(\theta,x\right)\) is a neural network, finding the global minimizer \(\theta_{\star}\) is often computationally intractable. Instead, various methods are used to find \(\hat{\theta}\) which is a "good enough" approximation. We refer to \(f\left(\hat{\theta}, .\right)\) as the fitted neural network.

If stochastic gradient descent is used to find \(\hat{\theta}\) for the broadly defined set of \(f\left(\theta,x\right)\) representing neural networks, then the fitted neural network \(f\left(\hat{\theta}, .\right)\) is vulnerable to adversarial manipulation.

Specifically, it is possible to take \(f\left(\hat{\theta}, .\right)\) and find an \(x'\) such that the difference between \(x\) and \(x'\) is smaller than some arbitrary \(\epsilon\) and yet \(f\left(\hat{\theta}, x\right)\) has the label \(y\) and \(f\left(\hat{\theta}, x'\right)\) has an arbitrarily different label \(y'\).

The uncertainty of the impact of this vulnerability is compounded because practitioners and vendors do not tend to disclose what machine learning algorithms they use. However, training neural networks by gradient descent is a common technique. See also the examples in the impact section.


An attacker can interfere with a system which uses gradient descent to change system behavior. As an algorithm vulnerability, this flaw has a wide-ranging but difficult-to-fully-describe impact. The precise impact will vary with the application of the ML system. We provide three illustrative examples; these should not be considered exhaustive.

  • Automatic speech recognition can be forced to erroneously transcribe an audio clip, and the attacker can freely pick the target transcription if they can pick the audio clip.
  • Facial recognition can be forced to erroneously identify faces across many photographs, in different lightings, by use of physical eyeglass frames or manipulation of the source photo. The attacker can choose an arbitrary target identity of the misclassification.
  • Tesla autopilot in March 2019 had a demonstrated vulnerability (as in, on a closed road course, the attack works) where the car can be forced to change lanes arbitrarily based on stickers placed on the road surface. In January 2020, similar attacks were demonstrated using projections, such as from airborne drones, rather than stickers.


The CERT/CC is currently unaware of a specific practical solution to this problem. To defend generally, do both of:
1. Adversarial training and testing of ML models. If a model must be exposed to adversarial input, the only well-tested defense against this kind of adversarial attack is adversarial training: using adversarially perturbed examples as part of the neural network's training regimen. When used for training, these examples increase the model's robustness against adversarial attack. Such training significantly increases the difficulty of attacking the model, but it does not guarantee the model is not vulnerable. Test your machine learning algorithm against known attacks. Libraries featuring reference implementations of popular attacks and defenses include Cleverhans, Foolbox, and the Adversarial Robustness Toolkit (ART).

2. Standard defense in depth. A machine learning tool is not different from other software in this regard. Any tool should be deployed in an ecosystem that supports and defends it from adversarial manipulation. For machine learning tools specifically designed to serve a cybersecurity purpose, this is particularly important, as they are exposed to adversarial input as part of their designed tasking. See CMU/SEI-2019-TR-005 for more information on evaluating machine learning tools for cybersecurity.

Other proposed solutions, which rely on either pre-processing the data or simply obfuscating the gradient of the loss, do not work when your adversary is aware that you are attempting those mitigations.


See Papernot et al. (2016) Towards the Science of Security and Privacy in Machine Learning or Biggio and Roli (2018) Wild patterns: Ten years after the rise of adversarial machine learning for a brief history.

This document was written by Allen Householder, Jonathan M. Spring, Nathan VanHoudnos, and Oren Wright.

Kategóriák: Biztonsági hírek

VU#127371: iOS contains an unspecified kernel vulnerability

k, 05/26/2020 - 17:26
iOS contains an unspecified kernel vulnerability. This vulnerability can allow code execution with kernel privileges. This vulnerability is being used by the public unc0ver 5.0 jailbreak utility,which claims to support all devices from iOS 11 through 13.5,excluding versions 12.3-12.3.2 and 12.4.2-12.4.5. It is also reported that this jailbreak works on modern iOS devices that use a CPU that supports Pointer Authentication Code(PAC),which indicates that PAC does not prevent exploitation of this vulnerability.
Kategóriák: Biztonsági hírek

VU#647177: Bluetooth devices supporting BR/EDR are vulnerable to impersonation attacks

h, 05/18/2020 - 20:16
Bluetooth is a short-range wireless technology based off of a core specification that defines six different core configurations,including the Bluetooth Basic Rate/Enhanced Data Rate(BR/EDR)Core Configurations. Bluetooth BR/EDR is used for low-power short-range communications. To establish an encrypted connection,two Bluetooth devices must pair with each other using a link key. It is possible for an unauthenticated,adjacent attacker to spoof the address of a previously paired remote device to successfully complete the authentication procedure with some paired/bonded devices without knowing the link key. The Bluetooth Impersonation Attack(BIAS)can be performed in two different ways,depending on which Secure Simple Pairing method(either Legacy Secure Connections or Secure Connections)was previously used to establish a connection between two devices. If the pairing procedure was completed using the Secure Connections method,the attacker could claim to be the previously paired remote device that no longer supports secure connections,thereby downgrading the authentication security. This would allow the attacker to proceed with the BIAS method against the legacy authentication unless the device they are attacking is in Secure Connections only mode. If the attacker can either downgrade authentication or is attacking a device that does not support Secure Connections,they can perform the attack using a similar method by initiating a master-slave role switch to place itself into the master role and become the authentication initiator. If successful,they complete the authentication with the remote device. If the remote device does not then mutually authenticate with the attacker in the master role,it will result in the authentication-complete notification on both devices,even though the attacker does not possess the link key. The BIAS method is able to be performed for the following reasons: Bluetooth secure connection establishment is not encrypted and the selection of secure connections pairing method is not enforced for an already established pairing,Legacy Secure Connections secure connection establishment does not require mutual authentication,a Bluetooth device can perform a role switch any time after baseband paging,and devices who paired using Secure Connections can use Legacy Secure Connections during secure connection establishment.
Kategóriák: Biztonsági hírek

VU#534195: Bluetooth devices supporting LE and specific BR/EDR implementations are vulnerable to method confusion attacks

h, 05/18/2020 - 20:12
Bluetooth is a short-range wireless technology based off of a core specification that defines six different core configurations,including the Bluetooth Low Energy(BLE)Core Configuration. Like Bluetooth Classic(BR/ER),BLE is used for low-power short-range communications,but has significantly lower power consumption,making it ideal for Internet of Things(IoT)and other resource restricted devices. For two devices to communicate over BLE,they need to establish a connection by pairing via the(Low Energy)Secure Connections(SC or LESC)or Secure Simple Pairing(SSP)methods. The pairing process includes feature information exchange between devices on what they support,public key exchange,and authentication of the public keys using an Association Model. Two of the possible Association Models,Numeric Comparison(NC)and Passkey Entry(PE),are impacted by this attack. An adjacent,unauthenticated attacker can intercept the credentials shared during the pairing process and force each victim device into a different Association Model. To do this,the attacker must negotiate an NC procedure with one device and a PE procedure with the other,and the user must erroneously enter the NC value as the public key value and accept pairing on the NC device. This scenario applies to both BLE Secure Connections pairing and BR/EDR Secure Simple Pairing. However,only a device operating as a keyboard for the purposes of pairing may be used to enter the passkey in the BR/EDR Secure Simple Pairing scenario. The attacker would be able to initiate any Bluetooth operation on either attacked device that is exposed by the enabled Bluetooth profiles. For this attack to be successful,an attacking device must be within wireless range of two vulnerable Bluetooth devices that are establishing either an LE or a BR/EDR encrypted connection without existing shared credentials(long term key or link key). At least one device must permit entry of a passkey,and the other must support a display capable of representing six decimal digits. This attack is possible because the Association Models NC and PE use the same form of check value,the model used is not indicated to the user(making it extremely difficult to notice the change),and the devices are not authenticating which Association Model is used by the peer device.
Kategóriák: Biztonsági hírek

VU#366027: Samsung Qmage codec for Android Skia library does not properly validate image files

cs, 05/14/2020 - 22:48
The Samsung May 2020 Android Security Update notes that"a possible memory overwrite vulnerability in Quram qmg library allows possible remote arbitrary code execution."Samsung identifies this vulnerability as SVE-2020-16747,more commonly known as CVE-2020-8899. Google Project Zero performed extensive fuzz testing on the Qmage(or Quram,or qmg)code Samsung added to the Android Skia library and identified more than 1500 unique crashing test cases. At least one of these memory corruption vulnerabilities can be exploited by sending a specially crafted MMS message to a vulnerable system. Samsung notes that versions O(8.X),P(9.0),Q(10.0)are affected.
Kategóriák: Biztonsági hírek