Pokračovat ve čtení »]]> Také se Vám po poslední aktualizaci rozbil Lastpass?

Lastpass měl poslední dobou máslo na hlavě, kdy opravoval každý týden nějakou zásadní chybu. Je dobře, že to aspoň přiznali a konali.

Nicméně zřejmě v tom fofru neměli moc času na testování a tak se stalo, že zatímco verze

4.1.45.84 (z 23.3.2017)  na  Win32bit / Chrome 49.0.2623 je funkční bez problémů,

tak následující verze 4.1.45.87 (z 3.4.2017) už ne

s touto verzí totiž .js hází chybu

onloadwff.js: Uncaught SyntaxError: Identifier ‘is_watermark‘ has already been declared

Tato chyba zdá se je jen ve starém chromu 49 (poslední verze pro XP), u novějších verzí jsem na tuto chybu nenarazil a zdají se být funkční.

Řešením je buď použít novější verzi chrome a nebo  – pokud třeba máte windows XP a nemůžete chrome upgradovat –  nezbývá než Lastpass dočasně downgradovat ( a doufat, že to autoři s vydáním příští verze snad opraví )

Pokud se rozhodnete pro to druhé řešení, tak zde naleznete upravený (viz níže) Lastpass verzi 4.1.45.84 ke stažení

abyste zabránili  automatické aktualizaci pluginu na novější verze, tak

1.obsah archivu rozbalte do složky,

2. poté aktivujte v chrome://extensions vývojářský režim a

3. zvolte načíst rozbalené rozšíření

Tímto způsobem zajistíte, že se Lastpass nebude již nadále aktualizovat a zůstane ve Vašem Chromu zakonzervován v této poslední funkční verzi.

Nebo si také můžete stáhnout originální neupravený archiv Lastpass 4.1.45.84 a přepsat jím obsah složky aktuální verze , např

%USERPROFILE%\Local Settings\Application Data\Google\Chrome\User Data\Default\Extensions\hdokiejnpimakedhajhdlcegeplioah\4.1.45.87_0

samozřejmě, pokud bude zlobit v budoucnu nějaká novější verze, stačí obsah složky nahradit, ale přitom zachovat  číslo nejnovější verze v názvu této složky

Toto je však nutno s každým dalším vydáním nové verze zopakovat, neboť se rozšíření automaticky aktualizují.

Pokračovat ve čtení »]]> Chyba 0x0000006B  PROCESS1_INITIALIZATION_FAILED

nastává, pokud je špatně vygenerovan c:\windows\system32\codeintegrity\bootcat.cache

Tento soubor je generován při startu windows 7 ři 2008 R2 a mění se pokaždé když se změní databáze podisů ovladačů a aplikací c:\windows\system32\catroot (což znamená po každé instalaci čehokoliv vč. automatických aktualizací windows)

Pokud máte přístup ke stroji s podobnou konfigurací, můžete zkusit přenést tento soubor z něj. Pokud se však stroje budou lišit (např jinou verzí nějakého ovladače) pravděpodobně tím rozbijete konfiguraci a něco nebude fungovat – to je nepříjemné, pokud se Vám takto podaří rozbít např. ovladač grafické karty

Nejlepší způsob opravy je:

1. vyndat disk, připojit jej k fungujícímu stroji
2. zkontrolovat katalog podpisů \windows\system32\catroot\ zda obsahuje složku {F750E6C3-38EE-11D1-85E5-00C04C2295EE} a zda je v ní databáze certifikátů ovladačů tvořená několika stovkami až tisícovkami souborů certifikátů *.cat (přesný počet záleží na konkrétní konfiguraci stroje a na momentálně nainstalovaných updatech). Pokud tato složka chybí, je prázdná nebo obsahuje jen jeden soubor oemXX.cat (kde XX je nějaké číslo, např. oem19.cat), bude nutné nejprve vyhledat původní obsah a vrátit jej kam patří, případně se pokusit přenést obsah této složky z jiné instalace windows 7 / 2008R2 pokudmožno co nejvíce podobné té Vaší, jinak opět nebude něco fungovat.
3. Po úspěšné opravě, tedy obsahuje-li už složka catroot správnou databázi certifikátů, je pak možno soubor \windows\system32\codeintegrity\bootcat.cache smazat nebo přejmenovat aby při startu systému mohl být automaticky vygenerován nový.

