Maksymalna długość ścieżki pod Windows’em


Być może jesteś jedną z osób, która do tego momentu wierzyła, że maksymalna długością ścieżki, jaką może ona osiągnąć pod Windows’em jest określona przez MAX_PATH ( 256 znaków ). NIC BARDZIEJ MYLNEGO!!!!
W dokumencie, który możecie pobrać poniżej opisałem m.in:

– jaka jest maksymalna długość ścieżki i z czego to wynika
– w jaki sposób uzyskać możliwość tworzenia ścieżek dłuższych niż MAX_PATH
– detale prezentujące konkretne api, w których odbywa się sprawdzanie długości ścieżki, jej typy, itp.

te i wiele innych kwestii.
Oczywiście, jeżeli jakiś programista założył, że maksymalną długością ścieżki jest MAX_PATH, to w najlepszym wypadku jego aplikacja będzie nie w pełni funkcjonalna, a w najgorszym można spodziewać się takich błędów jak buffer overflow. Aby przekonać się o słuszności swojej teorii postanowiłem przetestować „tolerancje” aplikacji anty-wirusowych na długie ścieżki. Rezultaty tych testów możecie obejrzeć w dokumencie, tutaj powiem tylko, że spora grupa wykazała oba powyżej opisane objawy.
A teraz czas na małą i IMO zachęcającą do wzięcia tematu długich ścieżek na poważnie galerię:

AVAST 5.0.594.0


AVIRA 10.0.0.567


Norton 17.6.0.32


Sophos 9.5.1

I na koniec najnowsza wersja gmer’a na dzień 15.10.2010 GMER 1.0.15.15315 ( ostatni bug raportowany przezemnie został załatany, jednak jak widać nie do końca 😉 )

Dokument w wersji angielskiej można pobrać stąd: Windows LongPaths – extended-length paths
Maybe you are one of persons who belived for this moment that maximal length of path in Windows is equal to MAX_PATH ( 260 signs). Nothing further from the truth !!!.
In document which you can download below I have described inter alia:

– what is the maximum path length and from which it follows
– in how achieve possibility to create paths longer than MAX_PATH
– details related with WinApi, where path length and it’s type is tested.

this and more issues.
Of course, if some programmer assumed that maximal path length is 260 signs, his application in the best scenario won’t be fully functional in but in the worst scenario we can expect bugs that kind like buffer overflow.
To convince myself to validity of this theory, I decided to test anti-virus applications “tolerance” on such paths. Results of those tests you can review in a mentioned document, here I can only say that quite a lot of anti-virus showed described above signs.
And now, it’s time for a little gallery which IMO encourage you to treatment existence of long paths like a real problem:
AVAST 5.0.594.0


AVIRA 10.0.0.567


Norton 17.6.0.32


Sophos 9.5.1

At the end the newest version of gmer on day 15.10.2010 GMER 1.0.15.15315 ( the last bug reported by me has been patched, but like we can see there is still more problems in this area 😉 ).

The document can be downloaded from here: Windows LongPaths – extended-length paths
Greetz to Emiliano Martinez Contreras for a translation from IceEng to more readable form ;).

This entry was posted in Analiza, Bez kategorii, RE, Security and tagged , , , , , , , . Bookmark the permalink.

14 Responses to Maksymalna długość ścieżki pod Windows’em

  1. ged_ says:

    nice find 🙂

  2. Pingback: Tweets that mention Icewall's blog » Extended length paths in Windows -- Topsy.com

  3. Icewall says:

    @ged_ and @Prakhar Prasad
    Thx guys 😉

  4. G says:

    to jeszcze noda

  5. omeg says:

    Jakieś 2 lata temu zajmowałem się podobnymi testami w jednej z dużych firm AV. 😉
    Jak widać, nie przejęli się chyba za bardzo rezultatami. Jako bonus polecam też długie ścieżki z losowymi znakami Unicode i/lub na dyskach sieciowych (choć z tym ostatnim ostrożnie, soft do backupów zazwyczaj się krzaczy i admin może przybiec z krzykiem, ponadto nie zawsze da się to potem prosto usunąć 😉
    PS. Wypadałoby wspomnieć, że na systemie plików FAT oczywiście to nie zadziała. (A co jeśli spróbujemy skopiować NTFS->FAT? 😉

    • Icewall says:

      @omeg

      Jakieś 2 lata temu zajmowałem się podobnymi testami w jednej z dużych firm AV.

      Nice ;). U mnie ten temat tez juz ponad rok w szufladzie lezal.

      Jak widać, nie przejęli się chyba za bardzo rezultatami. Jako bonus polecam też długie ścieżki z losowymi znakami Unicode i/lub na dyskach sieciowych (choć z tym ostatnim ostrożnie, soft do backupów zazwyczaj się krzaczy i admin może przybiec z krzykiem, ponadto nie zawsze da się to potem prosto usunąć

      Tak tak, tutaj modyfikacji i wektorów do ataku jest jeszcze sporo. Ja w papierze staralem sie poprostu przedstawic temat.
      Kiedy rozmawialismy o tym temacie w firmie np.Gynavel zaproponowal przetestowanie jeszcze:

      – virtual machines and their directory sharing functionality
      – sandboxes that sandbox the file system
      – hmm, maybe placing the symbol name or DLL name in a PE file and test
      some PE viewers?

      Wracajac do dalszej twojej wypowiedzi:

      PS. Wypadałoby wspomnieć, że na systemie plików FAT oczywiście to nie zadziała. (A co jeśli spróbujemy skopiować NTFS->FAT?

      FAT uznalem juz za twor nie warty uwagi takze nawet sie nad tym nie zastanawialem, ale super ze o tym wspominasz ;). Byc moze ktos bedzie chcial
      zbadac zaproponowana przez Ciebie kombinac ;).

  6. Hehe I’ve repeat publicly what I’ve said privately some time a go: This is a great find and piece of excellent research 🙂

  7. omeg says:

    Swoją drogą, CreateProcessW zdaje się nie obsługiwać długich ścieżek. Szkoda. 😉

    • Icewall says:

      @omeg
      Hymm, jak najbardziej można przy użyciu CreateProcessW uruchomić aplikacje spod długiej ścieżki. Należy jedynie pamiętać o tym że uruchamiana aplikacja nie może posiadać manifestu dla SxS, bo wtedy żeczywiście wystepuje jakiś problem w sxs.dll.

    • Icewall says:

      Hej,
      Nie spotkalem sie z tym papierem wczesniej, takze dzieki za link.
      Jak widac, juz od dawna ten temat wzbudzal zainteresowanie ;).

Comments are closed.