Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »Francouzský výrobce kabelů Nexans upozornil na napjaté dodávky elektrických kabelů. Výstavba nové výrobní linky pro některé typy kabelů může trvat přibližně tři roky. Datacentra potřebují rozsáhlé nízkonapěťové a středněnapěťové rozvody. Poptávka roste současně s modernizací elektrických sítí. Někteří odběratelé proto uzavírají výrazně delší dodavatelské smlouvy [Reuters].
Představena byla (𝕏) virtuální platforma FLYBENCH FPV, která nováčky provede zapojením a konstrukcí dronů.
Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
V implementaci Broadcom 802.11 byla zjištěna chyba ve zpracování WPS/EAP, týká se to SDK od roku 2010. Broadcom podle výzkumníka Quentina Kaisera odmítl CVE přidělit. Modemy Huawei a Technicolor jsou používány i v ČR, v LTE routerech, běžných domácích routerech a firemních přístupových bodech, jejich současný počet a zranitelnost konkrétních verzí však zatím neznáme. Více detailů a demo. GitHub / Broadcom 802.11 SDK Detection Toolkit.
Byla vydána nová verze 10.8 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Přibyl balíček DietPi WireGuard.
Programming stuff. And stuff.
Ve všech zmíněných případech dizajn protokolu umožňoval kvůli nízké entropii, nebo kvůli rozdělení klíčového materiálu na malé části, které šly "bruteforcovat" mnohem snáze. Na mnohých routerech je pořád problém WPS vůbec vypnout (případ originálního firmware toho WRT320n).
Nedávno byl na abclinuxu popsán jeden postup pro Linksys E2000, čož je de facto stejný router jako WRT320n. Instalace byla překvapivě jednoduchá, není nutné flashovat přes TFTP jako u starších routerů (třeba Asus WL-500g). Jenže tam jednoduchost končí. Musím ale říct, že naposledy u toho Asusu jsem s dd-wrt takové problémy ani zdaleka neměl. U Asusu byl jen jeden - při WPA/WPA2 s TKIP se přehřál a vytuhnul, pokud se z Windows přes wifi z disku připojeného k USB Asusu kopírovalo sambou. Tam stačilo zakázat TKIP a použít AES.
Použil jsem build DD-WRT v24-sp2 (04/07/12) mega - build 18946M NEWD-2 K2.6 Eko, protože jsem chtěl 6to4, client VPN a pár dalších věcí - jinak na fórách lidi právě doporučují radši mini-buildy, prý méně bugovité. Nicméně ani mini-build by mi tady nepomohl, protože největší problém byl s GUI a wifi (základní věci).
Hlavní HW problémy jsou u WRT320n prý způsobeny tím, že je to piece-of-crap. Navíc již od výroby přetaktovaný z 300 MHz na 325 MHz (více o tom níže).
GUI bugy - při nastavování wifi mezi A/B/G/N občas chybí třeba nastavení kanálu, především když se přepíná mezi 2.4 a 5 GHz pásmy. Po změně pásma/protokolu se nezmění hned možnosti, třeba nevyskočí výběr kanálu. Většinou stačí dát "Save", pak už vyskočí další možnosti. Z "bruteforce debuggingu" mi přišlo, že některé věci, které byly původně nastaveny pro jiná pásma, "tajně ovlivňují" možnosti v aktuálně vybraném pásmu. Třeba při přepnutí mezi G a A vždy zmizely všechny kanály až na "Auto".
Workaround pro nastavování wifi a kanálů: fungovalo vybrat wifi N (ať už 2.4 nebo 5 GHz, dle toho co chceme nastavovat), Save, nastavit šířku pásma na 10 nebo 20 MHz, vybrat kanál, Save, Apply Settings. Pak nastavit co skutečně chceme - a kanály už tam jsou. Ale není to 100% - občas mi po restartu nastaví kanál 34 místo 36, který má v konfiguraci.
Při 2.4 GHz jsem žádný problém nezaznamenal, až na nastavení kanálu 14 - ten nepatří pod "CZ/EU" 2.4 GHz rozsah, takže ho notebook neviděl (možná to lze wifi driveru vysvětlit, pokud to není zadrátované v železe, ale neměl jsem čas to googlit).
Při 5 GHz dd-wrt rádo preferuje kanál 34 (při nastavení "Auto"), který je taky mimo "CZ/EU" pásmo, tudíž mi ho wifi karta nevidí. Hledal jsem jestli je v dd-wrt nastavení země, podle které by to nabízelo kanály, ale nenašel jsem. Horší je, že po restartu routeru to občas nastaví kanál 34 i když má v configu kanál 36 (zatím jsem viděl jenom u power-cycle restartu, normální SW restart vypadal ok).
Nijakým způsobem se mi nepovedlo rozchodit N-kovou wifi, ani na 2.4 GHz, ani na 5 GHz. Bylo úplně jedno, jaké jsem zvolil kanály, šířky pásem, atd. Nic. Zvláštní věc jsem si všimnul při 5 GHz - pokud byl druhý kanál vysoký (100 nebo 104), signál pro tento kanál byl úplně mizerný i když byl router 1 m od notebooku (ale nemám spektrální analyzér, takže důvodů může být více). Taky se mi nepovedlo "zchannelbondovat" v nastavení dva vedlejší kanály, třeba 36 a 40 (frekvenčně by to snad mělo sedět, dokopy by to dávalo akorát těch 40 MHz). Nicméně žádný testovaný z 20 MHz kanálu v 5 GHz N módu nešel ani sám, takže je to jedno.
Ve fórách psali, že po vypnutí WPA/WPA2 a volném prístupu to pak šlo, ale mít open wifi zatím není můj plán
Skutečně vypadalo, že N-ková wifi failuje na autentizaci, ale už jsem neměl po 6 hodinách sil to debugovat.
Router je od výroby přetaktován, ve fórách se doporučuje ho "normáltaktovat" a skutečně vypadá, že wifi je pak mnohem stabilnější (přes telnet, ssh, nebo i GUI command line):
nvram set clkfreq=300,150,75
nvram commit
reboot
Další nastavení, z kterých pár stabilitě pomohlo. Těžko už říct které, první dvě asi nejspíš:
I když návod vypadá celkem hnusně, byla to mnohem větší pohodička než celá wifikalypsa. Akorát jeden detail, v jejich startup skriptu mi ip -4 addr show dev vlan2 nedá žádný výstup, tak jsem startup skript upravil:
insmod /lib/modules/`uname -r`/kernel/net/ipv6/sit.ko
sleep 5
radvd -C /tmp/radvd.conf start
sleep 5
WANIP=$(ifconfig vlan2 | grep 'inet addr' | awk '{print $2}' | cut -d ':' -f 2)
if [ -n "$WANIP" ]
then
V6PREFIX=$(printf '2002:%02x%02x:%02x%02x' $(echo $WANIP | tr . ' '))
ip tunnel add tun6to4 mode sit ttl 255 remote any local $WANIP
ip link set tun6to4 mtu 1480
ip link set tun6to4 up
ip addr add $V6PREFIX:0::1/16 dev tun6to4
ip addr add $V6PREFIX:1::1/64 dev br0
ip -6 route add 2000::/3 via ::192.88.99.1 dev tun6to4
kill -HUP $(cat /var/run/radvd.pid)
fi
sleep 10
radvd -C /tmp/radvd.conf start
Nakonec se to úplně obrátilo. Věci co jsem myslel že budou jednoduché (nastavit wifi) se ukázaly jako peklo, a vice versa - 6to4 a další customizace byly celkem rychlé. Ale hlavně WPS je definitivně dead a vyhnu se dementním UPC routem alespoň u serverů s IPv6. "Re-routovat" IPv4 bude další krok.
Tiskni
Sdílej: