Windows Vista 1. servisa pakotnes (SP1) atbalsts beidzas 2011. gada 12. jūlijā. Lai turpinātu saņemt Windows drošības atjauninājumus, pārliecinieties, vai datorā darbojas operētājsistēma Windows Vista ar 2. servisa pakotni (SP2). Lai iegūtu papildinformāciju, skatiet šo Microsoft tīmekļa lapu: dažām Windows versijām beidzas atbalsts.

Ja lietojumprogramma dinamiski ielādē dinamisko saišu bibliotēku (DLL), nenorādot pilno ceļu, sistēma Windows mēģina atrast DLL, meklējot skaidri definētu direktoriju kopu. Ja uzbrucējs iegūst vadību pār kādu no katalogiem, viņš var likt lietojumprogrammai ielādēt ļaunprātīgu DLL kopiju tā vietā, lai tā būtu gaidījusi. Šie uzbrukumi tiek dēvēti par DLL preloading uzbrukumiem, un tie ir kopīgi visām operētājsistēmām, kas atbalsta dinamiskas koplietoto DLL bibliotēku ielādi. Šādu uzbrukumu rezultāts var būt tāds, ka uzbrucējs var izpildīt kodu tā lietotāja kontekstā, kurš izmanto lietojumprogrammu. Kad lietojumprogramma tiek palaista kā administrators, tā var novest pie lokālās privilēģijas palielināšanas. Mēs esam informēti par atjauno interesi šajos uzbrukumos. Lai ierobežotu šīs problēmas ietekmi uz mūsu abpusējajiem klientiem, mēs izlaižam šo dokumentu izstrādātāju Kopienai, lai nodrošinātu, ka šī problēma tiek informēta par šo problēmu, un jums ir vajadzīgie rīki, lai risinātu šo problēmu savās lietojumprogrammās.

Kopsavilkums

DLL ielādēšanas uzbrukumu apraksts

LoadLibrary uzbrukumi

Ja lietojumprogramma dinamiski ielādē DLL, nenorādot pilnu ceļu, sistēma Windows mēģina atrast šo DLL, lineāri meklējot skaidri definētu direktoriju kopu, kas tiek dēvēta par DLL meklēšanas secību. Ja sistēma Windows atrod DLL DLL meklēšanas pasūtījumā, tas tiek ielādēts šajā DLL. Tomēr, ja Windows neatrod DLL nevienā no direktorijām DLL meklēšanas pasūtījumā, tas atgriezīs DLL ielādes darbību. Tālāk ir norādītas DLL meklēšanas secība LoadLibraryun LoadLibraryExfunkcijām, kas tiek izmantotas, lai dinamiski ievietotu DLL:

  1. Direktorijs, no kura ir ielādēta lietojumprogramma

  2. Sistēmas direktorijs

  3. 16 bitu sistēmas direktorijs

  4. Windows direktorijs

  5. Pašreizējais darba direktorijs (HNS)

  6. Direktoriji, kas ir uzskaitīti PATH vides mainīgajā

Iedomājieties šādu scenāriju:

  • Lietojumprogramma ielādē DLL, nenorādot pilnu ceļu, ko tas cer atrast lietojumprogrammas HNS.

  • Lietojumprogramma ir pilnībā gatava rīkoties, ja tā neatrod DLL.

  • Uzbrucējs zina šo informāciju par lietojumprogrammu un kontrolē HNS.

  • Uzbrucējs kopē savu īpaši izveidoto DLL versiju HNS. Tiek pieņemts, ka uzbrucējam ir atļauja to darīt.

  • Windows meklē, izmantojot direktorijus DLL meklēšanas pasūtījumā, un atrod DLL programmas HNS.