A nakonec ještě poznámka k původnímu obsah složky \windows\system32\catroot\

Po diskuzních fórech se povaluje spousta “zaručených” návodů jak opravit chyby ve windows update. Většina jich doporučuje smazat c:\windows\system32\catroot2\, který se po opětovném spuštění služeb windows update (wuausvc) a šifrování (cryptsvc) vytvoří znovu. Poku však krom catroot2 omylem smažete či v lepším případě přejmenujete také složku catroot zaděláte si tím na problém, neboť tato složka se automaticky NEOBNOVÍ a přijdete tak o digitální podpisy (certifikáty) všech updatů a ovladačů, které jste si kdy nainstalovali do čisté instalace windows. Pokud by se teoreticky jednalo o čerstvou instalaci bez servicepacku a bez aplikovaných updatů, nic se nestane, ale v dnešní době je většina stojů s tímto starým operačním systémem plná doinstalovaných updatů a ovladačů, takže databáze catroot obsahuje i několik tisíc položek.

Pokračovat ve čtení »]]> pokud se Vám nějakým způsobem rozbil raid 1, potřebujete provést znovu synchronizaci, spolehnete se přitom na HP  – a můžete narazit jako já. Proto věnujte prosím pozornost tomuto kratičkému návodu, jak se vyvarovat několika hodinám nervování.

Většinou předpokládám, že pokud se má něco pokazit, nebude to v tak fundamentální věci, jako je firmware raid controlleru. Bohužel HP se to povedlo .Stroj zákazníka byl HP proliant ML110G6 s raid controllerem B110i. Verze firmwaru 1.38

potřeboval jsem rozbít array a poté ho znovu sestavit, což obvykle nebývá žádný problém. Avšak narazil jsem, když jsem potřeboval spustit rebuild. Kontrolér správně poznal, že je to potřeba a nabídl mi (cituji volně, přesnou formulaci si nepamatuji):

press F1 for automatic data recovery (resync)

press F2 for continue boot without recovery

 

nabízel mi defaultní akci (F1) po uplynutí 60 vteřin odpočtu, tak jsem pro urychlení stiskl očekávanou F1 a očekával nějakou odezvu …. a ono NIC

dole na obrazovce stále svítilo RESUME F1 or F2 a já jsem čekal a čekal a čekal až proběhne synchronizace.

Po hodině mi přišlo podezřelé, že

1. domnělá synchronizace neukazuje žádný progress bar či jiný indikátor a

2. hlavně že tato činnost neprobíhá na pozadí při normální funkci OS – jedná se přece o server, tak kolik hodin ještě mám čekat, než konečně naběhne a já budu moct jít domů??

Nakonec jsem to nevydržel a musel jsem jej natrvrdo vypnout.

Při následném pokusu jsem se ničeho raději  už nedotýkal, F1 jsem nestiskl, počkal jsem 60 vteřin – a hle, najednou se objevila očekávaná hláška automatic rebuild started a systém pokračoval ihned v bootování… za minutu bylo vyřešeno, synchronizace probíhala na pozadí a já mohl jít domů.

Tedy resumé: HP smart array obsahuje chybu ve firmwaru 1.38, kdy automatická synchronizace raidu se nepouští stiskem F1 ale naopak jeho NESTISKNUTÍM

(Pro zajímavost: klávesa F2 mi předtím pro rozbití raidu fungovala, takže v  klávesnici to nebylo)

Pokračovat ve čtení »]]> Mám doma na půdě už nějaký ten rok svůj server. Když jsem se kdysi dávno při instalaci rozhodoval, který OS použiju pro nejnižší vrstvu virtualizace, tehdy jsem se rozhodl pro Windows server 2012 R2 CORE.  Důvody proč jsem nepoužil linux Xen nebo KVM byly spíš podružné, měl jsem prostě chuť vyzkoušet, jak budou linux guesti fungovat pod hyper-v. A taky zvědavost, japato že fachá ten Microsoftí server zdarma.

