Служба синхронизации часов на уровне приложения LoRaWAN анализирует нисходящие каналы в clock_sync_package_callback() (subsys/lorawan/services/lock_sync.c). Его командный цикл гарантирует только то, что однобайтовый идентификатор команды находится в пределах; для команды CLOCK_SYNC_CMD_APP_TIME (AppTimeAns) обработчик затем считывает 4-байтовую коррекцию времени через sys_get_le32() плюс 1-байтовый токен, не проверяя, остаются ли 5 байтов в буфере приема (len - rx_pos). Таким образом, короткий или созданный AppTimeAns считывает до 5 байтов после конца расшифрованной полезной нагрузки.
Полезная нагрузка (rx_buf/len) — это расшифрованный кадр приложения, доставленный в зарегистрированный обратный вызов нисходящей линии связи (mcps_indiction->Buffer/BufferSize). Для достижения обработчика требуется кадр на порту синхронизации часов, который проходит проверку целостности MAC-адреса LoRaWAN и расшифровку FRMPayload, поэтому практическим злоумышленником является злонамеренный или скомпрометированный сервер сети/приложений (назначенный отправитель AppTimeAns) или сторона, владеющая ключами сеанса, а не произвольный радиопрослушиватель. Чрезмерное чтение ограничено: резервное хранилище представляет собой фиксированный статический буфер размером 255 байт, поэтому несколько случайных байтов не вызывают сбоев, а считанные значения (time_correction, token) используются только внутри и никогда не передаются, поэтому злоумышленник не раскрывается и не происходит сбоя.
Единственный эффект заключается в том, что устаревший токен, соответствующий ctx.req_token, может применить мусорную корректировку time_correction к собственному смещению часов устройства (ctx.time_offset), незначительное влияние на целостность, ограниченное оценкой времени жертвы. Исправление добавляет явную проверку длины, которая удаляет слишком короткие AppTimeAns. Обратите внимание, что родственные однобайтовые чтения в обработчиках периодичности и принудительной повторной синхронизации остаются незащищенными с таким же незначительным воздействием.
Показать оригинальное описание (EN)
The LoRaWAN application-layer clock-synchronization service parses downlinks in clock_sync_package_callback() (subsys/lorawan/services/clock_sync.c). Its command loop only guarantees that the one-byte command id is in bounds; for the CLOCK_SYNC_CMD_APP_TIME (AppTimeAns) command the handler then reads a 4-byte time correction via sys_get_le32() plus a 1-byte token without checking that 5 bytes remain in the receive buffer (len - rx_pos). A short or crafted AppTimeAns therefore reads up to 5 bytes past the end of the decrypted payload. The payload (rx_buf/len) is the decrypted application frame delivered to the registered downlink callback (mcps_indication->Buffer/BufferSize). Reaching the handler requires a frame on the clock-sync port that passes LoRaWAN's MAC integrity check and FRMPayload decryption, so the practical attacker is a malicious or compromised network/application server (the designated sender of AppTimeAns) or a party holding the session keys, rather than an arbitrary radio listener. The over-read is bounded: the backing store is a fixed 255-byte static buffer, so the few stray bytes do not fault, and the read values (time_correction, token) are used only internally and never transmitted, so there is no disclosure to the attacker and no crash. The sole effect is that a stale token matching ctx.req_token can apply a garbage time_correction to the device's own clock offset (ctx.time_offset), a minor integrity impact confined to the victim's time estimate. The fix adds an explicit length check that drops a too-short AppTimeAns. Note the sibling one-byte reads in the periodicity and force-resync handlers remain unguarded with the same negligible impact.
Характеристики атаки
Последствия
Строка CVSS v3.1