Problém je také v tom, že každá aplikace může mít tutéž knihovnu, ale jinou verzi. Typicky ve Windows je v adresáři knihovna ABC_2342.DLL a ABC_2233.DLL a aplikace si zavolá jen knihovnu ABC.DLL, systém pak rozhodne podle svých záznamů kterou knihovnu aplikace do systému zkopírovala, tu jí nalinkuje pod názvem ABC.DLL, je to proto, že když je obrovské množství programů psané v obrovském množství jazyků, tak by i pouhý update na novou verzi knihovny (typicky třeba .NET) mohl znefunkčnit velké množství aplikací, které počítají právě s tou verzí knihovny na kterou jsou stavěny. Pak by tedy mohlo být absolutní pozicování knihoven problém.
Nechci znít nějak negativně nebo se o autora (či snad soudruhů bezpečnostních techniků) navážet, ale buď jsem natrdlý a něco naprosto nepobírám, nebo někdo v jednadvacátém století objevil Ameriku. Navazování jménem tu bylo odjakživa, je to mj. jedna z věcí, kterou .NET (a věřím, že i jiné systémy) řeší silnými jmény, podpisy knihoven atd. Už za dob DOSu tvůrci virů věděli, že mohou nepozornému uživateli podstrčit škodlivý kód pod duplicitním jménem. Pokud aplikace používá WinAPI, tak má knihovny především v chráněném adresáři Windows (pokud někdo není hazardér a ochranu neodstřelí), popřípadě ostatní knihovny má v chráněných Program Files a je na autorovi aplikace, zda si je nějak ověřuje nebo ne. To, že občas levá ruka programátorova neví, co dělá pravá, je jiná věc. Třeba to vývojáře konečně dokope k nějakému důrazu na bezpečnost.
Ano, souhlasím že s provalením téhle finty přibude útoků, ale i tak myslím, že pro běžného uživatele hrozba nijak znatelně nenarostla.
Odkud se zase tohle siri? At mi nikdo nerika, ze z tyhle vlastnosti po 25letech existence windows a DLL knihoven nejsou mezi programatory obecne zname.
Navic s poslednimi windows mi pripada ponekud obtiznejsi podstrcit knihovnu aplikaci bez administratorskeho opravneni. (a s administratorskym pristupem se otevira daleko vic moznosti jak donutit aplikaci provadet cizi kod, nez jenom vlozenim proxy knihovny)