Zjištění modifikace podepsané assembly referencované aplikací   zodpovězená otázka

VB.NET, Bezpečnost

CLR by nemělo za běhu aplikace umožnit nahrát referencovanou knihovnu podepsanou silným názvem (Strong Name), která byla po podepsání jakkoliv modifikována (třeba změnou jediného bajtu), protože nebude odpovídat její hash a tedy vyhodit vyjímku FileLoadException. Po řádově týdnech studií a experimentování se mi však nepodařilo libovolnou modifikací podepsané referencované knihovny tuto vyjímku vyvolat, aby na to bylo v aplikaci možné reagovat. Bohužel nedochází k vůbec žádné vyjímce a není tedy možné jakkoliv zjistit, že došlo například k podvržení dané knihovny. Máte s tímto někdo zkušenosti?

nahlásit spamnahlásit spam -6 / 6 odpovědětodpovědět

Přišel jsem na to. Od Frameworku 3.5 Service Pack 1 bylo zavedeno nové pravidlo, které u aplikací v zóně MyComputer (assembly s důvěryhodností FullTrust) vynechává ověřování silného názvu a tudíž nekontroluje, zda hash assembly odpovídá. Proto nedochází k žádné vyjímce. Ověřování se dá vynutit v konfiguračním souboru, v registru, nebo v konfiguraci Frameworku.

nahlásit spamnahlásit spam -4 / 4 odpovědětodpovědět

Nejde ověření provést přes reflexi za běhu?

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Jde, ale to je k ničemu, protože je potřeba, aby načtení assembly zabránil už CLR v době spouštění.

nahlásit spamnahlásit spam -7 / 7 odpovědětodpovědět

Môžete uviesť konkrétnu sekciu konfiguračného súboru resp. konkrétny hive, key a hodnotu v registri?

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Konfigurační soubor:

<configuration>
  <runtime>
     <bypassTrustedAppStrongNames enabled="false" />
  </runtime>
</configuration>

Registr:

Vytvořte položku DWORD s hodnotou 0 jménem AllowStrongNameBypass ve větvi HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework (32bitový systém) nebo HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework (64bitový systém). Nastavení potom bude platné pro všechny .NET aplikace, ne jen pro konkrétní assembly.

nahlásit spamnahlásit spam -5 / 5 odpovědětodpovědět

Jeste jsem tuto funkcionalitu nikdy nepouzival, ale prijde mi trosku bezpredmetne pouzivat konfiguracni soubor (registry asi taky) k tomu abych zajistil overeni integrity. Podle me, kdyz uz nekdo dokaze zmenit tu knihovnu, tak proc by nemel dokazat zmenit ten konfiguracni soubor?

Myslel jsem si, ze tahle zalezitost funguje nejak lepe, ale z toho co se tu pise mi to tak nepripada (coz se mi vubec nelibi)..

Hubert Kindermann

nahlásit spamnahlásit spam -4 / 4 odpovědětodpovědět

Microsoft zřejmě předpokládá, že se všude dodržují doporučené bezpečnostní postupy a tudíž běžný uživatel nebude mít přístup pro zápis do toho konfiguračního souboru nebo registru. Ještě před verzí 3.5 SP1 to ověřování integrity v zóně MyComputer fungovalo bez nutnosti ho vynucovat.

nahlásit spamnahlásit spam -9 / 9 odpovědětodpovědět

Kdyz ale predpoklada, ze se vsude dodrzuji bezpecnostni postupy, tak nemusi vubec Strong Key Signature podporovat (to podle me nedava smysl)... Moc ted nerozumim jeho smyslu. Spis bych rekl ze je tam neco co o cem nevime.

Hubert Kindermann

nahlásit spamnahlásit spam -1 / 1 odpovědětodpovědět

Co to je za nesmysl? Strong Name má dva hlavní důvody: Bezproblémové verzování a možnost udržování integrity assembly.

nahlásit spamnahlásit spam 1 / 1 odpovědětodpovědět

Nemluvil jsem o tom, ze je Strong Name obecne k nicemu, ale z hlediska bezpecnosti a ochrane proti nezadane zmene assembly (tim nemyslim prehranim jinou verzi)..

nahlásit spamnahlásit spam -1 / 1 odpovědětodpovědět

Vůbec není k ničemu z hlediska ochrany, jen se musí vynutit to výše uvedené nastavení. Kromě toho v jiných zónách (například síť) to ověřování ve výchozím stavu funguje. Lepší způsob proti změně assembly u managed aplikací neexistuje.

nahlásit spamnahlásit spam -4 / 4 odpovědětodpovědět

Pán Linhart,

je to zrejme myslené tak, že ak sa všade dodržiavajú bezpečnostné postupy, tak nie je nutné overovať integritu assembly.

nahlásit spamnahlásit spam 1 / 1 odpovědětodpovědět

Jenže oni se všude nedodržují a právě proto existuje toto ověřování integrity. Kromě toho i když uživatel zrovna nemá oprávnění správce, může si aplikaci zkopírovat/nainstalovat kamkoliv jinam než Program Files, nebo aplikaci spustit ze sítě.

nahlásit spamnahlásit spam -5 / 5 odpovědětodpovědět

To je pravda.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

kto ma msn potreboval bych zasifrovat exe subor

nahlásit spamnahlásit spam -3 / 3 odpovědětodpovědět

Co to má znamenat?!

nahlásit spamnahlásit spam 1 / 1 odpovědětodpovědět

Ještě jsem chtěl poznamenat, že zavádět silný název u 3.5 assembly z důvodu udržení integrity je tedy zcela bezpředmětné, pokud například v instalaci nezajistíte vynucení ověřování pomocí nastavení hodnoty v registru. To ale potom může mít negativní dopad na rychlost spouštění ostatních .NET aplikací. Udržovat integritu je potřeba u klíčových součástí aplikace, jako třeba knihovna, která zajišťuje licencování aplikace nebo podobné bezpečnostní záležitosti.

nahlásit spamnahlásit spam -6 / 6 odpovědětodpovědět
                       
Nadpis:
Antispam: Komu se občas házejí perly?
Příspěvek bude publikován pod identitou   anonym.
  • Administrátoři si vyhrazují právo komentáře upravovat či mazat bez udání důvodu.
    Mazány budou zejména komentáře obsahující vulgarity nebo porušující pravidla publikování.
  • Pokud nejste zaregistrováni, Vaše IP adresa bude zveřejněna. Pokud s tímto nesouhlasíte, příspěvek neodesílejte.

přihlásit pomocí externího účtu

přihlásit pomocí jména a hesla

Uživatel:  
Heslo:  

zapomenuté heslo

 

založit nový uživatelský účet

zaregistrujte se

 
zavřít

Nahlásit spam

Opravdu chcete tento příspěvek nahlásit pro porušování pravidel fóra?

Nahlásit Zrušit

Chyba

zavřít

feedback