abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    včera 01:11 | Nová verze

    Byl vydán Debian 13.6, tj. šestá opravná verze Debianu 13 s kódovým názvem Trixie a Debian 12.15, tj. poslední patnáctá opravná verze Debianu 12 s kódovým názvem Bookworm, k dispozici je LTS. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 a Debianu 12 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.

    Ladislav Hagara | Komentářů: 0
    10.7. 16:11 | Bezpečnostní upozornění

    V jádře Linux byla nalezena a v upstreamu již byla opravena kritická zranitelnost GhostLock aneb CVE-2026-43499. Lokálnímu uživateli umožňuje získat práva roota a také obejít kontejnerovou izolaci. Zranitelnost existovala v Linuxu 15 let, tj. od roku 2011, od Linuxu verze 2.6.39.

    Ladislav Hagara | Komentářů: 2
    10.7. 13:55 | IT novinky

    Evropská komise předběžně shledala, že návykový design aplikací Instagram a Facebook od americké společnosti Meta porušuje unijní nařízení o digitálních službách (DSA). Návykový design zahrnuje například takzvané nekonečné posouvání, automatické přehrávání videí, tzv. push notifikace, kdy aplikace uživatele vybízí k návratu do jejího prostředí, či vysoce personalizovaný algoritmus, který rychle pozná, co uživatele baví a snaží

    … více »
    Ladislav Hagara | Komentářů: 12
    10.7. 12:11 | Nová verze

    Byla vydána verze 1.97.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.

    Ladislav Hagara | Komentářů: 0
    10.7. 05:00 | IT novinky

    Švýcarská společnost Punkt. má nově v nabídce telefon Punkt. MC03. Telefon byl navržen ve Švýcarsku s důrazem na soukromí a digitální suverenitu a vyroben v Německu. V telefonu běží operační systém AphyOS (Apostrophy OS) založený na AOSP (Android Open Source Project) 15. Cena telefonu je 745 eur.

    Ladislav Hagara | Komentářů: 21
    10.7. 04:44 | Nová verze

    TypeScript (Wikipedie), tj. JavaScript rozšířený o statické typování a další atributy, byl vydán v nové verzi 7.0. Kompilátor byl kvůli výkonu přepsán z TypeScriptu do Go.

    Ladislav Hagara | Komentářů: 0
    9.7. 17:00 | IT novinky

    Europarlament podpořil pozměněnou verzi výjimky známé jako „chat control 1.0“ umožňující firmám skenovat soukromou komunikaci na internetu kvůli ochraně dětí před zneužitím. Pozměňovací návrhy přijaté europoslanci však počítají s tím, že z výjimky bude vyřazena šifrovaná komunikace. Výjimka přestala platit začátkem dubna poté, co se Evropský parlament a Rada EU nedokázaly shodnout na jejím prodloužení. Rada následně přijala

    … více »
    Ladislav Hagara | Komentářů: 12
    9.7. 04:44 | Bezpečnostní upozornění

    Nejnovější X.Org X server 21.1.24 a Xwayland 24.1.13 řeší 2 bezpečnostní chyby.

    Ladislav Hagara | Komentářů: 0
    9.7. 04:22 | Komunita

    Clement "Clem" Lefebvre publikoval souhrn dění v Linux Mintu za červen 2026. Vypíchnuta je vylepšená podpora Waylandu. Už není považována za experimentální. V příští verzi Linux Mintu, plánována je na Vánoce, bude běh Cinnamonu plně podporován na X11 i Waylandu. V květnu na vývoj Linux Mintu přispělo 611 dárců celkovou částkou 19 612 dolarů. Dalších 2 326 patronů přispělo na Patreonu celkovou částkou 5 334 dolarů.

    Ladislav Hagara | Komentářů: 4
    9.7. 04:00 | Bezpečnostní upozornění

    V Linuxu v KVM byla nalezena a v upstreamu již byla opravena kritická zranitelnost Januscape aneb CVE-2026-53359. Root na hostovaném počítači (virtuální stroj) může obejít izolaci a získat plnou kontrolu nad hostitelským systémem (DoS útok nebo vzdálené spuštění kódu s právy roota). Na obou hlavních architekturách – Intel i AMD. Zranitelnost v Linuxu existovala téměř 16 let (od srpna 2010 do června 2026).

    Ladislav Hagara | Komentářů: 0
    Které desktopové prostředí na Linuxu používáte?
     (10%)
     (7%)
     (2%)
     (17%)
     (31%)
     (4%)
     (6%)
     (2%)
     (16%)
     (25%)
    Celkem 2102 hlasů
     Komentářů: 30, poslední 3.4. 20:20
    Rozcestník


    Log4Shell: RCE v Apache Log4j 2 (CVE-2021-44228)

    Byly publikovány informace o kritické bezpečnostní chybě pojmenované Log4Shell (CVE-2021-44228) ve službě pro logování Apache Log4j 2. Jedná se o RCE (Remote Code Execution), tj. kdokoli může na vzdáleném serveru spouštět příkazy. Chyba je opravena v upstream verzi 2.15.0.

    11.12.2021 02:00 | Ladislav Hagara | Bezpečnostní upozornění


    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    xkucf03 avatar 11.12.2021 10:09 xkucf03 | skóre: 50 | blog: xkucf03
    Rozbalit Rozbalit vše Komplexita softwaru

    I takhle to může dopadnout, když si do programu zatáhnete dalších 280 000 řádků kódu, jen abyste měli „lepší“ logování, než je ve standardní knihovně…

    Dále se pak v programech vyskytují neúmyslné chyby, které lze použít k DoS útoku nebo třeba k eskalaci práv či vzdálenému spuštění kódu. Autor je tam nedal schválně, ale bezpečnostní riziko je to stejné. Komplexní software je jednak náchylnější ke vzniku takových chyb a jednak se v něm tyto chyby hůře hledají.

    Nicméně tuhle chybu lze (alespoň částečně) zažehnat vhodným nastavením firewallu, které by na produkčních serverech být mělo.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    11.12.2021 15:43 OldFrog {Ondra Nemecek} | skóre: 36 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: Komplexita softwaru
    abyste měli „lepší“ logování, než je ve standardní knihovně…

    Ve standardní knihovně - myslíte java.util.logging? Nevím, tam je mnoho nedostatků... SLF4J nebo Logback jsou lepší volby.
    -- OldFrog
    xkucf03 avatar 11.12.2021 15:58 xkucf03 | skóre: 50 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Komplexita softwaru

    Ano, myslím java.util.logging. Pokud nestačí, člověk si může implementovat vlastní Formatter nebo Handler, není to moc složité. Obecně, bez ohledu na jazyk, se snažím vystačit si se standardní knihovnou, co to jen jde, a další závislosti přidávat, až když to mám opravdu dobře zdůvodněné.

    Protože mám představu, kolik byznys logiky (hodně) obsahuje software o třeba 500 000 řádcích kódu, tak mi přijde dost nepřiměřené, aby 280 000 padlo jen na nějaké logování, což je pomocná vedlejší funkce.

    To množství kódu buď znamená, že je to psané hodně hloupě a neefektivně s mnoha duplicitami – což mi u Apachů přijde dost nepravděpodobné, protože tam bývá ta kvalita celkem slušná – nebo to znamená, že ta knihovna obsahuje mnoho funkcí, které nebudu potřebovat. A to je právě obrovský zbytečný prostor, ve kterém mohou být chyby. Statisticky vzato jsou chyby v každém softwaru a víceméně platí, že čím víc kódu, tím větší pravděpodobnost, že mě nějaká chyba ohrozí. Tlakem na kvalitu a různými kontrolními mechanismy se dá ta pravděpodobnost snížit – to je samozřejmě dobré dělat – ale často většího efektu dosáhnu tím, že snížím množství kódu, který vstupuje do hry.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    11.12.2021 19:39 OldFrog {Ondra Nemecek} | skóre: 36 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: Komplexita softwaru
    Jenže JUL má špatné API a chybí tam elementární věci. Je chybou, pokud si musí programátor ty elementární věci stále znovu doprogramovávat - je to i zbytečná práce navíc, výsledné řešení není standardizované, v implementaci mohou být chyby atd. atd. Ano, bohužel jsou ve standardní knihovně místa s hrozným API, příkladů je vícero. V této situaci je jasné, že vznikají knihovny, které to řeší. Ideálním řešením je kvalitnější návrh standardních knihoven s rozumným subsetem funkčností + externí závislosti, které tuto funkčnost rozšiřují či doplňují (nikoli nahrazují). Je to ideál, ke kterému se můžeme v nejlepším případě jen blížit...
    -- OldFrog
    11.12.2021 17:06 Cc
    Rozbalit Rozbalit vše Re: Komplexita softwaru
    Tu podľa mňa chyba nie je iba na strane log4j. Ich najväčšia chybe je podľa mňa template string injection aj v prípade, že skladám log message správne pomocou format stringu a parametrov. Ďalej áno, využívajú JNDI lookup bez zabezpečenia. Problém ale je, že *defaultne* je možné cez JNDI loadnuť remote untrusted kód a spustiť ho. Už sa to párkrát v Jave opravovalo, ale teraz sa zdá, že namiesto snahy o obecné riešenie problému sa vždy riešili konkrétne exploity. Efekt bol teda iba ten, že sa útočník musel trochu viac zamyslieť a exploit mierne upraviť. Ten problém je pritom známy roky.

    A tu si používaním JUL nepomôžete, JNDI máte na classpath štandardne. Jasné, možno ho nevyužívate, ale napadlo by vás pri pridávaní podpory, čo všetko je potrebné ošetriť, aby nedošlo k RCE?

    Inak používať knižnice versus vynaliezať znova koleso je na dlhšiu diskusiu.
    xkucf03 avatar 11.12.2021 17:27 xkucf03 | skóre: 50 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Komplexita softwaru
    Tu podľa mňa chyba nie je iba na strane log4j. Ich najväčšia chybe je podľa mňa template string injection aj v prípade, že skladám log message správne pomocou format stringu a parametrov.

    Ano a to je právě chyba na straně log4j. Pokud by to šlo jen skrze šablony zpráv, tak se dá říct, že to je vlastnost nikoli chyba – ty šablony má psát programátor a je to jeho odpovědnost, co do nich napíše. Ale pokud jde o parametry, k těm knihovna musí přistupovat obezřetně a nesmí je takto interpretovat.

    Když si programátor poslepuje logovanou zprávu pomocí "bla bla " + parametrOdPotenciálníhoÚtočníka, tak je to podobné SQL injection (což je chyba programátora, nikoli knihovny).

    Nicméně je pravda, že ve výchozím stavu bych očekával nějaké celkem bezpečné a blbuvzdorné nastavení – nebezpečné funkce by se měly zapínat až na vyžádání.

    Ďalej áno, využívajú JNDI lookup bez zabezpečenia. Problém ale je, že *defaultne* je možné cez JNDI loadnuť remote untrusted kód a spustiť ho. … JNDI máte na classpath štandardne.

    Tohle je vlastnost, funkce. Stejně tak tam mám třeba java.lang.Runtime.exec(), přes který můžu spustit libovolný příkaz, nebo javax.script.* API, přes které můžu spouštět skripty, nebo mám k dispozici kompilátor a reflexi…

    A tu si používaním JUL nepomôžete

    Pokud vím, tak v java.util.logging takto logované hodnoty zneužít a interpretovat nejde.

    Inak používať knižnice versus vynaliezať znova koleso je na dlhšiu diskusiu.

    Ano, o tom je mj. ten seriál článků (viz odkaz výše). Neexistuje jednoznačný recept, jestli jít jednou nebo druhou cestou, vždy je potřeba zvažovat ty poměry a hledat nějaké přiměřené řešení. Některé věci je lepší si napsat sám, i když při tom „vynalézám kolo“ a jinde je samozřejmost použít knihovnu. Dost taky pomáhá modulární návrh a vyšší granularita, kdy si mohu vybrat malé části (knihovny), které přepoužiji, aniž bych si zároveň zatáhl do systému spoustu nepotřebných funkcí. Na druhou stranu, kdyby to člověk hnal do extrému, tak převáží ta režie související se správou spousty malých závislostí, takže ani tohle není úplně černobílé. Pak se zase dostáváme k tomu, že něco si radši napíšu sám, než abych kvůli tomu závisel na knihovně, která má pár řádků.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    12.12.2021 18:24 Cc
    Rozbalit Rozbalit vše Re: Komplexita softwaru
    Ďalej áno, využívajú JNDI lookup bez zabezpečenia. Problém ale je, že *defaultne* je možné cez JNDI loadnuť remote untrusted kód a spustiť ho. … JNDI máte na classpath štandardne.

    Tohle je vlastnost, funkce. Stejně tak tam mám třeba java.lang.Runtime.exec(), přes který můžu spustit libovolný příkaz, nebo javax.script.* API, přes které můžu spouštět skripty, nebo mám k dispozici kompilátor a reflexi…

    A tu si používaním JUL nepomôžete

    Pokud vím, tak v java.util.logging takto logované hodnoty zneužít a interpretovat nejde.

    No chcel som poukázať na nasledujúce: písal ste o tom, ako si nepoužívaním log4j pomôžete od komplexity a tým pádom od chýb. Na príklade tejto chyby (nutnou podmienkou na exploit je chyba v log4j a zároveň problém v JNDI) je vidieť, že aj pri nulových externých zavislostiach už máte v projekte kód s komplexitou a chybami (aj keď bez použitia JNDI túto konkrétnu chybu nezprístupníte). To je ale zrejme osud každého netriviálneho SW.

    Inak zarazilo ma, že v oprave v log4j neriešili ten template string injection problém, ale iba začali opatrnejšie používať JNDI. Ak mi teda niečo neušlo.

    12.12.2021 14:50 sid
    Rozbalit Rozbalit vše Re: Komplexita softwaru
    I takhle to muze dopadnout ked niekto puse o niecom comu nerozumie.
    Jendа avatar 11.12.2021 16:24 Jendа | skóre: 78 | blog: Jenda | JO70FB
    Rozbalit Rozbalit vše Re: Log4Shell: RCE v Apache Log4j 2 (CVE-2021-44228)
    12.12.2021 12:19 trekker.dk | skóre: 72
    Rozbalit Rozbalit vše Re: Log4Shell: RCE v Apache Log4j 2 (CVE-2021-44228)
    This tweet aged like milk
    Quando omni flunkus moritati
    JiK avatar 11.12.2021 18:36 JiK | skóre: 13 | blog: Jirkoviny | Virginia
    Rozbalit Rozbalit vše Re: Log4Shell: RCE v Apache Log4j 2 (CVE-2021-44228)
    lighttpd a zadne logovani. nejsem fizl. sluzba, ktera neni, nejde exploitnout.
    14.12.2021 09:30 Xerces
    Rozbalit Rozbalit vše Re: Log4Shell: RCE v Apache Log4j 2 (CVE-2021-44228)
    Kolik bylo u vás hodin, když jste to psal? :-D

    Založit nové vláknoNahoru


    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.