Šajā scenārijā programmā speciāli izveidotais DLL tiek palaists lietojumprogrammā un iegūs pašreizējā lietotāja privilēģijas.Ieteikums lai novērstu šo uzbrukumu, lietojumprogrammas var noņemt pašreizējo darba DIREKTORIJU (HNS) no dll meklēšanas ceļa, zvanot uz SetDllDirectory API, izmantojot tukšu virkni (""). Ja lietojumprogramma ir atkarīga no tā, kā tiek ielādēts DLL no pašreizējā direktorija, lūdzu, iegūstiet pašreizējo darba direktoriju un izmantojiet šo iespēju, lai nodrošinātu pilnu LoadLibraryceļu.Mēs apzināmies, ka daži izstrādātāji izmanto LoadLibrary, lai validētu, vai konkrēts DLL ir klātesošs, lai noteiktu, kuru Windows versiju izpilda lietotājs. Ņemiet vērā, ka tas var padarīt lietojumprogrammu neaizsargātu. Ja ietekmētā bibliotēka patiešām nepastāv Windows laidienā, kurā lietojumprogramma tiek izpildīta, uzbrucējs var iepazīstināt bibliotēku ar to pašu nosaukumu programmā HNS. Mēs stingri iesakām izmantot šo metodi. Tā vietā izmantojiet ieteicamos paņēmienus, kas aprakstīti MSDN rakstā "sistēmas versijas iegūšana". Programma, kas ielādē trešo pušu spraudņus un nevar likt spraudņiem izmantot kvalificētu ceļu tā LoadLibrary zvaniem, ir jāzvana SetDllDirectory (""), lai noņemtu HNS un pēc tam zvanītu SetDllDirectory ("spraudņa instalēšanas vieta"), lai pievienotu spraudņa instalēšanas direktoriju DLL meklēšanas ceļam.

SearchPath uzbrukumi

Līdzīgs uzbrukums pastāv, ja lietojumprogramma izmanto SearchPath API, lai atrastu DLL un dinamiski ielādētu ceļu, ko atgriež SearchPath. Tālāk ir SearchPath API noklusējuma meklēšanas secība:

  • Direktorijs, no kura ir ielādēta lietojumprogramma

  • Pašreizējais darba direktorijs (HNS)

  • Sistēmas direktorijs

  • 16 bitu sistēmas direktorijs

  • Windows direktorijs

  • Direktoriji, kas ir uzskaitīti PATH vides mainīgajā

Mēs neiesakām šo shēmu, jo tā nav droša. SearchPath funkciju neiesakām izmantot kā. dll faila atrašanās vietu, ja paredzētais izvades lietojums ir zvanot uz funkciju LoadLibrary. Tas var izraisīt nepareizas. dll faila atrašanās vietu, jo funkcijas SearchPath meklēšanas secība atšķiras no meklēšanas secības, ko izmanto funkcija LoadLibrary. Ja vēlaties atrast un ielādēt. dll failu, izmantojiet funkciju LoadLibrary.

ShellExecute un CreateProcess

Šo problēmu variācijas var arī rasties, ja izstrādātāji izliek līdzīgas funkcijas, piemēram, ShellExecuteun CreateProcess, lai ielādētu ārējas izpildāmas. Iesakām izstrādātājiem būt uzmanīgam, ielādējot bināros failus un norādot pilno ceļu. To var izraisīt mazāk sarežģītības, ja bibliotēkas vietā tiek ielādēts binārs.

Programmatūras izstrādātājiem ieteicamās darbības

