51 lines
5.1 KiB
Markdown
51 lines
5.1 KiB
Markdown
**Модель:** Gemini 3 Pro
|
||
**Компания:** Google
|
||
**Дата:** 07.01.2026 14:50 UTC
|
||
|
||
---
|
||
|
||
# TIER 0: КРИТИЧЕСКИЕ
|
||
|
||
## 1. Eclipse Attack: Отравление AddrMan и отсутствие Anchor Connections
|
||
|
||
**Файлы:** `montana/src/net/addrman.rs`, `montana/src/net/connection.rs`, `montana/src/net/protocol.rs`
|
||
|
||
### Анализ кода
|
||
|
||
1. **Уязвимость вытеснения из Tried Table (`addrman.rs`):**
|
||
В методе `mark_good` (строка 181) при коллизии в таблице проверенных адресов (`tried_table`) вызывается `move_to_new` (строка 207).
|
||
```rust
|
||
// Handle collision
|
||
if let Some(existing_idx) = self.tried_table[idx] {
|
||
// Move existing back to new
|
||
self.move_to_new(existing_idx);
|
||
}
|
||
```
|
||
Это классическая уязвимость. Атакующий может намеренно создавать коллизии в бакетах (зная алгоритм SipHash и ключ или методом перебора), заставляя узел перемещать "хорошие" легитимные адреса обратно в таблицу `new_table`, где они могут быть удалены или затеряться среди адресов атакующего.
|
||
|
||
2. **Отсутствие Anchor Connections (`protocol.rs`, `connection.rs`):**
|
||
В `protocol.rs` (строки 206-207) явно указано:
|
||
```rust
|
||
// NOTE: Montana does NOT use anchor connections (see Network struct comment).
|
||
```
|
||
В Bitcoin Core файл `anchors.dat` сохраняет активные исходящие соединения при выключении и пробует подключиться к ним *первыми* при старте. В Montana этого нет. При рестарте узел полностью полагается на содержимое `addrman` (`addresses.dat`). Если `tried_table` была отравлена (см. п.1), узел подключится только к узлам атакующего.
|
||
|
||
3. **Слабая диверсификация исходящих (`protocol.rs`):**
|
||
Цикл `connection_loop` (строки 467-605) использует `addrman.select()` для выбора пиров. Хотя `addrman` пытается выбирать из разных бакетов, если *большинство* бакетов в `tried_table` контролируется атакующим (из-за уязвимости п.1), проверка `/16` netgroup не поможет, если атакующий имеет IP в разных подсетях (или использует ботнет).
|
||
|
||
### Эксплуатация (Chain of Exploitation)
|
||
|
||
1. **Заполнение (Filling):** Атакующий отправляет жертве тысячи `Addr` сообщений с подконтрольными IP-адресами, заполняя `new_table`.
|
||
2. **Продвижение (Promotion):** Атакующий устанавливает входящие соединения с жертвой с этих IP. Жертва, видя активность, может (в зависимости от логики) попытаться соединиться в ответ или просто обновить timestamp. При успешном исходящем соединении адрес попадает в `tried_table`.
|
||
3. **Вымывание (Eviction):** Атакующий продолжает добавлять новые "свои" адреса, вызывая коллизии в `tried_table`. Из-за логики `move_to_new`, старые честные пиры вылетают в `new_table`.
|
||
4. **Изоляция (Eclipse):** Атакующий ждет перезапуска узла жертвы (или провоцирует его DoS-атакой).
|
||
5. **Захват:** После рестарта жертва загружает `addresses.dat` (где `tried_table` отравлена) и не имеет `anchors.dat`. Все 8 исходящих соединений устанавливаются с узлами атакующего.
|
||
|
||
### Рекомендации по исправлению
|
||
|
||
1. **Исправить коллизии в Tried:** Вместо `move_to_new`, тестировать новый адрес. Если он работает, а старый нет — заменять. Если оба работают — оставлять старый (принцип "первый пришел — занял место").
|
||
2. **Внедрить Anchors:** Создать `anchors.dat`, сохраняющий 2-4 проверенных пира при выключении. При старте пробовать их в первую очередь.
|
||
3. **Outbound Eviction:** Внедрить защиту от Eclipse для исходящих соединений (мониторинг качества цепи, сравнение заголовков с другими пирами, Feeler connections для проверки новых адресов).
|
||
|
||
|