From 86878f61d1c1d61119035c7e06efc2757f519474 Mon Sep 17 00:00:00 2001 From: Vijay Anusuri Date: Fri, 20 Sep 2024 15:45:31 +0530 Subject: [PATCH] tgt: Security fix for CVE-2024-45751 Upstream-Status: Backport from https://github.com/fujita/tgt/commit/abd8e0d987ab56013d360077202bf2aca20a42dd Reference: https://ubuntu.com/security/CVE-2024-45751 Signed-off-by: Vijay Anusuri Signed-off-by: Armin Kuster --- .../tgt/files/CVE-2024-45751.patch | 68 +++++++++++++++++++ .../recipes-extended/tgt/tgt_git.bb | 1 + 2 files changed, 69 insertions(+) create mode 100644 meta-networking/recipes-extended/tgt/files/CVE-2024-45751.patch diff --git a/meta-networking/recipes-extended/tgt/files/CVE-2024-45751.patch b/meta-networking/recipes-extended/tgt/files/CVE-2024-45751.patch new file mode 100644 index 0000000000..e7f09c7e92 --- /dev/null +++ b/meta-networking/recipes-extended/tgt/files/CVE-2024-45751.patch @@ -0,0 +1,68 @@ +From abd8e0d987ab56013d360077202bf2aca20a42dd Mon Sep 17 00:00:00 2001 +From: Richard Weinberger +Date: Tue, 3 Sep 2024 16:14:58 +0200 +Subject: [PATCH] chap: Use proper entropy source + +The challenge sent to the initiator is based on a poor +source of randomness, it uses rand() without seeding it by srand(). +So the glibc PRNG is always seeded with 1 and as a consequence the +sequence of challenges is always the same. + +An attacker which is able to monitor network traffic can apply a replay +attack to bypass the CHAP authentication. All the attacker has to do +is waiting for the server or the service to restart and replay with a +previously record CHAP session which fits into the sequence. + +To overcome the issue, use getrandom() to query the kernel random +number generator. +Also always send a challenge of length CHAP_CHALLENGE_MAX, there is no +benefit in sending a variable length challenge. + +Signed-off-by: Richard Weinberger + +Upstream-Status: Backport [https://github.com/fujita/tgt/commit/abd8e0d987ab56013d360077202bf2aca20a42dd] +CVE: CVE-2024-45751 +Signed-off-by: Vijay Anusuri +--- + usr/iscsi/chap.c | 12 +++++------- + 1 file changed, 5 insertions(+), 7 deletions(-) + +diff --git a/usr/iscsi/chap.c b/usr/iscsi/chap.c +index aa0fc671..b89ecabd 100644 +--- a/usr/iscsi/chap.c ++++ b/usr/iscsi/chap.c +@@ -28,6 +28,7 @@ + #include + #include + #include ++#include + + #include "iscsid.h" + #include "tgtd.h" +@@ -359,22 +360,19 @@ static int chap_initiator_auth_create_challenge(struct iscsi_connection *conn) + sprintf(text, "%u", (unsigned char)conn->auth.chap.id); + text_key_add(conn, "CHAP_I", text); + +- /* +- * FIXME: does a random challenge length provide any benefits security- +- * wise, or should we rather always use the max. allowed length of +- * 1024 for the (unencoded) challenge? +- */ +- conn->auth.chap.challenge_size = (rand() % (CHAP_CHALLENGE_MAX / 2)) + CHAP_CHALLENGE_MAX / 2; ++ conn->auth.chap.challenge_size = CHAP_CHALLENGE_MAX; + + conn->auth.chap.challenge = malloc(conn->auth.chap.challenge_size); + if (!conn->auth.chap.challenge) + return CHAP_TARGET_ERROR; + ++ if (getrandom(conn->auth.chap.challenge, conn->auth.chap.challenge_size, 0) != conn->auth.chap.challenge_size) ++ return CHAP_TARGET_ERROR; ++ + p = text; + strcpy(p, "0x"); + p += 2; + for (i = 0; i < conn->auth.chap.challenge_size; i++) { +- conn->auth.chap.challenge[i] = rand(); + sprintf(p, "%.2hhx", conn->auth.chap.challenge[i]); + p += 2; + } diff --git a/meta-networking/recipes-extended/tgt/tgt_git.bb b/meta-networking/recipes-extended/tgt/tgt_git.bb index 42141cb72d..28ea44893b 100644 --- a/meta-networking/recipes-extended/tgt/tgt_git.bb +++ b/meta-networking/recipes-extended/tgt/tgt_git.bb @@ -11,6 +11,7 @@ SRC_URI = "git://github.com/fujita/tgt.git;branch=master;protocol=https \ file://0001-Correct-the-path-of-header-files-check-in-Yocto-buil.patch \ file://0001-usr-Makefile-WARNING-fix.patch \ file://usr-Makefile-apply-LDFLAGS-to-all-executables.patch \ + file://CVE-2024-45751.patch \ " SRC_URI += "file://tgtd.init \ file://tgtd.service \