155 lines
11 KiB
Markdown
155 lines
11 KiB
Markdown
# Security Audit: Lottery Grinding & Bootstrap DoS
|
||
|
||
**Модель:** Gemini 3 Pro
|
||
**Компания:** Google
|
||
**Дата:** 08.01.2026 16:30 UTC
|
||
|
||
---
|
||
|
||
## 1. Понимание архитектуры
|
||
|
||
Montana ACP (Atemporal Coordinate Presence) — это сеть, где консенсус достигается не через PoW/PoS, а через "накопление присутствия" (время). Узлы подписывают временные слоты (таймслайсы), доказывая своё существование. Победитель раунда (каждые 10 минут, τ₂) выбирается через детерминированную лотерею.
|
||
|
||
Ключевые механизмы защиты:
|
||
1. **Детерминированная лотерея**: Должна зависеть только от *предыдущего* состояния сети (хеш прошлого слайса), чтобы исключить манипуляции (grinding) в текущем раунде.
|
||
2. **Adaptive Cooldown**: Защита от Sybil через временнУю стоимость входа (1-180 дней).
|
||
3. **Adaptive Subnet Limiter**: Защита от сетевых атак (Erebus/DoS) через двухуровневые лимиты подсетей.
|
||
|
||
Я изучил архитектуру и обнаружил критическую уязвимость в реализации консенсуса.
|
||
|
||
---
|
||
|
||
## 2. Изученные файлы
|
||
|
||
| Файл | LOC | Ключевые компоненты |
|
||
|------|-----|---------------------|
|
||
| `montana/src/consensus.rs` | 271 | Логика лотереи, расчет seed, проверка победителя |
|
||
| `montana/src/net/rate_limit.rs` | 1183 | Реализация лимитеров, AdaptiveSubnetLimiter |
|
||
| `montana/src/net/protocol.rs` | 1653 | Основной сетевой протокол, обработка сообщений |
|
||
| `montana/src/net/bootstrap.rs` | 1254 | Логика начальной загрузки и верификации |
|
||
| `montana/src/cooldown.rs` | 262 | Реализация адаптивного кулдауна |
|
||
|
||
---
|
||
|
||
## 3. Attack Surface
|
||
|
||
Я определил следующие векторы атак:
|
||
1. **Манипуляция лотереей (Grinding)**: Возможность влиять на выбор победителя через изменение содержимого блока.
|
||
2. **Блокировка запуска (Bootstrap DoS)**: Манипуляция медианой сети для принудительного отказа в обслуживании новым узлам.
|
||
|
||
---
|
||
|
||
## 4. Найденные уязвимости
|
||
|
||
### [CRITICAL] Lottery Grinding (Манипуляция лотереей)
|
||
|
||
**Файл:** `montana/src/consensus.rs:23`
|
||
|
||
**Уязвимый код:**
|
||
```rust
|
||
pub fn compute_lottery_seed(prev_hash: &Hash, tau2_index: u64, presence_root: &Hash) -> Hash {
|
||
let mut data = Vec::with_capacity(72);
|
||
data.extend_from_slice(prev_hash);
|
||
data.extend_from_slice(&tau2_index.to_le_bytes());
|
||
data.extend_from_slice(presence_root); // <--- КРИТИЧЕСКАЯ ОШИБКА
|
||
sha3(&data)
|
||
}
|
||
```
|
||
|
||
**Описание:**
|
||
В документации (`layer_1.md`) явно указано, что `seed = SHA3-256(prev_slice_hash ‖ τ₂_index)`. Это гарантирует, что победитель определен *до* формирования блока.
|
||
Однако в коде в расчет `seed` включен `presence_root` *текущего* блока.
|
||
Поскольку `presence_root` зависит от набора подписей, включенных в блок, а блок формирует сам победитель, это создает циклическую зависимость, которую атакующий может эксплуатировать.
|
||
|
||
**Вектор атаки:**
|
||
1. Атакующий (даже с минимальным весом) собирает подписи присутствия (presence signatures) от других узлов.
|
||
2. Вместо публикации всех подписей, атакующий перебирает различные подмножества подписей.
|
||
3. Для каждого подмножества вычисляется новый `presence_root`.
|
||
4. Новый `presence_root` дает новый `seed` лотереи.
|
||
5. Новый `seed` меняет победителя (функция `find_winner`).
|
||
6. Атакующий повторяет перебор (Grinding), пока не найдет такой `presence_root`, при котором `seed` делает **его** победителем.
|
||
7. Атакующий публикует валидный блок, где он — законный победитель.
|
||
|
||
**Импакт:**
|
||
Атакующий с минимальным весом может выигрывать лотерею практически в каждом раунде, просто перебирая комбинации подписей. Это полностью ломает модель консенсуса, основанную на времени/весе, и превращает её в PoW-гонку (где "работа" — это хеширование комбинаций подписей). Захват сети возможен с одним слабым узлом.
|
||
|
||
**Сложность:** Низкая. Требуется только CPU для хеширования.
|
||
|
||
**PoC сценарий:**
|
||
```rust
|
||
// Псевдокод атаки
|
||
let signatures = collect_mempool_signatures();
|
||
let my_pubkey = my_keypair.public;
|
||
|
||
for subset in signatures.powerset() {
|
||
let root = compute_merkle_root(subset);
|
||
let seed = compute_lottery_seed(prev_hash, index, root);
|
||
let (winner, _) = find_winner(seed, all_participants);
|
||
|
||
if winner == my_pubkey {
|
||
publish_block(subset); // PROFIT!
|
||
break;
|
||
}
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
### [MEDIUM] Bootstrap DoS via Consensus Manipulation
|
||
|
||
**Файл:** `montana/src/net/bootstrap.rs:326` (verify_hardcoded_consensus)
|
||
|
||
**Описание:**
|
||
При запуске узел опрашивает 100 пиров (из которых ~20 hardcoded). Он вычисляет медиану высоты цепи по всем ответам. Затем он требует, чтобы *каждый* hardcoded узел соответствовал этой медиане (с допуском 1%). Если hardcoded узлы отклоняются (потому что медиана смещена атакой), загрузка прерывается с ошибкой CRITICAL.
|
||
|
||
**Вектор атаки:**
|
||
Атакующий окружает новый узел своими пирами (Eclipse) и сообщает ложную высоту (например, сильно большую или малую). Медиана по всем 100 пирам смещается в сторону атакующего. Честные hardcoded узлы (которые сообщают реальную высоту) оказываются "несогласными" с медианой. Узел считает, что hardcoded узлы скомпрометированы, и аварийно останавливается.
|
||
|
||
**Импакт:**
|
||
Полный отказ в обслуживании (DoS) для новых узлов. Они не могут присоединиться к сети.
|
||
|
||
**Сложность:** Средняя (требуется контроль входящих соединений жертвы).
|
||
|
||
---
|
||
|
||
## 5. Атаки, которые НЕ работают
|
||
|
||
1. **Erebus / Subnet Flood**: Код `GlobalSubnetLimiter` в `rate_limit.rs` корректно реализует двухуровневую защиту (Fast/Slow tiers) и правильно интегрирован в `protocol.rs` (вызовы `subnet_limiter.check()`). Это защищает от атак с использованием множества IP из одной подсети.
|
||
2. **Sybil (регистрация)**: `AdaptiveCooldown` реализован корректно в `cooldown.rs`. Спам регистрациями действительно приведет к увеличению кулдауна до 180 дней.
|
||
3. **Fake Hardcoded Nodes**: `HardcodedNode` аутентификация через ML-DSA-65 реализована и работает. Подделать hardcoded узел без приватного ключа нельзя.
|
||
4. **Inventory Exhaustion**: `BoundedInvSet` использует FIFO удаление старых элементов, что защищает память даже при флуде уникальными инвентарными хешами.
|
||
|
||
---
|
||
|
||
## 6. Рекомендации
|
||
|
||
1. **Исправить Lottery Grinding (СРОЧНО)**:
|
||
Исключить `presence_root` из расчета `seed` в `consensus.rs`. Seed должен зависеть *только* от `prev_hash` и `index`.
|
||
```rust
|
||
// Было:
|
||
// data.extend_from_slice(presence_root);
|
||
// Стало:
|
||
// (удалить эту строку)
|
||
```
|
||
Это сделает лотерею честной: победитель определяется до того, как он сможет манипулировать содержимым блока.
|
||
|
||
2. **Улучшить логику Bootstrap**:
|
||
Вместо аварийной остановки при несогласии hardcoded узлов с медианой сети, следует использовать "Trusted Core" подход:
|
||
1. Собрать ответы от всех hardcoded узлов.
|
||
2. Вычислить медиану ТОЛЬКО среди hardcoded узлов (`hardcoded_median`).
|
||
3. Проверить консенсус внутри hardcoded группы (сколько узлов в пределах ±1% от `hardcoded_median`).
|
||
4. Если большинство (>50%) hardcoded узлов согласны → считать `hardcoded_median` истинной.
|
||
5. P2P узлы проверять относительно этой доверенной медианы (warning при расхождении, но не блокировка).
|
||
6. Hardcoded узлы, которые не согласны с `hardcoded_median` (меньшинство), игнорируются, но не вызывают падения.
|
||
Это сделает bootstrap устойчивым к Eclipse-атакам, так как атакующий не может подделать подписи hardcoded узлов.
|
||
|
||
---
|
||
|
||
## 7. Вердикт
|
||
|
||
[x] CRITICAL — есть уязвимости, позволяющие уничтожить сеть (Lottery Grinding позволяет захватить контроль над блокчейном).
|
||
[ ] HIGH
|
||
[ ] MEDIUM
|
||
[ ] LOW
|
||
[ ] SECURE
|