No nebyla to nejrozumnější volba: bez windows 8+ workstationu narazíte na věci, které cmdlety prostě udělat nejdou.Ale to  o tom až jindy.

Chtěl jsem dnes sdělit postřehy s tím falešným raid řadičem, za který se zřejmě AMD stydí a tudíž jej ani pořádně nepojmenovalo. Ano, řeč bude o Amd Optimal Raidu integrovaném v chipsetech SB7xx, SB850 a zřejmě i novějších.

Nevím jak dnes, ale dříve byly tyhle pseudo RAIDy nepříliš oblíbené pro svou nízkou výkonnost a hlavně protože to nebyly skutečné hw. řadiče, ale jen jakási nadstavba biosu, kterou se dal nějaký základní array nastavit. Veškeré další běžné činnosti pak řídil a vykonával hostitelský OS pomocí (také neoblíbených) proprietárních ovladačů.

V tomto jsem za uplynulých cca 10 let stále nezaznamenal žádný pokrok.

Je pravda, že dnes už vzhledem k výkonu aktuálních CPU a propustnosti sběrnic není zatížení CPU  vlivem administrace spojené s RAID řadičem již rozhodující, toho 1% ubraného z výkonu asi není nutno litovat.

Problém stále zůstává v tom, že tyto pseudo raidy jsou závislé na OS, a pokud opravdu nastane problém, tak jej nevyřešíte bez nabootování OS  a spuštění aplikace pro managment raidu. Což je ovšem dost chyba designu, neboť když už problém nastane, zpravidla to znamená, že nechcete pokračovat v bootování a riskovat, že dojde k úplnému rozpadu raidového pole a ztrátě dat.

Nicméně nedá se v tomto případě nic dělat. Pokud se v postu objeví nějaká chyba, je ten bios tak hloupý, že stejně v něm nejde nic opravit. Maximálně tak můžete  pokusit se pole zcela zrušit a sestavit znovu (pozor na initalisation, zřejmě o data nechcete přijít), ale výsledek je nezaručen a operace značně riskantní.

Největší fail je, když dojde k rozpadu / degradaci pole, pokusí se navíc pokračovat v bootování bez zásahu uživatele, což považuju za obrovskou chybu. Neboť samozřejmě, jakmile se na jeden ze dvou disků v raid1 šáhne, dojde k nenávratnému rozpadu pole, neboť si potom obrazy binárně neodpovídají. A to se také stalo. Omylem jsem zapojil jeden z disků do špatného sata portu (jež nebyl aktivní), a ten pitomý raid management jen asi na vteřinu zobrazil varování. Než jsem stačil zasáhnout už pokračoval v bootování a bylo to. Raid se mi rozpadl a sesynchronizovat jej znovu nebylo čím.

Nepříjemné je, že v případě amd je managment aplikace (zvaná RaidXpert tool) určena dle popisu pouze pro Win 7, Win8, Win8.1. a win 10. No řekněme, že pokud běží na Win 8 / 8.1, mohlo by to jít i na  Win 2012 / 2012 R2… ale garantováno to jaksi není….. Ale co CORE server? nikde ani zmínka sakryš…

(pokračování příště)

Pokračovat ve čtení »]]> Při dění kolem Bashe v nedávné aféře jsem byl donucen aktualizovat všechny svoje nainsatalované distribuce od Mandrivy po Ubuntu. Ty novější  (např Ubuntu 12.04 LTS a samozřejmě nejnovější 14 ) šly aktualizovat automaticky z repozitářů.

Ale u některých postarších (konkrétně třeba Mandriva 2010, Ubuntu 13.04) už jejich tvůrcům na bezpečnosti asi tolik nezáleží , takže nezbylo než v těchto případech kompilovat ze zdrojového kódu 

Pominu fakt, že patche přibývaly téměř každým dnem po dobu zhruba dvou týdnů. Když už tahle zranitelnost vydržela více jak 10 let, potom myslím, že ten týden zdržení na vydání jedné kumulativní záplaty by se asi dal vydržet ale budiž…