Iesakām izstrādātājiem veikt tālāk norādītās darbības.

  • Validējiet to lietojumprogrammas nedrošo bibliotēkas slodžu gadījumiem (to piemēri ir doti tālāk šajā rakstā). Tās ir šādas:

    • SearchPath lietošana, lai noteiktu bibliotēkas vai komponenta atrašanās vietu.

    • LoadLibrary lietošana, lai noteiktu operētājsistēmas versiju.

  • Izmantojiet pilnus ceļus visiem zvaniem uz LoadLibrary, CreateProcess un ShellExecute, kur varat.

  • Ieviesiet zvanus uz SetDllDirectory ar tukšu virkni (""), lai noņemtu pašreizējo darba direktoriju no noklusējuma DLL meklēšanas secības, kur tas ir obligāts. Ņemiet vērā, ka SetDllDirectory ietekmē visu procesu. Tāpēc tas ir jāveic vienreiz pirms un pēc zvaniem uz LoadLibrary. Tā kā SetDllDirectory ietekmē visu procesu, vairāki pavedieni, kuri zvana SetDllDirectory ar dažādām vērtībām, var izraisīt nedefinētas darbības. Turklāt, ja process ir paredzēts, lai ielādētu trešo personu dll, testēšana būs nepieciešama, lai noteiktu, vai procesa mēroga iestatījums izraisa nesaderību. Zināma problēma ir tā, ka lietojumprogrammas, kas ir atkarīgas no Visual Basic for Applications, iestatījuma mērogs var izraisīt nesaderību.

  • Izmantojiet funkciju SetSearchPathMode, lai procesam iespējotu drošā procesa meklēšanas režīmu. Tas pārvieto pašreizējo darba direktoriju uz pēdējo vietu SearchPath meklēšanas sarakstā.

  • Izvairieties no SearchPath izmantošanas, lai pārbaudītu, vai nav DLL, nenorādot pilnu ceļu, pat tad, ja ir iespējots drošas meklēšanas režīms, jo tas joprojām var izraisīt DLL preloading uzbrukumus.

Norādījumi par nedrošu bibliotēkas slodžu identificēšanu

Avota kodā tālāk norādīti nedrošās bibliotēkas slodžu piemēri.

  • Tālāk esošajā koda piemērā programma meklē "schannel.dll", izmantojot mazāko drošo meklēšanas ceļu. Ja uzbrucējs var ievietot schannel.dll programmā HNS, tas tiek ielādēts pat tad, kad programma meklē Windows direktorijus atbilstošajā bibliotēkā.

    DWORD retval = SearchPath(NULL, "schannel", ".dll", err, result, NULL); HMODULE handle = LoadLibrary(result);
  • Tālāk esošajā koda piemērā lietojumprogramma mēģina ielādēt bibliotēku no dažādām lietojumprogrammu un operētājsistēmu vietām, kas aprakstītas šī dokumenta sākumā LoadLibrary () izsaukumā. Ja fails nav pieejams, lietojumprogramma var mēģināt ielādēt failu no pašreizējā darba direktorija. Šis scenārijs ir nedaudz mazāk bīstams nekā Iepriekšējais piemērs. Taču tas joprojām pakļauj lietojumprogrammas lietotājam risku, ja vide nav pilnībā prognozējama.

    HMODULE handle = LoadLibrary("schannel.dll");

Tālāk ir norādīti labākas, drošākas bibliotēkas slodžu piemēri.

  • Tālāk esošajā koda piemērā bibliotēka ir ielādēta tieši, izmantojot pilnu ceļu. Uzbrucējam nav riska, kurā tiek ieviests ļaunprātīgs kods, ja vien viņam jau nav rakstīšanas atļauju lietojumprogrammas mērķu direktorijā.

    HMODULE handle = LoadLibrary("c:\\windows\\system32\\schannel.dll");

    Piezīme informāciju par to, kā noteikt sistēmas direktoriju, skatiet šādos resursos: GetSystemDirectory

    http://msdn.microsoft.com/en-us/library/ms724373%28VS.85%29.aspxSHGetKnownFolderPath

    http://msdn.microsoft.com/en-us/library/bb762188%28v=VS.85%29.aspx

  • Tālāk esošajā koda piemērā pašreizējais darba direktorijs tiek noņemts no meklēšanas ceļa, pirms zvanāt uz LoadLibrary. Tas ievērojami samazina risku, jo uzbrucējam būtu jākontrolē vai nu lietojumprogrammas direktorijs, Windows direktorijs vai jebkura lietotāja ceļā norādītie direktoriji, lai izmantotu DLL preloading uzbrukumu.

    SetDllDirectory ("");HMODULE handle = LoadLibrary("schannel.dll");
  • Visās sistēmās, kurās ir instalēts drošības atjauninājums 963027 (aprakstīts MS09-014), šis kods neatgriezeniski pārvietos HNS uz pēdējo vietu meklēšanas pasūtījumā. Visi vēlākie zvani uz funkciju SetSearchPathMode no šī procesa, kas mēģinās mainīt meklēšanas režīmu, neizdosies.

    SetDllDirectory ("");HMODULE handle = LoadLibrary("schannel.dll");
  • Tālāk esošajā koda piemērā pašreizējais darba direktorijs tiek noņemts no meklēšanas ceļa, pirms zvanāt uz LoadLibrary. Tas ievērojami samazina risku, jo uzbrucējam būtu jākontrolē vai nu lietojumprogrammas direktorijs, Windows direktorijs vai jebkura lietotāja ceļā norādītie direktoriji, lai izmantotu DLL preloading uzbrukumu.

    SetSearchPathMode (BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE | BASE_SEARCH_PATH_PERMANENT );HMODULE handle = LoadLibrary("schannel.dll");

