182 lines
7.7 KiB
Markdown
182 lines
7.7 KiB
Markdown
# АНАЛИЗ УЯЗВИМОСТЕЙ СЕТИ MONTANA
|
||
|
||
**Модель:** Grok 3
|
||
**Компания:** xAI
|
||
**Дата:** 07.01.2026 15:00 UTC
|
||
|
||
## ВВЕДЕНИЕ
|
||
|
||
Проведен анализ сетевого слоя Montana на предмет уязвимостей согласно векторам атаки, определенным в PROMPT_COUNSIL_TEMPLATE.md. Анализ включает проверку кода, выявление слабых мест и описание методов эксплуатации для каждого вектора.
|
||
|
||
## TIER 0: КРИТИЧЕСКИЕ УЯЗВИМОСТИ
|
||
|
||
### 1. ECLIPSE ATTACK
|
||
**Статус:** ⚠️ ПОТЕНЦИАЛЬНО ВОЗМОЖЕН
|
||
|
||
**Файлы:** `addrman.rs`, `eviction.rs`, `connection.rs`
|
||
|
||
**Анализ кода:**
|
||
- NEW table: 1024 buckets × 64 slots = 65,536 адресов
|
||
- TRIED table: 256 buckets × 64 slots = 16,384 адресов
|
||
- Bucket assignment использует криптографический хэш с ключом (32 байта)
|
||
- MAX_PEERS_PER_NETGROUP = 2 (очень низкий лимит)
|
||
|
||
**Слабые места:**
|
||
1. **Отсутствие anchor connections**: Нет механизма сохранения "якорных" соединений между рестартами
|
||
2. **Коллизии в TRIED table**: При mark_good() старый адрес перемещается обратно в NEW table (строка 204-207 в addrman.rs)
|
||
3. **Netgroup diversity**: MAX_PEERS_PER_NETGROUP=2 обеспечивает защиту, но может быть недостаточно
|
||
|
||
**Эксплуатация:**
|
||
```
|
||
1. Заполнить NEW table вредоносными адресами:
|
||
- Создать 65k+ фейковых адресов в разных /16 подсетях
|
||
- Использовать AddrMan bucket collision для контроля распределения
|
||
|
||
2. Продвинуть адреса в TRIED table:
|
||
- Подключиться к жертве с 8 outbound соединениями
|
||
- Убедиться что все 8 соединений ведут к атакующим адресам
|
||
- Использовать eviction для вытеснения легитимных соединений
|
||
|
||
3. Ждать рестарта жертвы:
|
||
- После рестарта все outbound соединения пойдут к атакующему
|
||
- Жертва изолирована в контролируемой сети атакующего
|
||
```
|
||
|
||
**Защита:** Добавить anchor connections (сохранять 2-3 надежных outbound соединений между рестартами)
|
||
|
||
---
|
||
|
||
### 2. MEMORY EXHAUSTION
|
||
**Статус:** ✅ ЗАЩИЩЕН
|
||
|
||
**Файлы:** `protocol.rs`, `sync.rs`
|
||
|
||
**Анализ кода:**
|
||
- Early size check: MAX_SLICE_SIZE = 4MB перед аллокацией (строка 1117 в protocol.rs)
|
||
- Orphan pool: MAX_ORPHANS = 100 (ограничен)
|
||
- Flow control: проверяется ПЕРЕД read_message() (строки 647-658)
|
||
|
||
**Слабые места:** НЕ НАЙДЕНЫ
|
||
|
||
**Проверка чеклиста:**
|
||
- ✅ Flow control проверяется ПЕРЕД read_message()
|
||
- ✅ Orphan pool bounded (MAX_ORPHANS = 100)
|
||
- ✅ Все collections имеют limits (векторы, хэшмапы ограничены константами)
|
||
|
||
---
|
||
|
||
## TIER 1: ВЫСОКИЕ УЯЗВИМОСТИ
|
||
|
||
### 3. CONNECTION SLOT EXHAUSTION
|
||
**Статус:** ⚠️ СРЕДНИЙ РИСК
|
||
|
||
**Файлы:** `connection.rs`, `eviction.rs`
|
||
|
||
**Анализ кода:**
|
||
- MAX_INBOUND = 117
|
||
- MAX_OUTBOUND = 8
|
||
- Eviction: 6-слойная защита (Noban, Netgroup, Ping, Tx, Slice, Longevity)
|
||
|
||
**Слабые места:**
|
||
1. **Gaming eviction**: Атакующий может имитировать низкую latency, relay activity
|
||
2. **Нет rate limit на новые соединения**: Только проверка can_accept_inbound()
|
||
|
||
**Эксплуатация:**
|
||
```
|
||
1. Занять все 117 inbound slots:
|
||
- Создать 117+ одновременных подключений от разных IP
|
||
- Использовать разные /16 подсети (MAX_PEERS_PER_NETGROUP=2)
|
||
- Имитрировать полезную активность (relay tx/slice)
|
||
|
||
2. Обойти eviction:
|
||
- Поддерживать низкую ping latency (<50ms)
|
||
- Регулярно relay транзакции (update last_tx_time)
|
||
- Иметь длинную историю подключения (старые timestamps)
|
||
```
|
||
|
||
---
|
||
|
||
### 4. SYNC DOS
|
||
**Статус:** ⚠️ ВЫСОКИЙ РИСК
|
||
|
||
**Файлы:** `sync.rs`, `bootstrap.rs`
|
||
|
||
**Анализ кода:**
|
||
- MAX_PARALLEL_DOWNLOADS = 32
|
||
- DOWNLOAD_TIMEOUT_SECS = 120
|
||
- Headers: НЕТ rate limiting
|
||
- GetSlices: НЕТ rate limiting
|
||
|
||
**Слабые места:**
|
||
1. **Headers flooding**: Нет лимита на headers сообщения
|
||
2. **GetSlices amplification**: Нет rate limiting на GetSlices запросы
|
||
3. **Bootstrap verification**: Требует 100 peer responses, может быть DoS-нут
|
||
|
||
**Эксплуатация:**
|
||
```
|
||
Headers flooding (CPU exhaustion):
|
||
1. Подключиться к жертве с inbound соединением
|
||
2. Отправлять непрерывный поток headers сообщений
|
||
3. Каждое headers сообщение требует CPU для проверки
|
||
|
||
GetSlices amplification (bandwidth):
|
||
1. Отправлять GetSlices(start=0, count=500) запросы
|
||
2. Каждый запрос требует отправки 500 × 4MB = 2GB данных
|
||
3. Нет rate limiting на такие запросы
|
||
```
|
||
|
||
**Проверка чеклиста:**
|
||
- ❌ Headers rate limiting отсутствует
|
||
- ❌ GetSlices rate limiting отсутствует
|
||
|
||
---
|
||
|
||
### 5. RATE LIMIT BYPASS
|
||
**Статус:** ⚠️ СРЕДНИЙ РИСК
|
||
|
||
**Файлы:** `rate_limit.rs`
|
||
|
||
**Анализ кода:**
|
||
- Addr: 1000 burst, 0.1/sec sustained
|
||
- Inv: 5000 burst, 10/sec sustained
|
||
- GetData: 1000 burst, 5/sec sustained
|
||
- Rate limits per-peer, НЕ per-IP
|
||
|
||
**Слабые места:**
|
||
1. **Per-connection limits**: Атакующий может открыть multiple соединения
|
||
2. **Token bucket refill timing**: Можно синхронизировать атаки
|
||
|
||
**Эксплуатация:**
|
||
```
|
||
Multiple connections от одного IP:
|
||
1. Открыть 10+ inbound соединений с одного IP
|
||
2. Каждый peer имеет собственные rate limits
|
||
3. Общий rate = 10 × individual_limit
|
||
|
||
Token bucket timing:
|
||
1. Потратить все tokens в burst
|
||
2. Подождать refill (1 секунда для addr)
|
||
3. Повторить атаку синхронно со всех соединений
|
||
```
|
||
|
||
**Проверка чеклиста:**
|
||
- ❌ Rate limit per-connection вместо per-IP
|
||
- ✅ Все message types covered
|
||
|
||
---
|
||
|
||
## РЕЗЮМЕ АНАЛИЗА
|
||
|
||
### Критические проблемы:
|
||
1. **Eclipse Attack** - Возможен при отсутствии anchor connections
|
||
2. **Sync DoS** - Headers и GetSlices не имеют rate limiting
|
||
|
||
### Рекомендации по исправлению:
|
||
1. Добавить anchor connections для защиты от Eclipse
|
||
2. Внедрить rate limiting для headers и GetSlices сообщений
|
||
3. Рассмотреть per-IP rate limiting вместо per-connection
|
||
4. Увеличить MAX_PEERS_PER_NETGROUP до 3-4 для лучшей diversity
|
||
|
||
### Общая оценка безопасности:
|
||
Сетевой слой Montana имеет хорошую базовую защиту, но требует доработок в области Eclipse resistance и rate limiting для достижения production-ready состояния.
|