В ядре Linux устранена следующая уязвимость:
SUNRPC: ужесточена проверка длины gss_unwrap_resp_priv.
gss_unwrap_resp_priv() проверяет непрозрачную длину RPCSEC_GSS с помощью
смещение = (u8 *)(p) - (u8 *)head->iov_base;
if (смещение + opaque_len > rcv_buf->len)
перейти к unwrap_failed;
maj_stat = gss_unwrap(ctx->gc_gss_ctx, offset,
смещение + opaque_len, rcv_buf);
Оба операнда — это u32, а сумма вычисляется в u32. Ответ с
opaque_len рядом с 0xffffffff делает смещение + opaque_len переносом на небольшой размер.
значение ниже rcv_buf->len, поэтому связанная проверка проходит и
gss_unwrap() вызывается с end <begin. В чеке также отсутствует
нижняя граница, поэтому любой opaque_len в [0, GSS_KRB5_TOK_HDR_LEN)
принято и отправлено в gss_krb5_unwrap_v2(), который предварительно расшифровывает
заголовок читается на точках ptr+4 и ptr+6, а затем проходит мимо токена.
NFS-сервер krb5p, возвращающий созданный ответ RPCSEC_GSS, может управлять
клиент за пределами границ читает в gss_krb5_unwrap_v2() и
следующий цикл Rotate_left(). Исправьте это, заменив единственную комбинированную проверку тремя охранниками, которые
безопасны в арифметике u32 и обеспечивают соблюдение минимума RFC 4121.
длина внешнего токена:
if (смещение > rcv_buf->len)
перейти к unwrap_failed;
if (opaque_len > rcv_buf->len — смещение)
перейти к unwrap_failed;
если (opaque_len < GSS_KRB5_TOK_HDR_LEN)
перейти к unwrap_failed;
Первый охранник делает вычитание во втором охраннике.
безусловно безопасный; смещение происходит от успешного
xdr_inline_decode() в голове kvec, так что на практике это уже
удовлетворяет границе. Пол отражает добавленную проверку на стороне сервера.
в коммите 5b757c2e57a5 («SUNRPC: svcauth_gss: применить токен krb5
минимальная длина»).
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: harden gss_unwrap_resp_priv length checks gss_unwrap_resp_priv() validates the RPCSEC_GSS opaque length with offset = (u8 *)(p) - (u8 *)head->iov_base; if (offset + opaque_len > rcv_buf->len) goto unwrap_failed; maj_stat = gss_unwrap(ctx->gc_gss_ctx, offset, offset + opaque_len, rcv_buf); Both operands are u32 and the sum is computed in u32. A reply with opaque_len near 0xffffffff makes offset + opaque_len wrap to a small value that is below rcv_buf->len, so the bound check passes and gss_unwrap() is called with end < begin. The check also lacks a lower bound, so any opaque_len in [0, GSS_KRB5_TOK_HDR_LEN) is accepted and forwarded to gss_krb5_unwrap_v2(), whose pre-decrypt header reads at ptr+4 and ptr+6 then run past the token. A krb5p NFS server returning a crafted RPCSEC_GSS reply can drive the client into out-of-bounds reads in gss_krb5_unwrap_v2() and the rotate_left() loop that follows. Fix by replacing the single combined check with three guards that are safe in u32 arithmetic and that enforce the RFC 4121 minimum outer token length: if (offset > rcv_buf->len) goto unwrap_failed; if (opaque_len > rcv_buf->len - offset) goto unwrap_failed; if (opaque_len < GSS_KRB5_TOK_HDR_LEN) goto unwrap_failed; The first guard makes the subtraction in the second guard unconditionally safe; offset is derived from a successful xdr_inline_decode() in the head kvec, so in practice it already satisfies the bound. The floor mirrors the server-side check added in commit 5b757c2e57a5 ("SUNRPC: svcauth_gss: enforce krb5 token minimum length").
Характеристики атаки
Последствия
Строка CVSS v3.1