Názory k článku Postřehy z bezpečnosti: jaderné bitcoiny

1PFlofs 1 PFlops (FLoating-point Operations Per Second)

Použil bych tlačítko „Nahlásit chybu“, ale ono v mobilní verzi není.

Honem, rakušáci už chystají peněženky, aby mohli nakupovat filtry, které k nim nepustí jaderné bitcoiny. Elektriku už mají čistou a už jsou naučení za to utrácet...
Vymyslete někdo nějaký reklamní krasožvást, já udělám "hardware" a rozjedeme podnikání ve velkém a odporně zbohatneme...

;-)

olympic destoryer :)
hned se mi líp vstává, krásný den... :)

Skype chyba. Co treba pridat novy updater? Nechat ten stary neopraveny a jen pridat novy program a presmerovat updatovani na nej. A ten by pak zavolal pripadne dalsi funkce z toho stareho updateru.

To uz je asi fuk 1.3 MS zarizne starej skype a bude fungovat jen ta nova nefunkcni slatanina.

Updaterů není nikdy dost, a ještě by tam mohli přidat pár dalších služeb na pozadí a jednu službu, která by ty ostaní řídila a updatovala. Taky nějaký silnější notifikátor který by notifikoval každých pár vteřin o důležitých událostech a komentoval stav počítače a radil.

Myslis neco jako "Pan Sponka" ?

Prosím nejmenovat, nebo se zombie vrátí...

To už zkoušelo Adobe mít stahovač aktualizací pro stahovač aktualizací, problém nastal ve chvíli, kdy se objevila chyba i v něm.

Tohle je chyba s eskalací práv. Na tento útok stačí mít na PC normální účet. Díky této chybě mu pak můžete zvednout oprávnění a udělat z něj admina. Takže ten problém trápí v zásadě jen adminy, kteří nechtějí, aby si normální uživatelé sami přidělili práva lokálního administrátora. Což je v korporátním prostředí většina administrátorů.

Ne, to je chyba, že když do složky, ze které se to spouští, podstrčíš vlastní knihovnu, tak při načítání knihoven, na kterých to závisí, se načte ta tvoje. Nezískáš tím žádná práva, která bys nemohl získat "normálně" a MS to neopravuje jen proto, že to v tomhle případě za to nestojí.

To co popisujete (podsunutí vlastní dll knihovny) je "standardní chování" a MS s tím opravdu moc dělat nehodlá/nemůže. Chyba ve Skype je o tom, že updater si pro svou funkci obstará vyšší práva a ochotně pak zavolá .dll. Pokud se tohle sejde - updater zavolá podvrhnutou .dll ve chvíli, kdy má proces práva administrátora, tak pak je problém.

Řešení je stejné: část procesu, co běží v privilegovaném módu, nemá co načítat uživatelské programy nebo dynamické knihovny. Privilegovaný kód musí být vždy ve statické knihovně a mimo dosah uživatele.

V Linuxu taky nedáte setuid bit na něco, co má vlastníka root a v rámci vlastního procesu spustí kód dodaný uživatelem. I když je fakt, že už jsem zažil člověka, co zkoušel dát setuid na bash.

Chyba ve Skypu je opravena - detaily zde: https://www.theregister.co.uk/2018/02/15/microsoft_skype_fixed/

"Jakmile příjemce obdrží zprávu obsahující daný znak, nebo tento znak na klávesnici napíše, zařízení nebo aplikace spadne a odmítne normálně fungovat, dokud znak není odstraněn. To se dá ve většině případů vyřešit např. výmazem celého vlákna konverzace. Apple už o chybě ví a intenzivně pracuje na její nápravě."

Může prosím někdo dovysvětlit? Z tohoto odstavce se zdá, že aplikace, která odmítá fungovat, magicky umožňuje smazání vlákna konverzace. Podle odkazovaného článku je obvykle potřeba poslat jinou zprávu z jiného zařízení - předpokládám, že proto, že pak místo nezpracovatelné zprávy bude zobrazovat jen tu novou. Ale pak stačí jen neotevírat to staré vlákno, ne?

Taky jsem se nad tím zamyslel. Nicméně tak, jak je to popsané v článku, se mi to zdá dostatečné (jsou to postřehy, více ví Google).

Ale předpokládám, že jakmile se ten znak má zobrazit nebo jinak interpretovat, tak iDevice dostane infarkt. Takže stačí ten znak nezobrazovat, třeba právě tak, že smažu vlákno bez toho, abych musel vidět jeho obsah. Negooglil jsem to, jen to předpokládám.

Nehledal jsem co je tohle konkrétně za chybu, ale jako první myšlenka mě napadla chyba v interpretru definice fontu (tedy zobrazení konkrétního fontu). Domnívám se, že to není chyba algoritmu, který jenom zpracovává znaky ve formě "sekvencí neinterpretovaných bajtů".

Dovolím si tedy oponovat Vašemu tvrzení s tím, že takový test všech Unicode znaků by zřejmě nepomohl, protože aby chybu objevili, museli by k testování použít přesně tu implementaci a verzi fontu, která je použitá ve finálním produktu. Což v případě tak velkého produktu jako iPhone apod. nevypadá reálně a vývojáři s nejvyšší pravděpodobností testovali s jiným fontem a nebo stejným, avšak jinou verzzí.

To je řada domněnek. Opravdu spadne interpretr? Není to třeba o tom, že vyhodí výjimku a nějaká metoda o kus výš jí nezpracuje správně? Je to opravdu nevalidní sekvence? Není to třebas ve skutečnosti nějaké magic number, které programátor kdysi použil v domnění, že v reálném textu se nikdy nevyskytne? A co když je tohle všechno validní a problém je v jiných datech? Já jsem kupříkladu zažil hru, co padala s českým fontem prostě proto, že autor nepočítal s tím, že by některý znak mohl být tisknutelný a přesto mít na šířku 0 pixelů. Takže vše fungovalo do chvíle, než se v textu objevila dvojice znaků ˇr, kdy právě ten háček měl v definici fontu "po vytištění se posuň doprava o 0 pixelů". Takže uvěřím, že problém může ve skutečnosti být v datech (respektive v chybném předpokladu o povaze dat), třebas v těch fontech, a interpreter opravdu nemá problém s tím textem jako takovým.

Nedávno jsem řešil chybu, kdy se alokoval buffer podle délky pročištěného stringu bez neplatných znaků a kopíroval se do ní původní (delší) řetězec. Netušíš v čem ta chyba je, tak nemudruj.

Infikované vlákno je lepší smazat. Otevře se totiž automaticky, když do něj přijde další (korektní) zpráva (a Vy ji otevřete).

జ్ఞ‌ా