闪电网络安全缝隙技能细节及发现进程

以下是技能细节内容:

承受通道的闪电网络节点有必要检查funding买卖输出是否的确翻开了提议的通道,不然进犯者可宣称翻开一个通道,然后要么不向对等节点(peer)付出,要么不进行全额付出。

一旦买卖到达最小深度,其就可从通道中支出资金。只有当受害者妄图封闭通道,以及其具有的任何许诺或彼此成交买卖都无效时,他们才会注意到这种歹意行为。

而闪电网络客户端并不必定会履行这种检查操作:

c-lightning: v0.7.1以及更高版别的客户端正确地做到了这一点,而曾经版别的c-lightning客户端却没法办到。(CVE-2019-12998)

衔接对等节点,并用任何买卖id宣称翻开一个通道,就可运用这种缝隙。

lnd: v0.7.1及更高版别的客户端处理了这个问题,但曾经版别的lnd没有检查数量。v0.7.0及更高版别客户端正确检查了scriptpubkey,v0.6.x版别客户端部分强制履行赞助ScriptPubkey,但v0.6.0之前版别的客户端则彻底没有进行相关验证。(CVE-2019-12999)

对一切曾经版别的lnd客户端,进犯者都或许通过不正确的数量进行进犯。在v0.7.0版别,进犯者有必要运用正确的scriptpubkey,这会烧掉funding输出中的币。 而关于v0.6.0版别之前的客户端,进犯者通过不正确的scriptpubkey都可完结进犯。在v0.6.x客户端中,假如在funding买卖到达所需的承认数,在恣意一个全节点后端上运转txindex=0,且节点处于离线(offline)状况时,此缝隙也或许会被运用。 运用过错outpoint进犯neutrino客户端(一般是移动端或笔记本电脑)用户,需进犯者将其假outpoint与BIP 158 挑选程序中的实在outpoint脚本磕碰。用于创立挑选程序的siphash密钥是从blockhash派生而来的。因而,进犯者在不提早知道区块哈希的情况下,是无法直接进行进犯的。此外, neutrino客户端节点一般不会监听或不具备布告地址,这意味着进犯者有必要等至接收到入站衔接后才干履行进犯。

eclair: v0.3.1及以上版别的客户端正确处理了安全隐患,假如用户运用了bitcoin core作为后端,则曾经版别的eclair客户端就会有安全隐患。而electrum用户只检查脚本,而不会检查数量。(CVE-2019-13000)

进犯Electrum客户端用户(移动端),则要求用户自动衔接到歹意闪电网络节点,而且进犯者运用正确的scriptpubkey,这会烧掉 funding输出中的币。由于Eclair移动端客户端不会中继付出,进犯者在没有带外(offband)交互(例如,向用户出售某物,并运用假通道中的资金进行付出)的情况下,是无法进行提款操作的。

 处理计划

 一旦观察到funding买卖,对等节点(peer)有必要检查`funding_created`[1] 中所述的outpoint是否为`open_channel`[3]中描绘金额的funding买卖输出[2] 。

 布景

 要翻开一个闪电网络通道,funding对等节点发送带有提议`funding_satoshis`(金额)的`open_channel`。被赞助者则用 `accept_channel`回复,供给其期望用于这笔funding买卖的密钥。

然后出资人创立这笔funding买卖,并发送买卖id以及`funding_created`音讯中的输出编号。

闪电网络安全缝隙技能细节及发现进程

其间节点A是“出资人”,节点B是“被赞助者”

有了这些信息,“被赞助者”可在第一笔“许诺买卖”上创立签名,并将其发送到一则`funding_signed`音讯中,以便在呈现问题时,赞助者可取回他们的资金。这样,出资人就可以安全地签署并播送这笔opening买卖。通过必定数量的承认(由“被赞助者”设定)后,通道就开端运作(`funding_locked`)了。

规范清楚地描绘了检查所交流的各种签名,是否的确答应创立有用许诺买卖[4]的要求,并描绘了等候承认的要求[5]。

可是,它并不要求接收者实践检查买卖是否是出资人许诺的买卖:包含金额和实践的scriptpubkey。

 缝隙发现进程

 Rusty Russell (Blockstream)在为规范自身进行协议测验(增加了多个新的提议功用[6])时发现了这一缝隙。

在编写测验时,通道敞开者(opener)在`funding_created`音讯中供给了不正确的`funding_output_index`,Russell意识到C-Lightning客户端不会回绝它,由于C-Lightning只检查`funding_txid`的承认计数,甚至连`funding_output_index`是否存在都不会进行检查!

而这个要求在规范中是没有被说到的,因而Rusty当即向其它被广泛运用的客户端(eclair 和 lnd)的作者提醒了这一问题。通过查询后,他们发现的确是存在这样的问题。

所以,几个团队一同做出决议,先在新版别客户端中悄悄地处理这些问题,然后再通过8周(大大都用户完结晋级后),就可提醒问题自身,接着再过四周后,他们就全面发表缝隙。

值得幸亏的是,这一长期存在的缝隙并没有被广泛运用,其的确供给了一个测验整个闪电网络生态系统通讯和晋级办法的时机。

 缝隙时间表

 2019-06-27: Rusty Russell发现缝隙,并告诉LND和Eclair客户端作者;

2019-06-28: CVE缝隙编号被分配结束;

2019-07-02: lnd v0.7.0-beta客户端发布;

2019-07-03: Eclair 0.3.1客户端发布;

2019-07-04: c-lightning 0.7.1 客户端发布;

2019-07-06: Rusty Russell等人开端向其他客户端(rust-lightning, ptarmigan, BLW)作者发表缝隙;

2019-07-30: lnd v0.7.1-beta 客户端发布;

2019-08-17: [依据布置状况/问题检查下一个日期];

2019-08-30: 对外发表CVE缝隙存在,劝说运用旧版别客户端的用户进行晋级;

2019-09-07: 初次发现有人妄图运用这种缝隙;

2019-09-27: 全面发表CVE缝隙细节;

2019-09-27: 依据规范要求提交PR;