pbarry-r7 (48)
Last Login: June 17, 2021
pbarry-r7's Latest (18) Contributions
Technical Analysis
Mozilla recently announced a fix for this vulnerability in Firefox 83. They marked this as Impact: high
and provided the following details in their published advisory:
Incorrect bookkeeping of functions inlined during JIT compilation could have led to memory corruption and a potentially exploitable crash when handling out-of-memory errors.
While the bits they’ve offered here sound non-trivial to exploit, it’s not a bad idea for Firefox users to patch to version 83.
Technical Analysis
Mozilla recently announced a fix for this vulnerability in Firefox 83. They marked this as Impact: high
and provided the following details in their published advisory:
A parsing and event loading mismatch in Firefox’s SVG code could have allowed load events to fire, even after sanitization. An attacker already capable of exploiting an XSS vulnerability in privileged internal pages could have used this attack to bypass our built-in sanitizer.
The ability to bypass sanitization sounds like it’s worth Firefox users to patch to version 83.
Technical Analysis
This was patched in the July 2020 release of OFBiz 17.12.04.
If your business/org runs Apache OFBiz, now is a good time to update to 17.12.04.
Technical Analysis
This vuln is part of a related batch named SweynTooth from researchers at the Singapore University of Technology and Design. The SweynTooth vulnerabilities lie within certain Bluetooth Low Energy (BLE) SDKs for Systems-on-a-Chip (SoC), which can make proliferating fixes to affected devices in the field a slow going.
Vulnerable devices need to be within BLE radio range in order for an attacker to target. A successful exploit will leave the target in a deadlocked or non-functional state by sending the target a Link Layer ID packet with a value of 0. Device recovery may require a hard reset or powercycle, and a vulnerable device will immediately become vulnerable again once it enables BLE. A detailed explanation can be found here in the original disclosure. It appears the SoC manufacturer has issued fixes for their vulnerable SDK(s).
Related, the same researchers found an SoC from Cypress which also contained a similar vulnerability (CVE-2019-17061), also disclosed as part of SweynTooth.
EDIT: Attacker Value for this item largely depends on the type of device the vulnerable target is and behavior the device exhibits when successfully exploited.
Technical Analysis
This vuln is part of a related batch named SweynTooth from researchers at the Singapore University of Technology and Design. The SweynTooth vulnerabilities lie within certain Bluetooth Low Energy (BLE) SDKs for Systems-on-a-Chip (SoC), which can make proliferating fixes to affected devices in the field a slow going.
Vulnerable devices need to be within BLE radio range in order for an attacker to target. A successful exploit will leave the target in a deadlocked or non-functional state by sending the target a Link Layer ID packet with a value of 0. Device recovery may require a hard reset or powercycle, and a vulnerable device will immediately become vulnerable again once it enables BLE. In their testing, researchers were able to crash a FitBit Inspire device containing this vulnerability, which resulted in a period of ~30 where the Inspire ceased its Bluetooth advertising packets and then restarted itself. A detailed explanation can be found here in the original disclosure, as well as some potentially vulnerable devices in this list. It appears the SoC manufacturer has issued fixes for their vulnerable SDK(s).
Related, the same researchers found an SoC from NXP which also contained a similar vulnerability (CVE-2019-17060), also disclosed as part of SweynTooth.
EDIT: Attacker Value for this item largely depends on the type of device the vulnerable target is and behavior the device exhibits when successfully exploited.
Technical Analysis
This vuln is part of a related batch named SweynTooth from researchers at the Singapore University of Technology and Design. The SweynTooth vulnerabilities lie within certain Bluetooth Low Energy (BLE) SDKs for Systems-on-a-Chip (SoC), which can make proliferating fixes to affected devices in the field a slow going.
Vulnerable devices need to be within BLE radio range in order for an attacker to target. A successful exploit will crash the target by sending a Secure Manager Protocol (SMP) public key packet prior to the actual start of the SMP paring process, crashing (and possibly restarting) the target. In their testing, researchers were able to crash (and deadlock) a CubiTag device containing this vulnerability. A detailed explanation can be found here in the original disclosure, as well as some potentially vulnerable devices in this list. It appears the SoC manufacturer has issued fixes for their vulnerable SDK(s).
EDIT: Attacker Value for this item largely depends on the type of device the vulnerable target is and behavior the device exhibits when successfully exploited.
Technical Analysis
This vuln is part of a related batch named SweynTooth from researchers at the Singapore University of Technology and Design. The SweynTooth vulnerabilities lie within certain Bluetooth Low Energy (BLE) SDKs for Systems-on-a-Chip (SoC), which can make proliferating fixes to affected devices in the field a slow going.
Vulnerable devices need to be within BLE radio range in order for an attacker to target. A successful exploit will crash the target by sending a “too short” link layer PDU. That said, the watchdog mechanism (enabled by default in the SDK) will notice and reboot the device, making this a short-lived Denial of Service for devices which have the watchdog enabled. A detailed explanation can be found here in the original disclosure, as well as some potentially vulnerable devices in this list. It appears the SoC manufacturer is still working on fixes for their vulnerable SDK(s).
EDIT: Attacker Value for this item largely depends on the type of device the vulnerable target is and behavior the device exhibits when successfully exploited.
Technical Analysis
This vuln is part of a related batch named SweynTooth from researchers at the Singapore University of Technology and Design. The SweynTooth vulnerabilities lie within certain Bluetooth Low Energy (BLE) SDKs for Systems-on-a-Chip (SoC), which can make proliferating fixes to affected devices in the field a slow going.
Vulnerable devices need to be within BLE radio range and have “secure connection pairing” enabled in order for an attacker to target. A successful exploit will achieve a working connection without doing the full “secure connection pairing” process, allowing an attacker control over the BLE application’s communications. A detailed explanation can be found here in the original disclosure, as well as some potentially vulnerable devices in this list. It appears the SoC manufacturer has issued fixes for their vulnerable SDK(s).
EDIT: Attacker Value for this item largely depends on the type of device the vulnerable target is and behavior the device exhibits when successfully exploited.
Technical Analysis
This vuln is part of a related batch named SweynTooth from researchers at the Singapore University of Technology and Design. The SweynTooth vulnerabilities lie within certain Bluetooth Low Energy (BLE) SDKs for Systems-on-a-Chip (SoC), which can make proliferating fixes to affected devices in the field a slow going.
Vulnerable devices need only to be within BLE radio range for an attacker to target. An exploit can trigger a buffer overflow (BOF) to crash a vulnerable target, effectively a DoS. Because the attack vector is a BOF, the possibility does exist for a carefully constructed attack to bypass security by overwriting the security nonce and then leak user information. A detailed explanation can be found here in the original disclosure, as well as some potentially vulnerable devices in this list. It appears the SoC manufacturer has issued fixes for their vulnerable SDK(s).
EDIT: Attacker Value for this item largely depends on the type of device the vulnerable target is and behavior the device exhibits when successfully exploited.
Technical Analysis
Does rely on a user to download and open an injected .cbt file with a vulnerable version of Evince (though the preview functionality of file manager software might trigger the injection without requiring the user to expressly open the file).
Technical Analysis
Exploit doesn’t work within the Chrome sandbox, so an attacker will need to escape that first. Couple that with the facts that x64 is more difficult to target and the auto-update nature of Chrome, this one wouldn’t be the easiest to exploit, methinks…
Technical Analysis
There’s some interesting debate around the couching of this as a vuln in PostgreSQL, itself, since the COPY TO/FROM PROGRAM is ostensibly documented to allow program execution. Certainly a good reminder to, in general, limit privs where possible (in this case, don’t grant ‘pg_execute_server_program’ to users who don’t require it).
Technical Analysis
Sounds like this vuln appears in a LOT of versions of the software. Probably should update to v15.1.7+.
Technical Analysis
Have to be on the same local network as the target device to pull this off, but, hey, unauthenticated video broadcasting…! Might make those doctor waiting room visits a little more interesting…
Technical Analysis
Unclear if this has been officially patched yet in Net-SNMPd (there are reports that the most-current version is still vulnerable).
One way to remediate would be to set access to READ ONLY instead of READ/WRITE.
Technical Analysis
Data Protector is a product of Micro Focus (formerly HPE Software). Vulnerable versions allow exploit of the trusted $PATH environment variable of the SUID binary omniresolve
, leading to privilege escalation. Sounds like versions in the 9.X range have also proved to be vulnerable.
It’s reported that upgrading to Data Protector v10.50 successfully patches this vulnerability.
Technical Analysis
Purportedly, this affects versions of rConfig prior to 3.9.2, as well. rConfig installation leaves files lying around, asking the user to clean them up. If the user doesn’t take this step, then an attacker can use the ajaxServerSettingsChk.php file (leftover from installation) to gain unauthenticated command execution as the web server user. Chain this with a local privilege escalation, and things can go from bad to worse for the target…
One can remediate this by removing all files from the rConfig installation directory.
Neat!