Podatności Dompdf

W Dompdf w wersjach 3.15 i wcześniejszych, jeśli atakujący może dostarczyć nieograniczoną treść do renderowania, może wykorzystać funkcję renderowania SVG do wycieku informacji o systemie plików. Używając elementu <image> w osadzonym SVG z data-URI, atakujący może próbować osadzić inne pliki. Różnica w zachowaniu przy dostępie do istniejących i nieistniejących plików umożliwia wyciek. Problem rozwiązano w wersji 3.16.

W Dompdf w wersjach 3.15 i wcześniejszych istnieje podatność na atak DoS przez wyczerpanie zasobów. Atakujący może przesłać specjalnie spreparowany dokument HTML z pojedynczym obrazem o ogromnych wymiarach (np. 30 000x30 000 pikseli), co powoduje alokację dużych ilości pamięci i czasu CPU. Problem rozwiązano w wersji 3.16.

W Dompdf w wersjach 3.15 i wcześniejszych, akceptowany jest obraz BMP, a następnie generowany jest kompatybilny z PDF PNG tylko na podstawie zadeklarowanych wymiarów w nagłówku, bez ograniczenia szerokości × wysokości przed konwersją przez GD. Mały plik BMP (58 bajtów) z nagłówkiem deklarującym np. 6000×6000 powoduje alokację pełnej płótna pikseli, prowadząc do znacznego wzrostu zużycia pamięci (nawet 12-krotnego). Problem rozwiązano w wersji 3.16.

Dompdf w wersjach 3.15 i wcześniejszych pozwala atakującemu kontrolującemu wejście HTML na ominięcie ograniczeń poprzez osadzenie ścieżki pliku w obrazie SVG dostarczonym przez URI data:. Podczas przetwarzania SVG drugi przebieg nie egzekwuje tych samych zabezpieczeń co pierwszy, co prowadzi do odczytu dowolnych plików obrazów z systemu plików serwera.

Dompdf w wersjach 3.15 i wcześniejszych jest podatny na atak typu File Existence Oracle przez manipulację dyrektywą CSS @font-face. Atakujący może wykorzystać różnicę w zachowaniu przy odwołaniach do istniejących i nieistniejących plików lokalnych (przez protokół file://) jako wyrocznię do enumeracji plików na serwerze, nawet przy ograniczeniach CHROOT. Problem został naprawiony w wersji 3.16.

W Dompdf w wersjach 3.15 i wcześniejszych metoda validateLocalUri() sprawdza ograniczenia CHROOT przez porównanie prefiksu po normalizacji ścieżki. Ponieważ normalizacja usuwa końcowy separator katalogu, sprawdzenie może zostać obejście, np. katalog /var/www pasuje również do /var/www2. Atakujący kontrolujący część renderowanego HTML może odczytać pliki poza dozwolonym katalogiem. Problem został naprawiony w wersji 3.16.