Heti Linux sebezhetőség 

This is an announcement of CVE-2017-2636, which is a race condition in
the n_hdlc Linux kernel driver (drivers/tty/n_hdlc.c). It can be exploited
to gain a local privilege escalation.

The bug was introduced on 22 June 2009:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=be10eb7589337e5defbe214dae038a53dd21add8

I will publish my PoC exploit later, giving people some time to update
their systems.

I've found this bug investigating a suspicious kernel crash made by syzkaller

( log69 | 2017. 03. 07., k – 20:43 )

Más driver-ekben is lehetnek még százszámra ilyenek gondolom.. Gyakorlatilag a driver fejlesztő simán bevihet bármikor súlyos hibákat, főleg ha nem tudja minőség-biztosítani a kernel csapat.

Elgondolkodtató hogy mennyire ellene dolgozik a bonyolultság a biztonságnak és az elrobbant komplexitás miatt gyakorlatilag nem is lehet kivitelezni, még elfogadható szinten sem.

Ja hát igazából az is probléma, hogy nincsenek szabványok, legalábbis megfelelő mértékben. Adott szint alatt és felett mindenki eltér úgy ahogy akar és így nehéz kényszeríteni például a hardver gyártókat, hogy a kommunikációs protokollok azonosak legyenek és így ne legyen ilyen heterogén és káosz szintű az illesztés területe, és akkor nem kellene minden apró cseprő cuccra külön drivert írni nulláról (vagy ha nem is nulláról, akkor is).

Csak hát ugye a fejlődés meg arról szól, hogy eltérünk az addigitól. Illetve a piacverseny sem szolgálja a szabványt.

A szabványosításokra érdemes lenne koncentrálni. Adott, - bár szigorúbb keretek között, - de biztonságosabb és eredményesebb lenne a fejlesztőmunka. Az végeredmény, meg kevesebb bosszankodás.

Azért marhára nem ok, hogy lassan már húsz éve, szívunk, majd minden oprendszeren, a megjelenítés-felbontás problémával, - és ez megoldás helyett, csak tovább "színesedik" az ultramagas felbontás-megjelenítés, meg nem jeleníthetőségével...!

Ha minden hardvergyártó csak szabványkövető eszközt gyártana, akkor először meg kéne várni, hogy mi lesz a szabvány, és csak azután lehetne bármit is nekiállni implementálni.
Azt ugye tudod, hogy ez más iparágakban sem így megy?
Hanem úgy, hogy 1-1 (vagy pár) termelő/fejlesztő csinál egy terméket, amiből később szabvány lesz. Így működik a világ. A gyártók által képviselt szabványügyi szervezet szabványosítja a meglévő megoldást, hogy azt mások pontosan reprodukálni tudják.

Szóval úgy megy ez, hogy:
1. Egyik cég kitalál valamit
2. Több cég át szeretné venni, mert a piacnak ez jó
3. Összefognak és szabványosítják a dolgot.
4. A szabvány alapján implementálnak dolgokat.

Ha azt írnánk elő, hogy csak a szabványoknak megfelelő hardver legyen, akkor előbb kéne megvárni, hogy legyen szabvány - no de mi alapján legyen szabvány?

Nézd meg például a Vulkan API vagy az OpenGL esetét. Mindkét esetben egy már meglévő megoldásra (AMD illetve SGI termékre) alapulva hozták létre a szabványos grafikus API-t.

Szerintem itt csak hibas szohasznalattal allunk szemben. Nem is feltetlen szabvanyokra lenne szukseg, hanem egysegesitesre, hogy amikor kijon egy uj monitor, egy ugy wifi chipset, egy uj ethernet kartya, egy uj barakami, akkor valami alap szinten barmilyen drive el tudja kezelni, es csak az eszkozspecifikus/extra/specialis funkciokhoz kelljen esetleg plusz valami illesztek.
--
Blog | @hron84
Üzemeltető macik