Procesa pārrauga izmantošana, lai dinamiski noteiktu nedrošās slodzes

Microsoft publicē rīku, kas nosaukts par procesa monitoru. Šis rīks ļauj izstrādātājiem un administratoriem rūpīgi izsekot notiekošā procesa darbību. Procesa monitoru var izmantot, lai dinamiski noteiktu, vai kāda no lietojumprogrammām var būt neaizsargāta pret šāda veida problēmu.

  • Lai lejupielādētu procesa monitoru, apmeklējiet šo Microsoft tīmekļa lapu:

    http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

  • Mēģiniet startēt lietojumprogrammu, izmantojot HNS kopu noteiktam direktorijam. Piemēram, veiciet dubultklikšķi uz faila, kuram ir paplašinājums, kura failu apdarinātājs ir piešķirts jūsu lietojumprogrammai.

  • Iestatiet procesa monitoru ar šādiem filtriem: alternatīvais teksts

  • Ja tiek notriekts neaizsargāts ceļš, redzēsit kaut ko, kas līdzīgs šim: alternatīvais tekstsuz attālo failu koplietošanu, lai ielādētu dll, norāda, ka šī ir neaizsargāta programma.

Papildinformācija

Lai iegūtu papildinformāciju, apmeklējiet šīs Microsoft tīmekļa vietnes: dinamisko saišu bibliotēkas meklēšanas secība

http://MSDN.Microsoft.com/en-us/library/ms682586 (VS. 85). aspxMSDN dokumentācija SearchPath funkcijā

http://MSDN.Microsoft.com/en-us/library/aa365527 (VS. 85). aspxMSDN dokumentācija LoadLibrary funkcijā

http://MSDN.Microsoft.com/en-us/library/ms684175 (VS. 85). aspxMSDN dokumentācija SetDllDirectory funkcijā

http://MSDN.Microsoft.com/en-us/library/ms686203 (VS. 85). aspxMSDN dokumentācija SetSearchPathMode funkcijā

http://MSDN.Microsoft.com/en-us/library/dd266735 (VS. 85). aspxEmuāra ziņa, ko sniedz Deivids Leblanc, galvenais drošības speciālists ar Microsoft Office

http://blogs.msdn.com/b/david_leblanc/archive/2008/02/20/dll-preloading-attacks.aspxEmuāra ziņa ar Andrew Rothes, MSRC inženierijas komanda DLL preloading uzbrukumiem

http://blogs.technet.com/b/srd/archive/2009/04/14/ms09-014-addressing-the-safari-carpet-bomb-vulnerability.aspx

Papildu resursi

Nepieciešama papildu palīdzība?

Vēlaties vairāk opciju?

Izpētiet abonementa priekšrocības, pārlūkojiet apmācības kursus, uzziniet, kā aizsargāt ierīci un veikt citas darbības.

Kopienas palīdz uzdot jautājumus un atbildēt uz tiem, sniegt atsauksmes, kā arī saņemt informāciju no ekspertiem ar bagātīgām zināšanām.