In WebKitGTK through 2.36.0 (and WPE WebKit), there is a heap-based buffer overflow in WebCore::TextureMapperLayer::setContentsLayer in WebCore/platform/graphics/texmap/TextureMapperLayer.cpp.

CVE-2022-30293: security_advisories/webkitgtk-2.36.0 at master · ChijinZ/security_advisories

uClibc-ng through 1.0.40 and uClibc through 0.9.33.2 use predictable DNS transaction IDs that may lead to DNS cache poisoning. This is related to a reset of a value to 0x2.

Nozomi Networks Labs discovered a vulnerability (tracked under CVE-2022-30295, ICS-VU-638779, VU#473698) affecting the Domain Name System (DNS) implementation of all versions of uClibc and uClibc-ng, a popular C standard library in IoT products. The flaw is caused by the predictability of transaction IDs included in the DNS requests generated by the library, which may allow attackers to perform DNS poisoning attacks against the target device.

According to their respective official websites, uClibc is known to be/have been used by major vendors such as Linksys, Netgear, and Axis (only until 2010, newer Axis products include other libraries), as well as Linux distributions such as Embedded Gentoo. uClibc-ng is a fork specifically designed for OpenWRT, a common OS for routers possibly deployed throughout various critical infrastructure sectors.

Because the library maintainer was unable to develop a fix, this vulnerability remains unpatched. For this reason, we are not disclosing the details of the devices on which we were able to reproduce the vulnerability.

In this blog, we start with a background of C Standard Libraries used in IoT devices, present a technical analysis of the issue and detail its exploitability, and then provide a comprehensive timeline of the disclosure process.

A new unpatched vulnerability discovered by Nozomi Networks Labs affects the DNS implementation of all versions of uClibc and uClibc-ng.

**Background: C Standard Libraries and uClibc**

In computing, a library is a collection of resources (functions, configuration data, specifications, etc.) that is shared among software. The purpose of libraries is to provide standard primitives that software can use to perform common operations (such as to access a file on a disk or perform a network operation), without the necessity of reimplementing them all the time.

A C standard library is no exception, in the sense that it is a library for the C programming language itself. A real-world example can be found in the well-known C “Hello, World!” program. When we type the pre-processor command “#include <stdio.h>” and invoke an output function (for instance, “printf”) to print “Hello, World!”, we are actually executing the code of the chosen output function provided by the selected C standard library for the implementation of the header file “stdio.h”.

Of note, uClibc is one of the possible C standard libraries available, and specifically focuses on embedded systems. Other famous C standard libraries are glibc (GNU C library), the musl libc, or the Microsoft C run-time library (CRT).

It’s important to note that a vulnerability affecting a C standard library can be a bit complex. Not only would there be hundreds or thousands of calls to the vulnerable function in multiple points of a single program, but the vulnerability would affect an indefinite number of other programs from multiple vendors configured to use that library.

**Domain Name System (DNS)**

As we know, in modern computer networks the DNS is a hierarchical database that serves the primary, and crucial, purpose of translating a domain name into its related IP address, allowing users to access resources by more easily by memorizing human-friendly names instead of complex sequences of numbers.

Under the hood, DNS requests are mostly transmitted through UDP, which is a connectionless protocol. Thus, in order to distinguish the responses of different DNS requests, besides the usual 5-tuple {source IP, source port, destination IP, destination port, protocol} and of course the query, each DNS request includes a parameter called “transaction ID”. This is a unique number per request that is generated by the client, added in each request sent, and that must be included in a DNS response to be accepted by the client as the valid one for a corresponding request. If this condition is false, the response is discarded; if true (and other checks are satisfied as well), the response is accepted and the program that asked for a translation of a certain domain name can initiate the connection to the IP address provided.

**Figure 1.** Example DNS request. The 5-tuple, txID, and query are highlighted in the red.

Similar to other C standard libraries, uClibc provides an extensive DNS client interface that allows programs to readily perform lookups and other DNS-related requests.

**Poisoning Attacks to DNS**

Because of its relevance, DNS can be a valuable target for attackers. In a DNS poisoning attack, an attacker is able to deceive a DNS client into accepting a forged response, thus inducing a certain program into performing network communications with an arbitrarily defined endpoint, and not the legitimate one. A DNS poisoning attack enables a subsequent Man-in-the-Middle attacks  because the attacker, by poisoning DNS records, is capable of rerouting network communications to a server under their control. The attacker could then steal and/or manipulate information transmitted by users, and perform other attacks against those devices to completely compromise them. The main issue here is how DNS poisoning attacks can force an authenticated response.

To have a DNS response accepted for a certain DNS request, the aforementioned 5-tuple, the query, and the transaction ID must be correctly set. Given that 1. the protocol is DNS, 2. the destination port is 53/udp, 3. the query is the target that an attacker wants to compromise, 4. the source IP address is the target machine, and 5. the destination IP address is public information (it is the IP address of the DNS server in use in a certain network), the only unknowns remain the source port and the transaction ID. It is vital that these two parameters are as unpredictable as possible, because if they are not, a poisoning attack could be possible. 

**Vulnerability Details**

While we were reviewing the trace of DNS requests performed by an IoT device under test in our lab, we noticed the pattern of DNS requests performed from the output of Wireshark. If you look at the below screenshot (Figure 2) you can see that the transaction ID is first incremental, then resets to the value 0x2, then is incremental again.

**Figure 2.** Trace of DNS requests performed by an IoT device under test

While debugging the related executable, trying to understand the root cause, we eventually noticed that the code responsible for performing the DNS requests was not part of the instructions of the executable itself, but was part of the C standard library in use, namely uClibc 0.9.33.2 (“libuClibc-0.9.33.2.so”).

A source code review revealed that the uClibc library implements DNS requests by calling the internal “__dns_lookup” function, located in the source file “/libc/inet/resolv.c”.

**Figure 3.** DNS lookup function of uClibc.

In reference to line #1240, the function declares a static variable “last_id”. This variable contains the value of the transaction ID used in the last DNS request, and is initialized with the value 1 at the first invocation of “__dns_lookup”.

Additionally, at line #1260, the function declares a variable “local_id”. This variable contains the value of the transaction ID that will be used in the upcoming DNS request, and is left uninitialized.

Afterwards, the following lines of code are executed.

**Figure 4.** DNS lookup function of uClibc (2).

In reference to line #1309, at the first DNS request, the “local_id” variable is initialized with the value of the transaction ID of the last DNS request (“last_id”). Line #1320 is the actual core of the vulnerability: “local_id” is updated by incrementing its old value by 1. Given that the value is initialized to 1 at the first invocation, this is the reason that the transaction ID was reset to 0x2 the previous Wireshark screenshot (Figure 2).

After doing a bitwise AND at line #1321, this value is also stored inside “last_id” variable at line #1323. Finally, at line #1335, the value of “local_id” is copied inside the struct resolv\_header “h” variable, which represents the actual content of the header of the DNS request. Similar revisions of this code were found in all versions available of uClibc and uClibc-ng.

**Vulnerability Exploitability**

Given that the transaction ID is now predictable, to exploit the vulnerability an attacker would need to craft a DNS response that contains the correct source port, as well as win the race against the legitimate DNS response incoming from the DNS server. Exploitability of the issue depends exactly on these factors. As the function does not apply any explicit source port randomization, it is likely that the issue can easily be exploited in a reliable way if the operating system is configured to use a fixed or predictable source port.

If the operating system applies randomization of source port (which is done by all OSs nowadays—for instance, modern Linux kernels use range 32768–60999), exploitability depends on the capacity of the attacker to bruteforce the 16 bit source port value by sending multiple DNS responses, while simultaneously winning the race against the legitimate DNS response. In this situation, exploitability depends on factors such as the bandwidth at disposal of the attacker, or on the response time of the DNS query. Additionally, it is more likely that an attacker will succeed at least once in performing a DNS poisoning attack if the target device performs a great number of identical queries in a given time frame, compared to a target that performs sporadic queries.

**Mitigations**

This vulnerability remains unpatched, however we are working with the maintainer of the library and the broader community in support of finding a solution.

Because this vulnerability remains unpatched, for the safety of the community we cannot disclose the specific devices we tested on. We can, however, disclose that they were a range of well-known IoT devices running the latest firmware versions with a high chance of them being deployed throughout all critical infrastructure.

We recommend everyone increase their network visibility and security in both IT and OT environments.

**Disclosure Process and Timeline**

As anticipated, as of the publication of this blog, the vulnerability is still unpatched. As stated in a public conversation, the maintainer was unable to develop a fix for the vulnerability, hoping for help from the community. The vulnerability was disclosed to 200+ vendors invited to the VINCE case by CERT/CC since January 2022, and a 30-day notice was given to them before the public release.

The timeline of events is reported below:

*   2021/09/13: Disclosure to ICS-CERT
*   2021/10/05: Asked for updates from ICS-CERT
*   2021/10/05: Reservation of ticket numbers ICS-VU-638779, VU#473698
*   2021/10/26: Asked for updates from ICS-CERT
*   2021/11/19: Second attempt to ask for updates from ICS-CERT
*   2021/11/29: Received invitation to participate in CERT/CC VINCE case
*   2021/12/08: Request from CERT/CC to validate vulnerability on latest 1.0.39 version, and to provide insights regarding status of disclosure
*   2021/12/09: Replied to CERT/CC, vulnerability confirmed on 1.0.39, informed CERT/CC that for now disclosure has been submitted to ICS-CERT only
*   2021/12/09 (and later): Attempts by CERT/CC to invite uClibc-ng maintainer to the VINCE case
*   2022/01/24: Multiple vendors invited to the VINCE case by CERT/CC, vulnerability disclosed to them
*   2022/02/24: Asked for updates to CERT/CC
*   2022/03/11: Attempt to contact uClibc-ng maintainer
*   2022/03/14: Maintainer confirmed he was contacted by CERT/CC, explained he was unable to fix the vulnerability by himself, explicitly asked to publicly disclose it, hoping for help from the community
*   2022/03/15-16: Discussion with CERT/CC on next steps. Planned to request a second confirmation from the maintainer, then proceed to notification of vendors of a disclosure in 30 days
*   2022/03/18: Asked for second confirmation from maintainer
*   2022/03/21: CERT/CC provided a status update in the VINCE case to vendors
*   2022/03/21-22: Discussion with CERT/CC on next steps
*   2022/03/23: Resent email to maintainer
*   2022/03/29: Proposed to CERT/CC to proceed with the 30-day notification to vendors, given lack of responses (or counter-orders) from maintainer
*   2022/04/01: CERT/CC approved the disclosure schedule proposal
*   2022/04/01: Provided a status update in the VINCE case to vendors, informed them that the vulnerability would be disclosed on May 2nd
*   2022/05/02: Public disclosure

CVE-2022-30295: Nozomi Networks Discovers Unpatched DNS Bug in Popular C Standard Library Putting IoT at Risk

Nozomi Networks Labs discovered a vulnerability (tracked under ICS-VU-638779, VU#473698) affecting the Domain Name System (DNS) implementation of all versions of uClibc and uClibc-ng, a popular C standard library in IoT products. The flaw is caused by the predictability of transaction IDs included in the DNS requests generated by the library, which may allow attackers to perform DNS poisoning attacks against the target device.

According to their respective official websites, uClibc is known to be/have been used by major vendors such as Linksys, Netgear, and Axis (only until 2010, newer Axis products include other libraries), as well as Linux distributions such as Embedded Gentoo. uClibc-ng is a fork specifically designed for OpenWRT, a common OS for routers possibly deployed throughout various critical infrastructure sectors.

Because the library maintainer was unable to develop a fix, this vulnerability remains unpatched. For this reason, we are not disclosing the details of the devices on which we were able to reproduce the vulnerability.

In this blog, we start with a background of C Standard Libraries used in IoT devices, present a technical analysis of the issue and detail its exploitability, and then provide a comprehensive timeline of the disclosure process.

A new unpatched vulnerability discovered by Nozomi Networks Labs affects the DNS implementation of all versions of uClibc and uClibc-ng.

**Background: C Standard Libraries and uClibc**

In computing, a library is a collection of resources (functions, configuration data, specifications, etc.) that is shared among software. The purpose of libraries is to provide standard primitives that software can use to perform common operations (such as to access a file on a disk or perform a network operation), without the necessity of reimplementing them all the time.

A C standard library is no exception, in the sense that it is a library for the C programming language itself. A real-world example can be found in the well-known C “Hello, World!” program. When we type the pre-processor command “#include <stdio.h>” and invoke an output function (for instance, “printf”) to print “Hello, World!”, we are actually executing the code of the chosen output function provided by the selected C standard library for the implementation of the header file “stdio.h”.

Of note, uClibc is one of the possible C standard libraries available, and specifically focuses on embedded systems. Other famous C standard libraries are glibc (GNU C library), the musl libc, or the Microsoft C run-time library (CRT).

It’s important to note that a vulnerability affecting a C standard library can be a bit complex. Not only would there be hundreds or thousands of calls to the vulnerable function in multiple points of a single program, but the vulnerability would affect an indefinite number of other programs from multiple vendors configured to use that library.

**Domain Name System (DNS)**

As we know, in modern computer networks the DNS is a hierarchical database that serves the primary, and crucial, purpose of translating a domain name into its related IP address, allowing users to access resources by more easily by memorizing human-friendly names instead of complex sequences of numbers.

Under the hood, DNS requests are mostly transmitted through UDP, which is a connectionless protocol. Thus, in order to distinguish the responses of different DNS requests, besides the usual 5-tuple {source IP, source port, destination IP, destination port, protocol} and of course the query, each DNS request includes a parameter called “transaction ID”. This is a unique number per request that is generated by the client, added in each request sent, and that must be included in a DNS response to be accepted by the client as the valid one for a corresponding request. If this condition is false, the response is discarded; if true (and other checks are satisfied as well), the response is accepted and the program that asked for a translation of a certain domain name can initiate the connection to the IP address provided.

**Figure 1.** Example DNS request. The 5-tuple, txID, and query are highlighted in the red.

Similar to other C standard libraries, uClibc provides an extensive DNS client interface that allows programs to readily perform lookups and other DNS-related requests.

**Poisoning Attacks to DNS**

Because of its relevance, DNS can be a valuable target for attackers. In a DNS poisoning attack, an attacker is able to deceive a DNS client into accepting a forged response, thus inducing a certain program into performing network communications with an arbitrarily defined endpoint, and not the legitimate one. A DNS poisoning attack enables a subsequent Man-in-the-Middle attacks  because the attacker, by poisoning DNS records, is capable of rerouting network communications to a server under their control. The attacker could then steal and/or manipulate information transmitted by users, and perform other attacks against those devices to completely compromise them. The main issue here is how DNS poisoning attacks can force an authenticated response.

To have a DNS response accepted for a certain DNS request, the aforementioned 5-tuple, the query, and the transaction ID must be correctly set. Given that 1. the protocol is DNS, 2. the destination port is 53/udp, 3. the query is the target that an attacker wants to compromise, 4. the source IP address is the target machine, and 5. the destination IP address is public information (it is the IP address of the DNS server in use in a certain network), the only unknowns remain the source port and the transaction ID. It is vital that these two parameters are as unpredictable as possible, because if they are not, a poisoning attack could be possible. 

**Vulnerability Details**

While we were reviewing the trace of DNS requests performed by an IoT device under test in our lab, we noticed the pattern of DNS requests performed from the output of Wireshark. If you look at the below screenshot (Figure 2) you can see that the transaction ID is first incremental, then resets to the value 0x2, then is incremental again.

**Figure 2.** Trace of DNS requests performed by an IoT device under test

While debugging the related executable, trying to understand the root cause, we eventually noticed that the code responsible for performing the DNS requests was not part of the instructions of the executable itself, but was part of the C standard library in use, namely uClibc 0.9.33.2 (“libuClibc-0.9.33.2.so”).

A source code review revealed that the uClibc library implements DNS requests by calling the internal “__dns_lookup” function, located in the source file “/libc/inet/resolv.c”.

**Figure 3.** DNS lookup function of uClibc.

In reference to line #1240, the function declares a static variable “last_id”. This variable contains the value of the transaction ID used in the last DNS request, and is initialized with the value 1 at the first invocation of “__dns_lookup”.

Additionally, at line #1260, the function declares a variable “local_id”. This variable contains the value of the transaction ID that will be used in the upcoming DNS request, and is left uninitialized.

Afterwards, the following lines of code are executed.

**Figure 4.** DNS lookup function of uClibc (2).

In reference to line #1309, at the first DNS request, the “local_id” variable is initialized with the value of the transaction ID of the last DNS request (“last_id”). Line #1320 is the actual core of the vulnerability: “local_id” is updated by incrementing its old value by 1. Given that the value is initialized to 1 at the first invocation, this is the reason that the transaction ID was reset to 0x2 the previous Wireshark screenshot (Figure 2).

After doing a bitwise AND at line #1321, this value is also stored inside “last_id” variable at line #1323. Finally, at line #1335, the value of “local_id” is copied inside the struct resolv\_header “h” variable, which represents the actual content of the header of the DNS request. Similar revisions of this code were found in all versions available of uClibc and uClibc-ng.

**Vulnerability Exploitability**

Given that the transaction ID is now predictable, to exploit the vulnerability an attacker would need to craft a DNS response that contains the correct source port, as well as win the race against the legitimate DNS response incoming from the DNS server. Exploitability of the issue depends exactly on these factors. As the function does not apply any explicit source port randomization, it is likely that the issue can easily be exploited in a reliable way if the operating system is configured to use a fixed or predictable source port.

If the operating system applies randomization of source port (which is done by all OSs nowadays—for instance, modern Linux kernels use range 32768–60999), exploitability depends on the capacity of the attacker to bruteforce the 16 bit source port value by sending multiple DNS responses, while simultaneously winning the race against the legitimate DNS response. In this situation, exploitability depends on factors such as the bandwidth at disposal of the attacker, or on the response time of the DNS query. Additionally, it is more likely that an attacker will succeed at least once in performing a DNS poisoning attack if the target device performs a great number of identical queries in a given time frame, compared to a target that performs sporadic queries.

**Mitigations**

This vulnerability remains unpatched, however we are working with the maintainer of the library and the broader community in support of finding a solution.

Because this vulnerability remains unpatched, for the safety of the community we cannot disclose the specific devices we tested on. We can, however, disclose that they were a range of well-known IoT devices running the latest firmware versions with a high chance of them being deployed throughout all critical infrastructure.

We recommend everyone increase their network visibility and security in both IT and OT environments.

**Disclosure Process and Timeline**

As anticipated, as of the publication of this blog, the vulnerability is still unpatched. As stated in a public conversation, the maintainer was unable to develop a fix for the vulnerability, hoping for help from the community. The vulnerability was disclosed to 200+ vendors invited to the VINCE case by CERT/CC since January 2022, and a 30-day notice was given to them before the public release.

The timeline of events is reported below:

*   2021/09/13: Disclosure to ICS-CERT
*   2021/10/05: Asked for updates from ICS-CERT
*   2021/10/05: Reservation of ticket numbers ICS-VU-638779, VU#473698
*   2021/10/26: Asked for updates from ICS-CERT
*   2021/11/19: Second attempt to ask for updates from ICS-CERT
*   2021/11/29: Received invitation to participate in CERT/CC VINCE case
*   2021/12/08: Request from CERT/CC to validate vulnerability on latest 1.0.39 version, and to provide insights regarding status of disclosure
*   2021/12/09: Replied to CERT/CC, vulnerability confirmed on 1.0.39, informed CERT/CC that for now disclosure has been submitted to ICS-CERT only
*   2021/12/09 (and later): Attempts by CERT/CC to invite uClibc-ng maintainer to the VINCE case
*   2022/01/24: Multiple vendors invited to the VINCE case by CERT/CC, vulnerability disclosed to them
*   2022/02/24: Asked for updates to CERT/CC
*   2022/03/11: Attempt to contact uClibc-ng maintainer
*   2022/03/14: Maintainer confirmed he was contacted by CERT/CC, explained he was unable to fix the vulnerability by himself, explicitly asked to publicly disclose it, hoping for help from the community
*   2022/03/15-16: Discussion with CERT/CC on next steps. Planned to request a second confirmation from the maintainer, then proceed to notification of vendors of a disclosure in 30 days
*   2022/03/18: Asked for second confirmation from maintainer
*   2022/03/21: CERT/CC provided a status update in the VINCE case to vendors
*   2022/03/21-22: Discussion with CERT/CC on next steps
*   2022/03/23: Resent email to maintainer
*   2022/03/29: Proposed to CERT/CC to proceed with the 30-day notification to vendors, given lack of responses (or counter-orders) from maintainer
*   2022/04/01: CERT/CC approved the disclosure schedule proposal
*   2022/04/01: Provided a status update in the VINCE case to vendors, informed them that the vulnerability would be disclosed on May 2nd
*   2022/05/02: Public disclosure

Vyper is a pythonic smart contract language for the ethereum virtual machine. Since version 0.3.2, decimals use the full range of the underlying int168 type. multiplication of 168 bit integers can wrap in 256-bit arithmetic, but safemul does not check for that. This has been patched in v0.3.4. There are no known workarounds for this issue.

**safemath for decimals do not check for 256-bit overflow**

**Affected versions**

\>=v0.3.2

**Description**

**Impact**

since v0.3.2, decimals use the full range of the underlying int168 type. multiplication of 168 bit integers can wrap in 256-bit arithmetic, but safemul does not check for that.

**Patches****Workarounds****References**

see #2845

**For more information**

If you have any questions or comments about this advisory:

*   Open an issue in example link to repo
*   Email us at example email address

CVE-2022-29175

**safemath for decimals do not check for 256-bit overflow**

**Package**

pip vyper ( pip )

**Affected versions**

\>=v0.3.2

**Description**

**Impact**

since v0.3.2, decimals use the full range of the underlying int168 type. multiplication of 168 bit integers can wrap in 256-bit arithmetic, but safemul does not check for that.

**Patches**

to patch in v0.3.4

**Workarounds****References**

tracking in #2845

**For more information**

If you have any questions or comments about this advisory:

*   Open an issue in example link to repo
*   Email us at example email address

CVE-2022-29175: Build software better, together

The passwordless future just became closer to reality, as Microsoft, Apple, and Google pledge to make the standard possible across operating systems and browsers.

Apple, Google, and Microsoft will expand support for FIDO Alliance's passwordless standard to make logins easier across mobile devices and desktops.

By expanding support for the password-free sign-in standard from the FIDO Alliance and the World Wide Web (W3) Consortium, Google, Microsoft, and Apple will make it possible for anyone to use their mobile device to sign into an app or website on a nearby device. More importantly, users will be able to access passkeys – their FIDO sign-in credentials – across multiple devices without having to re-enroll every account on each device. This will be a key change from the current reality, where users have to sign into each website or app with each device before they can take advantage of the passwordless feature.

"We plan to implement passwordless support for FIDO Sign-in standards in Android & Chrome. Apple and Microsoft have also announced that they will offer support for their platforms," writes Sampath Srinivas, a product management director for secure authentication at Google and the president of the FIDO Alliance. "This will simplify sign-ins across devices, websites, and applications no matter the platform — without the need for a single password. These capabilities will be available over the course of the coming year."

**Case for No More Passwords**  
Passwords do not provide sufficient security – they can be stolen or guessed if the password itself isn't very good. Weak passwords accounted for more than 80% of all data breaches, according to Verizon's annual Data Breach Investigations Report. Passwords are the single largest attack vector and the root cause of most attacks -- including account takeovers, advanced persistent threats, and ransomware, says Jasson Casey, CTO of Beyond Identity. Four out of five times adversaries rely on stolen credentials for initial access and lateral movement, he says.

"Password-based authentication has failed us. Full stop," Casey says.  

There are more than 921 password attacks every second, writes Vasu Jakkal, corporate vice president of security, compliance, identity, and management at Microsoft. That represents more than double the figure over the past 12 months.

A new Google/Ipsos survey found that one in three Americans share passwords with someone else or have access to someone else's passwords, and 65% of respondents say they reuse passwords. One in five use common words or easy-to-guess terms for passwords, and 52% say they incorporate personal information such as name and birthday into the password.

"The alternatives \[to passwords\] often are unworkable, unwieldy, or just not likely to be adopted by consumers, especially the non-tech-savvy ones or those who are on the lower end of the socio-economic scale," says John Bambenek, principal threat hunter at Netenrich.  

Passwords are still ubiquitous despite the issues because they are relatively easy to implement and people know how to use them, which is why passwords still haven't gone away. Instead, security teams rely on technologies such as multifactor authentication and password managers to provide additional protection to strengthen the security around accounts, platforms, and data. 

However, these controls have made "marginal security gains," Casey says, mainly because they still rely on passwords and the second factors can be intercepted via social engineering methods (such as one-time passwords sent over SMS).

**Cross-Platform Passwordless**  
The good news is that technology is now in place to make passwordless authentication a reality, Casey says. Secure enclaves are prevalent (and resident in nearly every device), and almost all enterprise and consumer apps can leverage secure enclaves to easily delegate passwordless authentication.

The announcement from Google, Microsoft, and Apple indicates the expanded support will be implemented in macOS and Safari, Android and Chrome, and Windows and Edge. The actions used to unlock the mobile device — such as fingerprint, face scan, and device PIN — will give access to the passkey stored on the device. Signing in with the passkey is more secure because it's based on public key cryptography, Srinivas says. Even if the device is lost, the passkeys will sync back to the mobile device from cloud backup, he says.

All of this will be cross-platform. Ideally, a user would be able to sign into a website via Google Chrome on a Windows machine using a passkey on an Apple device.

"This new approach protects against phishing and sign-in will be radically more secure when compared to passwords and legacy multi-factor technologies such as one-time passcodes sent over SMS," the FIDO Alliance said in a statement.  

Implementations that rely on secure enclaves, especially those already built into modern devices, such as the Trusted Platform Module on laptops and desktops, combined with the security posture of the device itself make passwordless authentication a reality, Casey says.

Jennifer Easterly, director of the US Cybersecurity and Infrastructure Security Agency (CISA), praises the announcement, calling it "the type of forward-leaning thinking that will ultimately keep the American people safer online."

Passwordless needs to be easy. "If you don’t consider usability, your users will create your next vulnerability," Casey warns.

Microsoft, Apple, and Google Promise to Expand Passwordless Features

The same attack that allowed a threat actor to steal data from private Heroku GitHub repositories also resulted in the compromise of customer credentials, the company now says.

Salesforce subsidiary Heroku on Thursday said that the threat actor that stole Heroku GitHub integration OAuth tokens in April also accessed an internal database containing hashed and salted passwords belonging to the company's customers.

The discovery prompted Heroku to force a reset of all compromised user passwords and rotate internal Heroku credentials as well. In a security notification, which the company has been constantly updating since April 15, Heroku said it had also put additional detection mechanisms in place to mitigate future issues, without elaborating on what they were.

"We continue to work diligently in response to this Heroku incident first announced on April 15, 2022," the platform-as-a-service vendor said. "We worked with GitHub, our threat intelligence vendors, other industry partners, and have been in touch with law enforcement to assist in our investigation."

**Refresher: The Original GitHub Repo Breach**  
GitHub on April 13 disclosed to Heroku that it had detected a threat actor downloading a subset of Heroku's GitHub private repositories, including source code, on April 9. Heroku said GitHub had notified it about the threat actor gaining access to OAuth tokens issued to the company and using them to enumerate customer accounts. Heroku described the tokens as giving the threat actor read and write access to private customer GitHub repos connected to Heroku.

In an April 15 blog, GitHub CSO Mike Hanley said the threat actor used OAuth user tokens issued to Heroku and another third-party integrator, Travis-CI, to download data from repositories belonging to dozens of organizations, including npm, the node package manager used by millions of developers worldwide.

Hanley said GitHub's investigation showed the attackers also mined the contents of the downloaded GitHub private repositories for data that could be used to attack other infrastructure. He added that the attacks appeared highly targeted because of the way the attackers used the stolen OAuth tokens: First, they listed all the impacted organizations, then selected private repositories of interest and cloned them.

Heroku's investigation of the incident showed that the threat actor had used a stolen OAuth token associated with an internal "machine account" to access a Heroku database containing OAuth tokens that are used for customer GitHub integration.

The threat actor gained access to the Heroku database on April 7 and downloaded the stored tokens — then used them to download customer data two days later, Heroku said. Following that discovery, Heroku revoked all its GitHub integration OAuth tokens to prevent customers from deploying apps via GitHub using Heroku's dashboard or automation.

**Broader Impact Than Initially Assumed**  
Heroku on Thursday said that its ongoing investigation of the breach showed the attacker had used the same machine-account OAuth token to access the internal database containing the hashed usernames and passwords belonging to the company's customers.

The incident has highlighted why organizations need to pay close attention to the security of their OAuth authentication mechanisms, security experts say.

Casey Bisson, head of product and developer relations at BluBracket, says an attack using OAuth tokens can interact with the service that issued the tokens using all the permissions that were granted to the original client. "People and companies depend on OAuth integrations to securely allow another service to access code in private repos, as is needed to support CI tests and run code coverage reports," he says, pointing to two examples.

**OAuth: Better Account Protection, As Long as Tokens Are Safe**  
Compared to the alternative of sharing passwords between services, OAuth tokens enable more secure data sharing. For example, if it had been passwords that were stolen, the level of access the attackers might have gained would likely be even greater. And the initial mitigation and long-term fix would become more complex, Bisson says.

However, OAuth tokens are commonly used to automate cloud services such as code repositories and DevOps pipelines, notes Ray Kelly, fellow at NTT Application Security. So, a malicious actor with a stolen token can steal corporate IP or modify source code in repositories such as GitHub. Or they could use it to spread malware or steal sensitive data from organizations, he says. "Special care should always be taken when it comes to protecting tokens. They should never be publicly available or shared outside of the organization," Kelly says.

GitHub itself has said that starting the end of 2023, it would require all developers who contribute code to the repository to use multifactor authentication to access their accounts. The company described it as a move designed to bolster the security of code and IP stored in GitHub repositories amid a surge in attacks targeting the software supply chain.

Heroku: Cyberattacker Used Stolen OAuth Tokens to Steal Customer Account Credentials

TOTOLINK N600R v5.3c.5507_B20171031 was discovered to contain a command injection vulnerability via the QUERY_STRING parameter in the "Main" function.

**TOTOLINK N600R V5.3c.5507\_B20171031 Has an command injection vulnerability****Overview**

*   **Type**: command injection vulnerability
*   **Vendor**: TOTOLINK (https://www.totolink.net/)
*   **Products**: WiFi Router, such as N600R V5.3c.5507\_B20171031
*   \*\*Firmware download address:\*\*https://www.totolink.net/data/upload/20200728/f984576c47289d782ed65e67edbf06e2.zip

**Description****1.Product Information:**

TOTOLINK N600R V5.3c.5507\_B20171031 router, the latest version of simulation overview：

**2\. Vulnerability details**

TOTOLINK N600R V5.3c.5507\_B20171031 was discovered to contain a command injection vulnerability in the "Main" function. This vulnerability allows attackers to execute arbitrary commands via the QUERY\_STRING parameter.

We can see that the os will get  QUERY_STRING without filter splice to the string ;ps; and execute it. So, If we can control the QUERY_STRING, it can be command injection.

**3\. Recurring vulnerabilities and POC**

In order to reproduce the vulnerability, the following steps can be followed:

1.  Boot the firmware by qemu-system or other ways (real machine)
2.  Attack with the following POC attacks

    GET /cgi-bin/downloadFlile.cgi?;ls; HTTP/1.1 
    Host: 192.168.0.1 
    User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0 
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 
    Accept-Encoding: gzip, deflate 
    Connection: keep-alive 
    Upgrade-Insecure-Requests: 1 
    Cache-Control: max-age=0

CVE-2022-27411: GitHub - ejdhssh/IOT_Vul

A denial of service vulnerability exists in the libxm_av.so DemuxCmdInBuffer functionality of Anker Eufy Homebase 2 2.1.8.5h. A specially-crafted set of network packets can lead to a device reboot. An attacker can send packets to trigger this vulnerability.

**Summary**

A denial of service vulnerability exists in the libxm\_av.so DemuxCmdInBuffer functionality of Anker Eufy Homebase 2 2.1.8.5h. A specially-crafted set of network packets can lead to a device reboot. An attacker can send packets to trigger this vulnerability.

**Tested Versions**

Anker Eufy Homebase 2 2.1.8.5h

**Product URLs**

Eufy Homebase 2 - https://us.eufylife.com/products/t88411d1

**CVSSv3 Score**

7.4 - CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H

**CWE**

CWE-190 - Integer Overflow or Wraparound

**Details**

The Eufy Homebase 2 is the video storage and networking gateway that enables the functionality of the Eufy Smarthome ecosystem. All Eufy devices connect back to this device, and this device connects out to the cloud, while also providing assorted services to enhance other Eufy Smarthome devices.

Among the home_security binary’s responsibilities, communications with the cloud and with smarthome devices is the most important. While the binary itself is somewhat opaque with regards to the actual implementation of this, a good chunk of the network functionality is within an imported libxm_av.so library. This library normally creates five different network servers, as so:

      tcp
        32392 - UDPRecvClient path
        32293 - WifiComSend_Pth            
        32295 - WifiComRecv_Pth            
        32290 - DspComSvr_Path - recv   ** not seen **
        32292 - DspComSvr_Path - send   ** not seen **
    
      udp
        32380 - UDPComCreate => UdpRecvSvr_pth 
        32392 - UdpSndSvr                      
    

While the code paths of some of these seem to converge or complement each other, these servers are all related to communications between the Homebase 2 and the smarthome devices. For today’s writeup we take a brief look into the WifiComRecv_Pth on TCP port 32295. Just like all the other ports, this codepath uses the getpeermac() function for defacto authentication, in that a network connection’s IP address must have an arp table entry on the br0 interface to be allowed to talk to any of these ports. Assuming that one has a vulnerabilty to bypass this check (see TALOS-2022-1479, libxm\_av.so getpeermac() authentication bypass vulnerability), or if one has compromised one of the smarthome devices that are resident on the br0 192.168.32.0/24 network, then one can essentially talk to the Eufy Homebase like any other device that has been paired. So what can one do with this?

Looking at the WifiComRecv_Pth, let’s take a look at what the message structure looks like:

    struct WifiComPkt{
        uint32_t magic; //[1]
        uint32_t opcode;
        uint32_t datalen; // [2]
        uint8_t data[]// [3]
    }
    

The packet must start with the magic bytes "\x55\x55\x00\xff" at \[1\]. We have an opcode as expected, and then there’s a datasize at \[2\] which determines the length of the array at \[3\]. All pretty standard. So let’s now examine the code handling these messages:

    void*  WifiComRecv_client_pth(struct mall_20* malloced_arg) { 
        //[...]
        0002d068      while (true)
        0002d068          if (g_XM_RUNNING != 0)  // [4]
        0002d14c              int32_t recv_ret
        0002d14c              uint32_t bytes_demuxed
        0002d14c              char* rbufptr
        0002d14c              do
        0002d088                  recv_ret = recv(sockfd: mall20.fd, buf: &buffer[pWriteOffset], len: 0x400 - pWriteOffset, flags: 0x40) // [5]
        0002d094                  if (recv_ret s> 0)
        0002d0a0                      pWriteOffset = pWriteOffset + recv_ret
        0002d0b4                      bytes_demuxed = DemuxCmdInBuffer(buffer: &buffer[pReadOffset], inpsize: pWriteOffset - pReadOffset, mall_20: &mall20) // [6]
    }
    

The server runs for as long as the g_XM_RUNNING global is switched on at \[4\] and constantly reads packets into a size 0x400 buffer on the stack at \[5\], which is subsequently parsed inside the DemuxCmdInBuffer function at \[6\].

    0002cd04  void* DemuxCmdInBuffer(char* buffer, uint32_t inpsize, struct mall_20* mall_20)
    0002cd6c      uint8_t* var_3c
    // [...]
    0002cde8      int32_t size_m4 = inpsize - 4
    0002cdf4      uint32_t bytes_left = 0
    0002cdf0      if (size_m4 s> 0)
    0002ce00          int32_t size_mc = inpsize - 0xc
    0002ce04          uint32_t bytesread = 0
    0002ce24          do
    0002ce2c              struct WifiPkt* wifipkt = &buffer[bytesread]
    0002ce38              while (wifipkt->magic == 0xff005555)                   // [7]
    0002ce54                  if (bytesread + 0xb s>= inpsize) 
    0002cefc                      return inpsize - bytesread
    0002ce74                  bytes_left = inpsize - bytesread
    0002ce70                  if (bytesread + wifipkt->size + 0xb s>= inpsize)   // [8]
    0002cefc                      return bytes_left
    0002ce7c                  XM_LOG(fname: "Xm_WifiComServer.c", line: 0x8a2, 2, 0, fmtstr: "cmd offset:%d\n", values: bytesread)
    0002ce94                  int32_t wificmd_ret = WifiCommandRespProc(wifipkt: wifipkt, mall_20: mall_20)  // [9]
    

After iterating through our data packet until finding the 0xff005555 magic bytes at \[7\], we finally get to our vulnerability: a lack of checking of the Wifipkt->size field inside the DemuxCmdInBuffer function, which allows us to cause an integer overflow at \[8\]. Unfortunately for attacker purposes, this WifiPkt->datalen field does not actually do that much inside WifiCommandRespProc \[9\] besides being checked and also potentially used as the length in an fwrite call. The best we can really get out of this vulnerability is setting the datalen large enough such that an out-of-bounds read occurs after advancing its read pointer by WifiPkt->datalen+0xb. This results in an unmapped read and a binary crash. If the home_security process crashes enough times within a given period, a device reboot will also occur, resulting in a denial of service.

**Crash Information**

    [ 5886.888000] do_page_fault() #2: sending SIGSEGV to home_security(23710) for invalid read access from
    [ 5886.888000] 282e7aa4 (pc == 778c4e30, ra == 778c4e9c)
    
    <(^.^)>#info reg
              zero       at       v0       v1       a0       a1       a2       a3
     R0   00000000 1100ff00 487f5f11 00000001 00000001 00000001 00000000 00000001
                t0       t1       t2       t3       t4       t5       t6       t7
     R8   00000000 fffffffe 00000000 00000000 9b64c2b0 8758a11c 00000000 00000007
                s0       s1       s2       s3       s4       s5       s6       s7
     R16  b780a0ff 33e09af7 7c5ff9f8 00000010 0000000c ff005555 7700a4d1 7700b920
                t8       t9       k0       k1       gp       sp       s8       ra
     R24  00000000 773d36ec 00000000 00000000 77026560 7c5ff960 7c5ff9d8 76ff6e9c
                sr       lo       hi      bad    cause       pc
          0100ff13 067e836c 001154dc 33e09af7 00800010 76ff6e30
               fsr      fir
          00000000 00000000
    
    <(^.^)>#x/10i $pc-0x10
       0x76d3ae20 <WifiComRecv_client_pth+504>:     li      a1,2280
       0x76d3ae24 <WifiComRecv_client_pth+508>:     li      a2,2
       0x76d3ae28 <WifiComRecv_client_pth+512>:     jalr    t9
       0x76d3ae2c <WifiComRecv_client_pth+516>:     move    a3,zero
    => 0x76d3ae30 <WifiComRecv_client_pth+520>:     lw      gp,32(sp)
       0x76d3ae34 <WifiComRecv_client_pth+524>:     move    s4,s2
       0x76d3ae38 <WifiComRecv_client_pth+528>:     move    s0,s2
       0x76d3ae3c <WifiComRecv_client_pth+532>:     move    s1,zero
       0x76d3ae40 <WifiComRecv_client_pth+536>:     lw      t9,-31148(gp)
    

**Vendor Response**

Fixed version 3.1.8.7 and 3.1.8.7h is in grayscale on Homebase2

**Timeline**

2022-03-11 - Vendor disclosure  
2022-04-15 - Vendor patched  
2022-05-05 - Public disclosure

Discovered by Lilith &gt;\_&gt; of Cisco Talos.

Tag

#mac