"akkor valami alap szinten barmilyen drive el tudja kezelni, es csak az eszkozspecifikus/extra/specialis funkciokhoz kelljen esetleg plusz valami illesztek."
Ez pedig nem más, mint szabvány. Mint például az USB-nél vannak device classok, és mondjuk minden USB Mass Storage device class-t képes egy driver kezelni.
Általánosan PCI-express felületen szerintem ilyen nincs. Azaz hiába kötsz egy PCI-Express buszra egy Ethernet vezérlőt, nincs olyan, hogy "Ethernet Device Class", mert a PCI-Express buszrendszer ezt nem ismeri. De aki jobban ért PCI-Express buszrendszerhez, az esetleg meg tudná mondani, hogy ott létezik-e olyan fogalom, mint USB-nél a device class.

Update:
bocs, létezik ilyen.
http://pci-ids.ucw.cz/read/PD
Ezek a device classok vannak.
És mondjuk például a GPU-knál van VESA mód, ergya minőségben meg tud hajtani minden GPU-t alapban a generikus driver.

Igazad van, abban az értelemben hibás a szóhasználat, hogy minden hardvergyártó "szabványosít" mindent, őrült káoszt szabadítva a szoftveres világra. (Nos, én olyan jogi jellegű szabályozásra gondoltam, amely szankcionálná ezt a méltatlan, folyamatosan áradó, félig vagy még félig sem kész technológiai özönvizet. Senkinek nem kell feltalálni, marketinges előnyök, meg licencdij kerülések okán, a spanyolviaszt. Vannak az operációs rendszereknek szabványosított interfészei, tessék a hardvereket azok figyelembevételével fejleszteni. (Különben bünti.)

A szabványosítás jelenlegi formában mindenre jó, csak átgondolt fejlesztőmunkát segíteni nem. Azaz semmi mással csak önmagával "szabványos" megoldásokat jelent. A nagy gyártók elfelejtették, mi is a szabvány jelentése valójában.

"Vannak az operációs rendszereknek szabványosított interfészei, tessék a hardvereket azok figyelembevételével fejleszteni"
Milyen szabványosított interfész van device driverekre? Megsúgom: nincs ilyen. A device driver nem userspace. És a POSIX az csak userspace dolgokat ír elő.

"A nagy gyártók elfelejtették, mi is a szabvány jelentése valójában."
Dehogy felejtik el. Mindig egy meglévő, gyártó által elkészített dologból lesz szabvány, azért, mert a többi gyártó is követni akarja azt a megoldást, mert bevált.
Ilyen például az USB, a FireWire vagy akár az ISA vagy AGP is. Egyik illesztőfelület sem egy design-by-committee eredménye, hanem egy-egy gyártó kitalálta, és az terjedt el.
Aztán később a gyártók által grundolt szervezetek szabványosították, hogy minden gyártó ugyanazt értse AGP vagy ATX vagy PCI-Express alatt.

Szerintem te nem érted, hogy hogyan működik a szabványosítás folyamata.

Van egy két usb-s wifi adapterem, egyik azonnal ment ubuntuval, másikhoz kézzel kellett hekkelgetni valamit. Lehet én userként messziről nézem ezeket a dolgokat, de miért nem egységes az oprendszer és a hardver közti kommunikáció? Mi a különbség ami ténylegesen indokolttá teszi, hogy egyéni driver kelljen az egyikhez és a másikhoz ahelyett, hogy létezne egy általános driver ezen ezköztípusra?

" de miért nem egységes az oprendszer és a hardver közti kommunikáció?"
Nincs olyan, hogy AZ oprendszer. Van egy csomó operációs rendszer, amelyek mindegyike más-más driver modellt követ.

"Mi a különbség ami ténylegesen indokolttá teszi, hogy egyéni driver kelljen az egyikhez és a másikhoz ahelyett, hogy létezne egy általános driver ezen ezköztípusra?"
http://www.usb.org/developers/docs/devclass_docs/
Az, hogy nincs olyan device class, hogy Wireless network adapter.
Olyan van, hogy Communications Device Class. Ami ezt írja le:
The specification currently outlines the common elements needed to support the following types
of devices:
• Telecommunications devices: analog modems, ISDN terminal adapters, digital telephones, and
analog telephones
• Networking devices: ADSL modems, cable modems, 10BASE-T Ethernet adapters/hubs, and
“Ethernet” cross-over cables.

Ezért nincs egységes WiFi driver. Mert a szabvány nem tér ki arra, hogy USB-n hogyan kell a WiFi eszközöknek kommunikálnia.

Sajnálatos, hogy így van. Fentebb arról volt szó, hogy egyik gyártó kitalál valamit, a többiek meg megpróbálják követni, és ebből lesznek szabványok.

Írtad is példának az USB-t, Firewire-t, stb.

A probléma továbbra is az, hogy ettől függetlenül minden eszközhöz kapod a drivert vindózra a jellemzően bloat segédprogramokkal, linux alatt pedig szívsz, és csak reménykedsz a normális támogatásban.

A wifi eszközt csak azért írtam, mert tök jó példa a jelenségre. Messziről nézve kábé ugyanazt csinálja mindegyik. Van amelyik ismer gyorsabb szabványt, van amelyik támogat speciális lehetőségeket, de alapjában véve az alapfunkciók ugyanazok, és semmi nem indokolja, hogy ezek ne legyenek hardver szinten egységesen kezelve, hogy az oprendszernek (akármelyiknek) vagy a drivereknek ennek az elfedésével kelljen foglalkoznia, és végeredményképp az usernek ne kelljen mellőznie az eszköz használatát nem támogatott oprendszeren. Eleve ne létezzen az a jelenség, hogy a gyártónak kelljen driverekkel támogatnia egy platformot, ha nem muszáj.

"Van amelyik ismer gyorsabb szabványt, van amelyik támogat speciális lehetőségeket, de alapjában véve az alapfunkciók ugyanazok, és semmi nem indokolja, hogy ezek ne legyenek hardver szinten egységesen kezelve, hogy az oprendszernek (akármelyiknek) vagy a drivereknek ennek az elfedésével kelljen foglalkoznia, és végeredményképp az usernek ne kelljen mellőznie az eszköz használatát nem támogatott oprendszeren. "

Az, hogy valami felhasználói oldalról csak annyi, hogy "scan -> SSID kiválaszt -> jelszó megad -> örül", attól még hardver oldalon ez sokkal bonyolultabb lehet. Nézd meg eleve a 802.11 szabványrendszert, nem éppen 3 oldal a leírás.
És ugye egy szabványos eszköznek minden, a szabványban előírt dolgot támogatnia kell. Az, hogy ez az OS és végül a felhasználó felé csak a fent leírt 4 lépést jelentse (bár az OS felé többet, hiszen a jelszóparamétereket meg egyéb más dolgokat az OS felé tudnia kell jeleznie a hardvernek, a felhasználó egy csomó mindenről nem tud, ami technikai részlet), ahhoz kell pont a driver tudása.
Azonban mivel NINCS szabvány, hogy az egyes buszokon hogyan kell a 802.11 szabványnak megfelelő adatokat továbbítani, épp emiatt kell driver.
A buszok szabványosítóinál lehet picsogni, azaz az USB IF-nél meg a PCI Special Interest Groupnál, hogy szabványosítsák ezt a protokollt.

"Eleve ne létezzen az a jelenség, hogy a gyártónak kelljen driverekkel támogatnia egy platformot, ha nem muszáj."
Amíg a busz szabvány olyan, amilyen, sajnos ez így fog maradni.

De amúgy ellenindoklás: a busz szabvány leírja, hogy miként lehet device discovery tenni a buszon lévő eszközökhöz (másnéven enumeration ez), meg leírja, hogy miként lehet általánosan adatot cserélni a buszon.
Miért kéne leírnia a szabványnak azt, hogy az összes lehetséges eszköztípus esetén miként kell kommunikálni?
Akkor a buszrendszer szabványnak ismernie kéne az összes lehetséges eszköztípus összes lehetséges szabványát.
Példa: az USB szabványnak ismernie kéne a 802.11 szabványrendszer összes lehetséges logikai paraméterét és üzenettípusát, majd leírnia, hogy azt miként kell az USB buszon keresztül kommunikálni.
Ezt azért te sem gondolhatod komolyan.

Nem feltetlenul a busz szabvanyanak kell leirnia ezeket. Engem az sem erdekel, ha ez egy common sense a gyartok kozott, hogy marpedig a wifit igy kommunikaljuk. Sot, tudod mit, engem az se erdekel, ha ebbol vilagvallast csinal valaki, csak ne kelljen minden gyarto szaraval egyedileg szivni.
--
Blog | @hron84
Üzemeltető macik

"ha ez egy common sense a gyartok kozott, hogy marpedig a wifit igy kommunikaljuk."
Ezt hívják szabványnak.
Sok-sok gyártó összeül, megegyeznek, hogy "márpedig a wifit így kommunikáljuk", ebből készül egy hivatalos technikai dokumentum, amit elfogadnak és szabványnak hívnak.

" a tobbi gyarto utanakullog"
Ez az a lepes az, amikor a sok gyarto osszeul.

Egy termeket, protokollt, barmit mindenkeppen egy entitas (ceg, csoport vagy szemely) kezd el csinalni.
Igy volt ez a UNIX-nal, igy volt ez az Ethernetnel, igy volt ez a PC-nel.
Meg a Linux disztroknal is igy volt ez.
Aztan amikor masok kompatibilisek akartak lenni masnak a termekevel, akkor kezdodott a szabvanyositas.
Aztan lett POSIX, lett IEEE 802.3, igy lett Linux Standards Base, stb.

Igy mukodnek a szabvanyok. Jo reggelt.

A szabványok úgy működnek, hogy a máig nincs egy egységes driver linuxra amivel kábé mindegyik wifi kártya alap szinten tudna működni :) Pedig wifi adapterek azért vannak már egy ideje.

