To przepełnienie może zostać wykorzystane przez osoby zalogowane do systemu aby zatrzymać jego pracę lub do wykonania kodu z uprawnieniami jądra. Błąd znajduje się w bardzo wiekowej funkcji CreateDIBPalette() sterownika Win32k.sys. Funkcja używa jako licznika wartość biClrUsed z nagłówka informacyjnego BITMAPINFOHEADER podczas kopiowania danych ze schowka.
Błąd może być wywołany przez przekazanie w biClrUsed wartości większej niż 256.
Tavis Ormandy, który zgłosił trzy z tegorocznych błędów w jądrze systemu twierdzi, że nie było w tym roku więcej niż kilka dni gdy Mcrosoft nie był narażony na opublikowane i niezałatane błędy w jądrze.
Błędy w jądrze są trudniejsze do wykorzystania z uwagi na braki w dokumentacji. W dodatku z osób zajmujących się błędami przepełnienia bufora tylko mały ułamek zajmuje się jądrem systemu, a błędy często z braku umiejętności są traktowane jedynie jako DoS.
Błędów nie jest dużo mniej w jądrze jak w aplikacjach. Zarówno z uwagi na niedojrzałą optymalizacje, a znacznie częściej na kompatybilność – wiele błędów tkwi tam latami. Jak powyższy prawdopodobnie kilkunastoletni błąd.
Nie wiem czy powyższa podatność będzie użyta do wykonania kodu na nowszych systemach. Sterta kernela jest chroniona przez DEP (nx ,xd) i ASLR mimo tego, że kod kernela jest traktowany jako zaufany. Sterowniki w kernelu współdzielą ten sam obszar pamięci i jakiś trik może być możliwy 🙂
Nie będzie to proste. Wręcz “Na granicy niemożliwego” jak twierdzi autor publikacji i z tego powodu nie obawiał się upublicznić błędu. Ma jednak wątpliwości i jest ciekaw, czy komuś się to uda, biorąc pod uwagę, że w tym wypadku “dane” mają dodatkowe ograniczenia struktury.
[i]Więcej na:[/i]
http://www.ragestorm.net/blogs/
http://www.vupen.com/english/advisories/2010/2029