Zaujalo mne však, že ani po aplikaci všech záplat jsem se s verzí 3.2.57 nedostal přes všech 5 testů bez ztráty květinky. Zkrátka mi na jednom stroji zranitelnost 7187 (nested loops) stále zůstává a nejde opravit.

Toto jsem vyřešil tak, že jsem vyměnil shelly a místo bashe mám teď pro všechny defaultně sh. Jediný účet s bashem používám jenom já pro správu. Mohl jsem si to dovolit, protože se jedná o backend server bez lokálního přístupu běžných uživatelů .

Nicméně, zjistil jsem, že se mezi sebou verze BASHe poměrně zásadně liší i mezi dvěma minoritními verzemi, konkrétně neopatchovaná 3.2.48 vs 3.2.57:

Totiž původní neopatchovaná verze byla benevolentní co se týče deklarace funkcí, zatímco opatchovaná je v tomto striktní. Vzhledem k povaze objevených zranitelností by se to dalo očekávat, nicméně pro nepřipravené to znamená komplikace a nepříjemnosti spojené s laděním nutným po opatchování.

Skripty odladěné na přechozí verzi po opatchování začaly najednou kravit a vyhazovat chyby, které jsem nikdy předtím nezaznamenal. Poněkud mne zarazilo že to nedělaly ani tak moje vlastní skripty, ale často i poměrně zásadní součásti systému, zejména rd (init) skritpy.

Zjistil jsem, že zatímco původní neopatchovaná verze bashe umožňovala deklarovat funkci minimálně třemi způsoby:

standartně:

function function_name {
command…
}

 zkráceně ( C++ like ):

function_name () {
command…
}

a navíc také tolerovala sémanticky chybný zápis ve formě:

function function_name () { 
command… 
} 

což už ale opatchovaná striktní verze nezkousne !!  

Bylo nutné tyto nestandartní zápisy ručně opravit. 

Nejsem odborník na nastavení bashe, možná že by se dala pomocí nějaké proměné nastavit citlivost parseru na takto chybné zápisy. Vzhledem k aféře se zranitelností shellshock si ale spíš myslím, že zpřísnění a “striktní mód” je na místě. Myslím, že jinak než úpravou kódu se těmto nepříjemnostem asi nelze vyhnout.

Pokračovat ve čtení »]]> Jedná se o MVC aplikaci napsanou v PHP 5.3

Použil jsem Zend Framework 1 a to zejména z důvodu dobré dostupnosti dokumentace a literatury. Další aplikace ale už budu raději vyvíjet v nette nebo jiném frameworku, neboť u Zend-u jsem narazil na dost nečekané a otravné limity zejména v oblasti spolupráce s Ajax, jquery, přizpůsobení vzhledu, atd.

Dále také používám MYSQL 5.5, Apache 2 a APC resp. memcached daemona.

Vstupem jsou textové (csv) tabulky jednotlivých uskutečněných volání (volající, volaný čas zahájení, čas ukončení). Výstupem jsou faktury v pdf a xml pro jednotlivé koncové zákazníky, dále seznamy jednotlivých uskutečněných volání konkrétního uživatele, jež lze v html prohlížet, filtrovat, sumarizovat a řadit podle různých sloupců.

Tento projekt je stále ještě ve stádiu vývoje, nebyl zatím předán zadavateli, takže ještě nemohu zveřejňovat veškeré podrobnosti, na které bych chtěl upozornit. Jakmile to bude možné, tento text rozšířím o konkrétní ukázky a zajímavosti, na které jsem v průběhu vývoje této aplikace narazil.

• Podle volajícího ID (číslo A)  se načtou data uživatele a patřičný ceník uživateli přiřazený.
• v ceníku se vyhledá tarif odpovídající předčíslí s největším stupněm shody s volaným ID (číslo B)
• každý ceník má cca 6000 řádků, tedy z důvodu urychlení využíváme cachování pomocí jedné z více možných metod memcached, APC, RAM, RAMDISK
• podle Timestampu volání se určí, zda se jedná o silný či slabý provoz (svátky, Vánoce, Velikonoce, víkendy atd)
• na základě údajů z ceníku se určí také tarifikace, která je rozdílná pro různé kategorie uživatelů a také pro různé destinace volání (60+60, 60+1, 30+1, 15+15, 1+1)
• spočítá se výsledná cena
• musí se ošetřit přechody mezi vysokým a nízkým tarifem v rámci jednoho hovoru
• musí se ošetřit různé chytáky ve speciálních tarifech (linky 810, 900,906, 976, 1188, 1301 apod)
• kontroluje se minimální marže (koncová cena pro zákazníka vs. spojovací poplatky operátorům a poskytovatelům)
• v případě chyby (nenalezen uživatel nenalezen tarif atd) nejsou faktury vygenerovány a vše se vrátí ze zálohy do původního stavu

