QUIC sniffer: Fix potential slice panic #3406
Conversation
Vigilans
left a comment
Vigilans
left a comment
There was a problem hiding this comment.
前面的协议校验都过了，这两个都来自header的字段出了问题，确实很神奇
我又发现了一个潜在的崩溃位置 如果假header后面的数据太短了会导致 b[hdrLen+4:hdrLen+4+16] 再次超限(见我加的新test) |
| hdrLen := len(b) - int(buffer.Len()) | ||
| if len(b) < hdrLen+int(packetLen) { | ||
| if len(b) < hdrLen+int(packetLen) || len(b) < hdrLen+20{ | ||
| return nil, common.ErrNoClue // Not enough data to read as a QUIC packet. QUIC is UDP-based, so this is unlikely to happen. |
There was a problem hiding this comment.
翻了一下协议好像没找到下面20(4+16)长度的准确解释，貌似是关于Packet Number Decoding的？
这一行可以付上 // See https://github.com/v2fly/v2ray-core/pull/3406#issuecomment-2866415064，方便查阅这个Magic Number的解释。
There was a problem hiding this comment.
翻了一下协议好像没找到下面20(4+16)长度的准确解释，貌似是关于Packet Number Decoding的？
这一行可以付上
// See https://github.com/v2fly/v2ray-core/pull/3406#issuecomment-2866415064，方便查阅这个Magic Number的解释。
如果地方多的话 感觉可能不如以前的xray偷懒做法 直接recover切片类panic当read错误返回notquic就行了
There was a problem hiding this comment.
这两个用例都是少了 115 行 packetLen < 4（即 origPNBytes 的长度）的判断，关于 packetNumberLength 应该另外处理（如 #3389）
|
This pull request is ready to be merged. Thanks! |
Disable QUIC sniff until next-server is switched to v2ray-core. Fixed in v2fly/v2ray-core#3406.
4 participants
From XTLS/Xray-core#3914
概述：
一些奇怪的数据包 读出的 packet number length 有可能会大于 length 本身 导致切片读取错误(b[17:15]这样) 样例数据在原issue有 可自行验证 想了一下比较简单的粗暴的方法大概就是检验后直接返回错误
先发到这里的原因是Xray的是从fly这copy的(其实这个错误从最开始的旧QUIC嗅探嗅探器就存在的样子)
CC: @Vigilans