Podatności Algernon

Algernon, mały samodzielny serwer WWW napisany w Go, przed wersją 1.17.9, na systemach Windows zawiera podatność polegającą na nieprawidłowym wyborze obsługi plików dla nazw równoważnych NTFS, takich jak x.lua::$DATA. Nieuwierzytelniony klient może uzyskać dostęp do surowego kodu źródłowego skryptów serwerowych, co może ujawnić dane uwierzytelniające bazy danych, klucze API i wartość SetCookieSecret.

Algernon przed wersją 1.17.7 ma podatność w funkcji DirPage, która przy żądaniu katalogu bez pliku indeksu przeszukuje katalogi nadrzędne (poza skonfigurowanym korzeniem serwera) w poszukiwaniu pliku handler.lua. Znaleziony plik jest wykonywany z pełnym dostępem do API Algernon, co pozwala na zdalne wykonanie kodu bez uwierzytelnienia.

Algernon przed wersją 1.17.8, gdy uruchomiony z opcją --domain (lub --letsencrypt), rozpoznaje katalog serwowany poprzez łączenie skonfigurowanego --dir z wartością nagłówka Host dostarczonego przez klienta bez walidacji, co umożliwia atakującym odczyt dowolnych plików, wyświetlenie listy katalogów i wykonanie kodu Lua po stronie serwera.

Algernon przed wersją 1.17.7 ma podatność w serwerze SSE, gdzie nagłówek Access-Control-Allow-Origin jest ustawiony na '*' niezależnie od pochodzenia żądania. Umożliwia to stronom trzecim odczyt strumienia nazw plików przez JavaScript.

Serwer WWW Algernon przed wersją 1.17.7 domyślnie wiązał serwer zdarzeń SSE z adresem 0.0.0.0:5553 na Linux/macOS, co umożliwiało dostęp z zewnątrz. Luka została naprawiona w wersji 1.17.7.

W Algernon przed 1.17.7, gdy uruchomiony jest z pojedynczym plikiem, tryb debugowania ujawnia pełną ścieżkę i zawartość pliku źródłowego w odpowiedzi na błąd. Każdy klient może wywołać błąd i uzyskać kod źródłowy.

Algernon przed wersją 1.17.6 zawiera podatność w funkcji uploadedFileSaveIn() w lua/upload/upload.go, która używa filepath.Join() z katalogiem dostarczonym przez wywołującego bez sprawdzania granic po połączeniu, umożliwiając zapis plików poza katalogiem głównym serwera.

Algernon, mały serwer WWW napisany w Go, w wersjach przed 1.17.6, ma podatność w engine/luahandler.go, gdzie sync.RWMutex chroniący LoadCommonFunctions jest zwalniany przed wykonaniem L.Push() i L.PCall(). Ponieważ LState gopher-lua nie jest bezpieczny dla współbieżności, współbieżne żądania powodują wyścig na współdzielonym stanie, prowadząc do uszkodzenia maszyny wirtualnej Lua.