další je myslím nejlépe patrné ze screenshotů:

Uživatel + JS

◄ Back

Next ►

Picture 1 of 19

Editace uživatele. Verifikace polí formuláře pomocí javascriptu.

Pokračovat ve čtení »]]> XSS znamená cross-site scripting. Je to velmi často používaná metoda útoku, kdy útočník propašuje škodlivý kód do PHP či jiné aplikace. Docílí tak toho, že uživatel či správce, který aplikaci použije, aniž by to spozoroval spustí kód z jiného umístění.

Tato metoda předpokládá, že buď má útočník přístup pro zápis do nějaké části (souboru) aplikace (špatné zabezpečení, bezpečností díra, chyba v kódu) a injektuje tak odkaz např. do css.

Nebo je tam tento backdoor už od začátku a třeba několik měsíců o sobě nedá vědět, dokud se útočník nerozhodne útok provést (samozřejmě – to se nás netýká, my stahujeme všechny pluginy pro wordpress z ověřených zdrojů a kontrolujeme všechny řádky jejich kódu!)

Asi nejčastější případ je, že se útočníkovi povede tento škodlivý kód dostat do dat, které se cílené osobě zobrazují. Toto je možné provést libovolnou akcí, která předpokládá zobrazení infikovaných dat v prohlížeči administrátora či osoby, na níž je útok veden.

Asi nebude problém nalézt nějakou akci uživatele, jež vyžaduje zobrazení v prohlížeči např. administrátora – takové přidání nového příspěvku do diskuze, zadání nové objednávky v e-shopu, žádost zadaná přes kontaktní formulář, a spousta dalších jiných akcí toto předpokládá.

Je to velmi jednoduché – útočníkovi stačí najít neošetřené textové či jiné uživatelské vstupy, přes které krom standardního textu projdou také znaky <> :/”

schválně si zkuste, kolik diskuzních fór či e-shopů dovolí registrovat uživatele s adresou dejme tomu

Tonda Novak

<script src=”http://www.bouska.biz/public/xsstest.js”></script>

Praha 1

(Můžete si vyzkoušet – soubor xsstest.js z příkladu v případě spuštění vyvolá popup okno s varováním.)

Samozřejmě, že toto ještě neznamená, že potenciálně škodlivý skript xsstest.js se skutečně SPUSTÍ

Pokud programátor odvedl svou práci v přijatelné kvalitě, budou buď tagy zcela vypuštěny a nebo budou převedeny opisem  na neškodný textový řetězec, který nezpůsobí spuštění tohoto kódu ale pouze zobrazení uvedeného textu. Text pak např. místo znaku  < obsahuje řetězec &lt který prohlížeč interpretuje jako text a nikoliv jako začátek tagu. Filtrování je možno provézt minimálně na dvou místech: při přijímání dat z formuláře a nebo až při jejich zobrazování v pohledu. Důsledný programátor použije pro jistotu filtrování na obou místech.

Pokud však programátor byl lempl, tak se filtrování neprovede, data se v nezměněné podobě uloží a při dalším zobrazení se prohlížeči pošlou opět v nefiltrované podobě.

Tak schválně… kolik běžně používaných diskuzních fór, CMS, ERP, seznamek,  bazarů, eshopů a jiných běžně dostupných aplikací nefiltruje data a dovolí Vám registrovat se s výše uvedenou adresou (přezdívkou, poznámkou, vzkazem pro administrátora)

Tak to by bylo pro tentokrát vše, v příštím dílu si povíme, jak může vlastně škodit ten škodlivý kód.