Podatności Headroom

W wersjach Headroom przed 0.35.0 serwer WebSocket nie weryfikuje nagłówka `Origin` przychodzących żądań przed przekazaniem ich do serwera nadrzędnego, co pozwala złośliwym klientom WebSocket na wykonywanie dowolnych żądań do LLM bez uwierzytelnienia. Podatność może zostać wykorzystana przez złośliwego klienta WebSocket działającego w przeglądarce, jeśli ma ona dostęp do proxy Headroom, a klucz OpenAI API jest przechowywany w zmiennej środowiskowej `OPENAI_API_KEY`. Wersja 0.35.0 naprawia ten problem.

Proxy LLM Headroom wywodzi właściciela pamięci z nagłówka żądania x-headroom-user-id. Nagłówek jest odczytywany bezpośrednio w kilku miejscach, a nic nie wiąże wartości z wywołującym. Klient może podać identyfikator innego użytkownika i odczytać lub zapisać jego pamięć LLM. Poprawka wprowadza pojedynczy punkt resolve_memory_identity, który honoruje nagłówek tylko dla wywołań z loopback lub z listy dozwolonych, a w przeciwnym razie wiąże tożsamość z odciskiem tokena proxy lub użytkownikiem systemu operacyjnego. Domyślna konfiguracja pip wiąże 127.0.0.1, ale referencyjny docker-compose.yml udostępnia porty bez wymaganego tokena, co naraża trasy danych na sieć bez uwierzytelnienia.

Proxy LLM Headroom pozwala klientowi wybrać docelowy serwer za pomocą nagłówka x-headroom-base-url. Brakuje sprawdzenia, czy cel nie jest adresem pętli zwrotnej, link-local lub RFC 1918, co umożliwia dostęp do wewnętrznych usług i adresów metadanych chmury. Dodatkowo, nagłówek Authorization jest przekazywany do wskazanego hosta. Domyślna konfiguracja docker-compose.yml wystawia porty bez wymaganego tokena, co zwiększa ryzyko.