Amúgy érthető amit mondasz, csak te az elméletet mondod, ami a gyakorlatban néhány esetben nagyon jól működik, más esetben viszont továbbra is extra szívás.

Pedig jobb lenne, ha inkabb ugy keszulnenek, hogy elore osszeulnek a gyartok, es kialakitanak a szabvanyt, meg mielott fragmentalodik a piac.

Marmint, az lenne a jo, ha alapertelmezeskent mindenki szabvanyositasra torekedne, nem pedig egyeni protokollokat fejlesztene. Mert amit mondasz, az nagyon szepen hangzik elmeletben, a gyakorlat azonban egy hatalmas nagy kaosz, es meg mindig nem latom, hogy ebbol mikor lesz rend. Kb. sohanapjan.
--
Blog | @hron84
Üzemeltető macik

"Pedig jobb lenne, ha inkabb ugy keszulnenek, hogy elore osszeulnek a gyartok, es kialakitanak a szabvanyt, meg mielott fragmentalodik a piac."
Ez egyik gyartonak sem erdeke. Mindenki a sajat fejleszteset akarja lenyomni a masik ceg (meg a userek) torkan, mint szabvanyt, mert akkor neki jar a szabadalmak utani bevetel.
Gondolj bele, a Nokia (Microsoft), a Motorola (Google) es hasonlo cegek bevetelenek nagy resze a GSM/LTE szabvanyok mas altali kovetesebol eredo szabadalmi bevetel. Es megis mukodnek a telefonok.
Vagy eppen ott az Mp3, ami utan a Franhufer intezetnek kell fizetni a licencet. Es megis mukodik a zenehallgatas. Pedig ez is ceges talalmany.
Jo reggelt.
Ceges talalmany a 3 pontos biztonsagi ov, a Volvo talalta ki, csak eppen royalty nelkul adta a vilagnak. Ceges talalmany, amibol szabvany lett.
Ceges talalmany az X86 utasitaskeszlet meg az ARM utasitaskeszlet is, aztan mindkettore tobb ceg csinal termeket.
Ceges talalmany a lampak E27-es foglalata, Edison talalta ki, megis szabvany.
Ceges talalmany az SQL, az IBM talalta ki. Aztan megis szabvany lett.
Ceges talalmany az ISA bus, az IBM talalta ki. Aztan megis szabvany lett a PC-ken.
Ceges talalmany a VHS, a JVC talalta ki, aztan megnyerte a formatumhaborut es szabvany lett.
Ceges talalmany a CD, a Philips talalta ki, aztan szabvany lett.
Ceges talalmany a Bluray, a Sony talalta ki, aztan szabvany lett.
Rengeteg, rengeteg esetet lehet sorolni, igy mukodik a szabvanyositas.
Nagyon-nagyon keves esetben mukodik az, hogy egy gyartoi szovetseg talal ki egy szabvanyt, ez a kivetel. Van ilyen, de ez a kivetel.

( szegecs | 2017. 03. 08., sze – 09:11 )

meg mindig nem kell a stable 2.4hez nyulnom, pedig itt a hupkon mar megmondtak az unstable 2.6-4.0 fanok hogy abbanisbiztosvan;(