[meta-virtualization][dunfell][PATCH] lxc: Fix CVE-2022-47952

[meta-virtualization][dunfell][PATCH] lxc: Fix CVE-2022-47952

[Bhabu Bindu]

From: Omkar Patil <omkar.patil@kpit.com>

lxc-user-nic install setuid root, and may allow local users to infer
whether any file exists, even within a protected directory tree, because
“Failed to open” often indicates that a file does not exist, whereas
“does not refer to a network namespace path” often indicates that a file
exists.

Reference: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1783591

Signed-off-by: Virendra Thakur <virendrak@kpit.com>
---
 .../lxc/files/CVE-2022-47952.patch            | 74 +++++++++++++++++++
 recipes-containers/lxc/lxc_4.0.9.bb           |  1 +
 2 files changed, 75 insertions(+)
 create mode 100644 recipes-containers/lxc/files/CVE-2022-47952.patch

diff --git a/recipes-containers/lxc/files/CVE-2022-47952.patch b/recipes-containers/lxc/files/CVE-2022-47952.patch
new file mode 100644
index 0000000..eca2ad6
--- /dev/null
+++ b/recipes-containers/lxc/files/CVE-2022-47952.patch
@@ -0,0 +1,74 @@
+From 1b0469530d7a38b8f8990e114b52530d1bf7f3b8 Mon Sep 17 00:00:00 2001
+From: Maher Azzouzi <maherazz04@gmail.com>
+Date: Sun, 25 Dec 2022 13:50:25 +0100
+Subject: [PATCH] Patching an incoming CVE (CVE-2022-47952)
+
+lxc-user-nic in lxc through 5.0.1 is installed setuid root, and may
+allow local users to infer whether any file exists, even within a
+protected directory tree, because "Failed to open" often indicates
+that a file does not exist, whereas "does not refer to a network
+namespace path" often indicates that a file exists. NOTE: this is
+different from CVE-2018-6556 because the CVE-2018-6556 fix design was
+based on the premise that "we will report back to the user that the
+open() failed but the user has no way of knowing why it failed";
+however, in many realistic cases, there are no plausible reasons for
+failing except that the file does not exist.
+
+PoC:
+> % ls /l
+> ls: cannot open directory '/l': Permission denied
+> % /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic delete lol lol /l/h/tt h h
+> cmd/lxc_user_nic.c: 1096: main: Failed to open "/l/h/tt" <----- file does not exist.
+> % /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic delete lol lol /l/h/t h h
+> cmd/lxc_user_nic.c: 1101: main: Path "/l/h/t" does not refer to a network namespace path <---- file exist!
+
+Signed-off-by: MaherAzzouzi <maherazz04@gmail.com>
+Acked-by: Serge Hallyn <serge@hallyn.com>
+
+Upstream-Status: Backport [https://github.com/lxc/lxc/commit/1b0469530d7a38b8f8990e114b52530d1bf7f3b8]
+CVE: CVE-2022-47952
+Comment: No Hunk refreshed
+Signed-off-by: Virendra Thakur <virendrak@kpit.com>
+---
+ src/lxc/cmd/lxc_user_nic.c | 15 ++++++---------
+ 1 file changed, 6 insertions(+), 9 deletions(-)
+
+diff --git a/src/lxc/cmd/lxc_user_nic.c b/src/lxc/cmd/lxc_user_nic.c
+index a91e2259d5..69bc6f17d1 100644
+--- a/src/lxc/cmd/lxc_user_nic.c
++++ b/src/lxc/cmd/lxc_user_nic.c
+@@ -1085,20 +1085,17 @@ int main(int argc, char *argv[])
+ 	} else if (request == LXC_USERNIC_DELETE) {
+ 		char opath[LXC_PROC_PID_FD_LEN];
+ 
+-		/* Open the path with O_PATH which will not trigger an actual
+-		 * open(). Don't report an errno to the caller to not leak
+-		 * information whether the path exists or not.
+-		 * When stracing setuid is stripped so this is not a concern
+-		 * either.
+-		 */
++		// Keep in mind CVE-2022-47952: It's crucial not to leak any
++		// information whether open() succeeded of failed.
++
+ 		netns_fd = open(args.pid, O_PATH | O_CLOEXEC);
+ 		if (netns_fd < 0) {
+-			usernic_error("Failed to open \"%s\"\n", args.pid);
++			usernic_error("Failed while opening netns file for \"%s\"\n", args.pid);
+ 			_exit(EXIT_FAILURE);
+ 		}
+ 
+ 		if (!fhas_fs_type(netns_fd, NSFS_MAGIC)) {
+-			usernic_error("Path \"%s\" does not refer to a network namespace path\n", args.pid);
++			usernic_error("Failed while opening netns file for \"%s\"\n", args.pid);
+ 			close(netns_fd);
+ 			_exit(EXIT_FAILURE);
+ 		}
+@@ -1112,7 +1109,7 @@ int main(int argc, char *argv[])
+ 		/* Now get an fd that we can use in setns() calls. */
+ 		ret = open(opath, O_RDONLY | O_CLOEXEC);
+ 		if (ret < 0) {
+-			CMD_SYSERROR("Failed to open \"%s\"\n", args.pid);
++			CMD_SYSERROR("Failed while opening netns file for \"%s\"\n", args.pid);
+ 			close(netns_fd);
+ 			_exit(EXIT_FAILURE);
+ 		}
diff --git a/recipes-containers/lxc/lxc_4.0.9.bb b/recipes-containers/lxc/lxc_4.0.9.bb
index f7cab78..7240589 100644
--- a/recipes-containers/lxc/lxc_4.0.9.bb
+++ b/recipes-containers/lxc/lxc_4.0.9.bb
@@ -55,6 +55,7 @@ SRC_URI = "http://linuxcontainers.org/downloads/${BPN}/${BPN}-${PV}.tar.gz \
         file://skip_rootfs_pinning_for_read_only_filesystem.patch \
         file://add_lxc_init_groups_config_key.patch \
         file://lxc-conf-improve-read-only-sys-with-read-write-sys-devic.patch \
+        file://CVE-2022-47952.patch \
 	"
 
 SRC_URI[md5sum] = "365fcca985038910e19a1e0fff15ed07"
-- 
2.17.1

Re: [meta-virtualization][dunfell][PATCH] lxc: Fix CVE-2022-47952

[Bruce Ashfield]

There are newer 4.0.x releases of LXC available.

We should confirm that they address this CVE, and do an update,
versus a single patch.

Also, when sending a CVE fix for a stable/maintained branch,
we also need to indicate that the CVE is already covered by
the newer versions of the package on those branches (since
we don't only want to fix a CVE on an older branch).

This came in three times .. I'm dropping all three from my
queue and will wait to hear about the 4.0.12+ version bump.

Bruce

In message: [meta-virtualization][dunfell][PATCH] lxc: Fix CVE-2022-47952
on 20/02/2023 Bhabu Bindu wrote:

> From: Omkar Patil <omkar.patil@kpit.com>
> 
> lxc-user-nic install setuid root, and may allow local users to infer
> whether any file exists, even within a protected directory tree, because
> “Failed to open” often indicates that a file does not exist, whereas
> “does not refer to a network namespace path” often indicates that a file
> exists.
> 
> Reference: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1783591
> 
> Signed-off-by: Virendra Thakur <virendrak@kpit.com>
> ---
>  .../lxc/files/CVE-2022-47952.patch            | 74 +++++++++++++++++++
>  recipes-containers/lxc/lxc_4.0.9.bb           |  1 +
>  2 files changed, 75 insertions(+)
>  create mode 100644 recipes-containers/lxc/files/CVE-2022-47952.patch
> 
> diff --git a/recipes-containers/lxc/files/CVE-2022-47952.patch b/recipes-containers/lxc/files/CVE-2022-47952.patch
> new file mode 100644
> index 0000000..eca2ad6
> --- /dev/null
> +++ b/recipes-containers/lxc/files/CVE-2022-47952.patch
> @@ -0,0 +1,74 @@
> +From 1b0469530d7a38b8f8990e114b52530d1bf7f3b8 Mon Sep 17 00:00:00 2001
> +From: Maher Azzouzi <maherazz04@gmail.com>
> +Date: Sun, 25 Dec 2022 13:50:25 +0100
> +Subject: [PATCH] Patching an incoming CVE (CVE-2022-47952)
> +
> +lxc-user-nic in lxc through 5.0.1 is installed setuid root, and may
> +allow local users to infer whether any file exists, even within a
> +protected directory tree, because "Failed to open" often indicates
> +that a file does not exist, whereas "does not refer to a network
> +namespace path" often indicates that a file exists. NOTE: this is
> +different from CVE-2018-6556 because the CVE-2018-6556 fix design was
> +based on the premise that "we will report back to the user that the
> +open() failed but the user has no way of knowing why it failed";
> +however, in many realistic cases, there are no plausible reasons for
> +failing except that the file does not exist.
> +
> +PoC:
> +> % ls /l
> +> ls: cannot open directory '/l': Permission denied
> +> % /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic delete lol lol /l/h/tt h h
> +> cmd/lxc_user_nic.c: 1096: main: Failed to open "/l/h/tt" <----- file does not exist.
> +> % /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic delete lol lol /l/h/t h h
> +> cmd/lxc_user_nic.c: 1101: main: Path "/l/h/t" does not refer to a network namespace path <---- file exist!
> +
> +Signed-off-by: MaherAzzouzi <maherazz04@gmail.com>
> +Acked-by: Serge Hallyn <serge@hallyn.com>
> +
> +Upstream-Status: Backport [https://github.com/lxc/lxc/commit/1b0469530d7a38b8f8990e114b52530d1bf7f3b8]
> +CVE: CVE-2022-47952
> +Comment: No Hunk refreshed
> +Signed-off-by: Virendra Thakur <virendrak@kpit.com>
> +---
> + src/lxc/cmd/lxc_user_nic.c | 15 ++++++---------
> + 1 file changed, 6 insertions(+), 9 deletions(-)
> +
> +diff --git a/src/lxc/cmd/lxc_user_nic.c b/src/lxc/cmd/lxc_user_nic.c
> +index a91e2259d5..69bc6f17d1 100644
> +--- a/src/lxc/cmd/lxc_user_nic.c
> ++++ b/src/lxc/cmd/lxc_user_nic.c
> +@@ -1085,20 +1085,17 @@ int main(int argc, char *argv[])
> + 	} else if (request == LXC_USERNIC_DELETE) {
> + 		char opath[LXC_PROC_PID_FD_LEN];
> + 
> +-		/* Open the path with O_PATH which will not trigger an actual
> +-		 * open(). Don't report an errno to the caller to not leak
> +-		 * information whether the path exists or not.
> +-		 * When stracing setuid is stripped so this is not a concern
> +-		 * either.
> +-		 */
> ++		// Keep in mind CVE-2022-47952: It's crucial not to leak any
> ++		// information whether open() succeeded of failed.
> ++
> + 		netns_fd = open(args.pid, O_PATH | O_CLOEXEC);
> + 		if (netns_fd < 0) {
> +-			usernic_error("Failed to open \"%s\"\n", args.pid);
> ++			usernic_error("Failed while opening netns file for \"%s\"\n", args.pid);
> + 			_exit(EXIT_FAILURE);
> + 		}
> + 
> + 		if (!fhas_fs_type(netns_fd, NSFS_MAGIC)) {
> +-			usernic_error("Path \"%s\" does not refer to a network namespace path\n", args.pid);
> ++			usernic_error("Failed while opening netns file for \"%s\"\n", args.pid);
> + 			close(netns_fd);
> + 			_exit(EXIT_FAILURE);
> + 		}
> +@@ -1112,7 +1109,7 @@ int main(int argc, char *argv[])
> + 		/* Now get an fd that we can use in setns() calls. */
> + 		ret = open(opath, O_RDONLY | O_CLOEXEC);
> + 		if (ret < 0) {
> +-			CMD_SYSERROR("Failed to open \"%s\"\n", args.pid);
> ++			CMD_SYSERROR("Failed while opening netns file for \"%s\"\n", args.pid);
> + 			close(netns_fd);
> + 			_exit(EXIT_FAILURE);
> + 		}
> diff --git a/recipes-containers/lxc/lxc_4.0.9.bb b/recipes-containers/lxc/lxc_4.0.9.bb
> index f7cab78..7240589 100644
> --- a/recipes-containers/lxc/lxc_4.0.9.bb
> +++ b/recipes-containers/lxc/lxc_4.0.9.bb
> @@ -55,6 +55,7 @@ SRC_URI = "http://linuxcontainers.org/downloads/${BPN}/${BPN}-${PV}.tar.gz \
>          file://skip_rootfs_pinning_for_read_only_filesystem.patch \
>          file://add_lxc_init_groups_config_key.patch \
>          file://lxc-conf-improve-read-only-sys-with-read-write-sys-devic.patch \
> +        file://CVE-2022-47952.patch \
>  	"
>  
>  SRC_URI[md5sum] = "365fcca985038910e19a1e0fff15ed07"
> -- 
> 2.17.1
> 

Re: [meta-virtualization] [dunfell][PATCH] lxc: Fix CVE-2022-47952

[Bruce Ashfield]

On Thu, Apr 20, 2023 at 5:54 AM Ranjitsinh Rathod via
lists.yoctoproject.org
<ranjitsinh.rathod=kpit.com@lists.yoctoproject.org> wrote:
>
> Hi Bruce,
>
> When I checked in https://github.com/lxc/lxc/compare/stable-4.0 branch and check, it seems the CVE is not fixed there and so this fix is not available for the 4.0.12 version as well if we sned the bump.
>
> Please suggest what we can do here to fix the CVE at least for the dunfell branch.
>
> If CVE is not fixed in the stable branch for lxc upstream, do we not going to fix this CVE by applying a patch?
>

In a situation like this, we should still do the bump .. as there are
obviously more bugfixes than just the CVE in the newer version.

So do the bump, and then include the CVE patch as an explicit backport
from upstream at the same time.

Bruce

> Thanks,
> Ranjitsinh Rathod
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#8002): https://lists.yoctoproject.org/g/meta-virtualization/message/8002
> Mute This Topic: https://lists.yoctoproject.org/mt/97081672/1050810
> Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II