mirrors/meta-openembedded
1
0
Fork 0
mirror of https://github.com/openembedded/meta-openembedded.git synced 2026-06-13 17:39:57 +00:00
Code Issues Projects Releases Wiki Activity

tgt: Security fix for CVE-2024-45751

Browse Source 
Upstream-Status: Backport from https://github.com/fujita/tgt/commit/abd8e0d987ab56013d360077202bf2aca20a42dd

Reference: https://ubuntu.com/security/CVE-2024-45751

Signed-off-by: Vijay Anusuri <vanusuri@mvista.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
This commit is contained in:
Vijay Anusuri
2024-09-20 15:45:31 +05:30
committed by Armin Kuster
parent 4d0efedaa6
commit 86878f61d1
2 changed files with 69 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
meta-networking/recipes-extended/tgt/files/CVE-2024-45751.patch
+68
View File
@@ -0,0 +1,68 @@
From abd8e0d987ab56013d360077202bf2aca20a42dd Mon Sep 17 00:00:00 2001
From: Richard Weinberger <richard@nod.at>
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 <richard@nod.at>
Upstream-Status: Backport [https://github.com/fujita/tgt/commit/abd8e0d987ab56013d360077202bf2aca20a42dd]
CVE: CVE-2024-45751
Signed-off-by: Vijay Anusuri <vanusuri@mvista.com>
---
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 <stdio.h>
#include <stdlib.h>
#include <string.h>
+#include <sys/random.h>
#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;
}
meta-networking/recipes-extended/tgt/tgt_git.bb
+1
View File
@@ -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 \