pdf.js je ale samostatna komponenta, co je do browseru jen prilepena. A nic vam nebrani tu komponentu proste zakazat.
tak si tam zkus dát jinou verzi pdf.js, zjistíš, že vlastně či FF je open source, tak způsob jak připravit pdf.js, jak to otestovat už open source není.
Na cestě toolkit/components/pdfjs není snapshot z pdf.js repa, ale odvozený kód a prostě se do toho musíš ponořit, prozkoumat, porovnat a ručně upravit. Tohle určitě nejde označit jako samostatnou část, stříliš od boku aniž bys tuhle reálii znal.
Samostatnou komponentou je neco, co se z toho prohlizece da klidne i komplet vyhodit a nebude to k ujme, co se tyce zakladni fukncionality od prohlizece ocekavane. A tady je proste pdf.js doplnek, bez ktereho prohlizec fungovat bude. To, ze si to interne Mozilla v ramci Firefoxu priohne je zhruba tak stejne, jako vselimozne lokalni patche v distribucich - kdy pro zachovani nekterych funkci musite nejak pracovat i s tim distribucnim patchem - a nestaci vzit jen kod z upstreamu. A mimoto, tady to zas takova cerna magie neni.
pokud pdf.js smažeš z repositáře a spustíš build FF, selže ti, musíš upravit i build skripty, tohle jako samostatný doplněk opravdu není.
V těch distribucích mají aspoň všecho veřejně, změny mají v patch souborech. Update script je fajn, ale už v něm nejsou ty kroky navíc, které tam dělají. Ve FF se pdf.js používá tak trochu hardcoded, aktualizace není jen o stažení aktuální verze z repa, to je první krok. Před pár měsíci jsem tam potřeboval propašovat změny, aby se řádně zobrazovaly interní podepsaná pdf a sranda to není. Samostatný doplněk vypadá jinak.
Aky svincik?
Co je na tom zvlastne/nenormalne/nove a ako to kontrastuje s sshd?
To si mali napisat vlastny pdf prehliadac? Aj keby, tak by to nic neriesolo, lebo aj v tam moze byt chyba, ktora moze ostat nezaplatana. To riziko je tam vecsie ako pri siroko pouzivanych kniznic/komponent.
A da sa to vypnut.
Já to pochopil tak, že "integrovaný svinčík" je obecný povzdech nad ElectronJS aplikacemi potažmo i třeba hotovými kontejnery z nějakých veřejných repozitářů (Flathub, Dockerhub). A kde všude tahle knihovna zůstane ve zneužitelné verzi bez záplaty. Tyhle aplikační bundly pak dává do kontrastu s démonem sshd, který dělá víceméně "jednu věc" a ještě se má dál dělit kvůli lepší privilege separation.
Já tenhle sentiment úplně nesdílím, protože jak aplikační bundly, tak kontejnery jsou v určitých situacích fajn a zodpovědný správce podobné zranitelnosti musí řešit tak jako tak, ať už je původ software z distribuce, od vendora aplikace nebo nějakého veřejného repozitáře. Ale to už je jiná věc.
21. 5. 2024, 11:46 editováno autorem komentáře
Spravce nic resit nemuze, protoze nema jak. V 99% jsou presne takovyhle svinstva na tema "fungujte to s verzi 1.24.78.787.4.7778.7777 ... a zadnou jinou".
Ovsem v tomhle pripade je to specielni svinstvo, ktere jednak nema v browseru co pohledavat, druhak stejne nefunguje, a zatreti se jeste navic userum vnucuje jako default, takze je to jen a pouze dira.
Spravce nic resit nemuze, protoze nema jak.
Podle zprávičky, odkazovaného článku i CVE toho může udělat docela dost.
Pokud jde jen o Firefox, tak by měl mít na stanicích aktualizované verze 126, resp. ESRko 115.11. Vzhledem k tomu, je to zveřejněné asi dva týdny po opravě, tak by to mělo být ve všech distribucích, resp. aktualizačních kanálech na Windows a MacOS. Ve většině případu si myslím, že už se to stalo, aniž by to někdo řešil.
Pokud je ta JS knihovna používaná mimo Firefox v nějakých webových aplikacích, o které se stará (typicky CMS, self-hostované *Cloud servery s pluginy pro PDF prohlížení atp.), tak by si měl zkontrolovat, jestli má verzi komponenty PDF.js aspoň 4.2.67, nebo jestli se to používá s vypnutou volbou isEvalSupported.
https://github.com/mozilla/pdf.js/security/advisories/GHSA-wgrm-67xf-hhpq
Pokud používá a nasazuje hotové věci (aplikační bundly na bázi Electronu, hotové kontejnery), tak by si v základu měl zkontrolovat, jestli autor/dodavatel/vývojový tým ve firmě udělal nějakou aktualizaci v posledních dvou týdnech.
Případně si ještě prozkoumat changelogy, manifesty, yaml soubory s konfigurací dockeru, které bývají u mnoha projektů dostupné atp. Může si samozřejmě také dohledat soubory v docker image, flatpaku a případně sám zkusit použít to magické PDFko z článku.
Když nepochodí s opravou, tak by si měl nějak vyhodnotit riziko a např. dočasně vypnout konkrétní plugin, informovat uživatele atp.
V 99% jsou presne takovyhle svinstva na tema "fungujte to s verzi 1.24.78.787.4.7778.7777 ... a zadnou jinou".
Nevím, tady je jasně napsaná verze knihovny a FF, od které je to opravené - všechny předtím jsou postižené. Nebo můžete ve web aplikaci použít workaround, příp. backportovat opravu, jestli opravdu nutně chcete mít starší verzi PDF.js.
Když si půjčím vaší konstantu, myslím si naopak že pro 99% aplikací a autorů bude minimální problém konkrétní bundle, nebo kontejner aktualizovat tak aby z NPM použil nejnovější fixnutou verzi knihovny, aniž by jim to cokoliv dalšího rozbilo.
Ten zbytek s těmi svinstvy v porhlížeči je subjektivní pohled, který bude nejspíš trochu odlišný od většiny uživatelů webu, u kterých to vypadá, že naopak ocení, když nemusí každé PDFko stahovat na disk, aby si ho prohlédli - proto je to default. A samozřejmě vám konkrétně nic nebráni nastavit si, jak se váš prohlížeč bude chovat s "application/pdf" MIME typem, jestli máte jiné preference.
Jiste, uzivatel vzdy oceni nejvic, kdyz se mu treba prave to pdfko otevira v necem, co pdfka zobrazit neumi. Coz je presne to, co je v browserech.
Na widlich mam tuhle kravinu zakazanou GPOckem v chomakovi, GPOckem v ve foxovi (tam kde jeste jsou pozustatky, protoze sem ho vetsinou vsude zlikvidoval kvuli hromade dalsich krasnych vlastnosti, jako je napriklad nekonecny vytvareni kopii user profilu) ... ovsem chromej edge to s klidem ignoruje, a cas od casu zresetuje uzivatelum preference na sebe ze?
A samozrejme se to nijak nastavit neda.
A az mi budou vasnosti tvrdit, ze da, tak chci priklad zcela konkretne jak nastavim GPOckem asociaci souboru. Samozrejme tak, aby to nerozbilo nic dalsiho a fungovalo aspon 1/2 roku. Budu se tesit, a semnou dalsi miliony spravcu.
O tom, jak vypadaji dodavky SW zjevne neraceji tusit vubec nic. Dodavatel doda blob, a tak jak ho dodal se to i musi pouzivat. Aktualizace typicky znamena ze se to po 10 letech vsechno nainstaluje znova. Tedy pokud dodavatel jeste existuje.
Mam tu treba zalohovac, nikoli levny (licence v radu MKc) a je tam vyslovene zakaz aktualizovat system pod tim (v tomhle pripade nejaky centos).
Už výrazně odbíháme od PDF.js a Firefoxu, který je v celé věci z pohledu správce a řešení té bezpečnostní chyby ten nejmenší problém - stačí jej standardní cestou zaktualizovat.
Jiste, uzivatel vzdy oceni nejvic, kdyz se mu treba prave to pdfko otevira v necem, co pdfka zobrazit neumi. Coz je presne to, co je v browserech.
Jasně, vzhledem k tomu jak dlouho je to default, tak si klidně tipnu, že uživatelé browserů napříč si zobrazí klidně vyšší desítky milionů nejrůznějších PDFek denně, a to naprosto uspokojivým způsobem pro většinu použití. Ale váš závěr z toho je, že to obecně neumí zobrazovat PDFka :))
Beru, že má někdo osobně jinou preferenci. Stejně jako si dovedu představit, že ve firmě, kde většinově pracují s PDFky obsahující formuláře a skripty a nebo mají postavené document workflow na proprietární fíčurách od Adobe (schvalování, sdílené poznámky atp.), tak řeší deploy Adobe Readeru nebo plného Acrobatu.
Tam kde tahle speciální PDFka nejsou úplně dominantní, a věříte v inteligenci uživatelů, tak ten Reader bohatě stačí nainstalovat jako fallback. Tím mají zachované rychlé, progresivní načítání a zobrazování přímo z prohlížeče nebo mailu, což je většinou "good enough", a pokud už narazí na nějaký formulář, nebo mají třeba velký dokument, kde využijí lepšího vyhledávání, tak si to stáhnou na disk a otevřou v Readeru. Přesně tohle jsou zkušenosti mé zkušenosti jak z menších i větších firem (cca 2k stanic).
Stran té asociace souborů přes GPO, nejsem na rozdíl od kolegů specialista na AD (spíš Linux, MacOS atd.), ale když koukám na jeden server, co tam řeší v šabloně, tak je to v podstatě tohle..
https://techcommunity.microsoft.com/t5/ask-the-performance-team/how-to-configure-file-associations-for-it-pros/ba-p/1313151
Tzn. XMLko s definicí přiřazení na sdílené složce, plus ty volby v článku dole (vypnuté notifikace o nové aplikaci, vypnuté hledání aplikace pro otevření na internetu a ve store...).
Dovedu si představit, že kdybych z nějakého důvodu chtěl mít jistotu, že to použije vždycky ta systémová přiřazení, tak to ještě doplním nějakým powershellem, co rekurzivně projede existující uživatele v systému a odmázne pro konkrétní přípony klíč UserChoice v HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts
Což může být samozřejmě super invazivní, pokud si tam už něco sám nastavil.
Nicméně jak jsem předesílal, není to můj denní chleba. A konkrétně ten MS Edge vypadá, že je super agresivní v revertování nastavení, ignorování existujících politik a spousta věcí a jeho chování se mění mezi jeho různými buildy, aspoň co jsem slyšel. Takže jestli pak něco vydrží déle jak půl roku je otázka :)
O tom, jak vypadaji dodavky SW zjevne neraceji tusit vubec nic. Dodavatel doda blob, a tak jak ho dodal se to i musi pouzivat. Aktualizace typicky znamena ze se to po 10 letech vsechno nainstaluje znova. Tedy pokud dodavatel jeste existuje.
Ale samozřejmě že tuším.. proto jsem psal, že správce (resp. bezpečák) by měl zhodnotit riziko. Ať zůstaneme u tématu, asi bude rozdíl, jestli máte třeba starý Firefox a distribuci na serveru v nějakém izolovaném systému v segmentované síti s jasně danými přístupy a prostupy, nebo PDF.js v nějaké webové aplikaci/kontejneru, co přímo využívají třeba tísícovky uživatelů.
Nicméně rozhodně to není tak, že takovéhle peklo, co jste popsal, je vždycky. Chápu, že někdy řadový správce není nutně v nějakém rozhodovacím procesu, nemá nejspíš vliv na výši investic ani prostředků na rozvoj. Ale někdy ta potenciální frustrace může vést i k zásadnějším rozhodnutím, kdy si člověk vyhodnotí, že než zdegenderovat na takového toho strejdu Nejdeto, co akorát pi*uje v kantýně, a valí před sebou čím dál větší kuličku, tak u toho taky nemusí být a otevře se mu spousty dalších možností :)
Desne se to chova porad a typicky presne to, co lidi vazne potrebujou === vsemozny formulare, dotazniky a dalsi strasne dulezite chojoviny ... statni spravy, v tom nefungujou vubec.
Ale nejen to, v par poslednich mesicich sem nekolikrat resil, ze "to pdfko nejde vytisknout" a bylo to prave a vyhradne tim (v ruznych variantach, od toho ze to vubec neslo na tiskarnu poslat pres ze to tisklo prazdny papir po ze to tisklo cast objektu a dalsi cast ne).
Libovolnej svepravnej soft to samozrejme vytiskl bez problemu cele.
No jo, to bude konkurenční výhoda jak noha.
PDF je naprosto běžný formát na webu a když mi to nezobrazí aplikace rovnou (Firefox, Thunderbird), tak je to otrava. Stačí, když jdete na nějaký web, který nemá správně content-type nebo něco a PDF se po kliknutí uloží - pak to najít, otevřít, to je luxus.
Můžete si vybrat: na webu bude to, co prohlížeč umí, nebo prohlížeč bude umět to, co lidi na web dávají.
Můj první browser byl NCSA Mosaic, který uměl obrázky jen v BMP. Jsem rád, že prohlížeče poněkud pokročily a běžný obsah rovnou zobrazí, i když jen v náhledu.
Ale to je problem taky firefoxu a jeho systemu prace se stazenymi soubory (ktery mi nikdy nevyhovoval). Treba vivaldi nabizi dialog stahnout ci otevrit vzdy, nezavisle na tom co webova stranka tvrdi, a operacni system vidi ze samotny soubor zacina %PDF a otevre to prirazenym programem.
No a vzhledem k tomu, ze integrovany webovy prohlizec pdf je strasne nekomfortni, tak si kazde pdf otviram okularem z KDE.