- A hozzászóláshoz be kell jelentkezni
- 1615 megtekintés
Hozzászólások
Ubuntu -> CVE-2023-6246 -> https://ubuntu.com/security/cves?q=&package=glibc
trey@alderaan:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.3 LTS"
ID | Priority | Package |
14.04 ESM |
16.04 ESM |
18.04 ESM |
20.04 LTS |
22.04 LTS |
23.10 |
24.04 LTS |
---|---|---|---|---|---|---|---|---|---|
CVE-2023-6780 |
medium |
glibc |
Does not exist |
Not vulnerable |
Not vulnerable |
Not vulnerable |
Not vulnerable |
Needed |
— |
CVE-2023-6779 |
medium |
glibc |
Does not exist |
Not vulnerable |
Not vulnerable |
Not vulnerable |
Not vulnerable |
Needed |
— |
CVE-2023-6246 |
medium |
glibc |
Does not exist |
Not vulnerable |
Not vulnerable |
Not vulnerable |
Not vulnerable |
Needed |
— |
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Fura hogy a 6246- re azt mondja hogy nem érintett/nem sebezehtő, miközben a szöveges leírásban az van hogy "All glibc versions from at least September 1992 (glibc 1.04) to the current release (glibc 2.38) are affected" - még akkor is ha a glibc team azt mondta hogy ezt a hívó fél hibája, nem az övék...
- A hozzászóláshoz be kell jelentkezni
Igen, irkálnak mindent össze-vissza. Utánanézve a syslog sérülékenység a 2.38-as glibc-t nem érinti, csak a qsort-os. A syslogosat ki is próbáltam a leírásban mutatott módszerrel, hibával leállt a jelszókérés (Authentication token manipulation error), de nem történt segfault és eszkaláció, most próbáltam ki Arch-on, ahol 2.38 van.
A qsort-os elvileg érinti a 2.38-at, de nem tudtam még tesztelni, mert max. csak a hétvégén lesz időm erre forráskódot pörgettyűzni. Bár szerintem addigra tuti kijön hozzá a javítás.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Lám, pont az van, amit jósoltam, mostanra csorog is le Arch-on a glibc 2.39. Nem sok idő volt arra, hogy ezt a sérülékenységet kihasználják. A MS-nál egy ilyen kaliberű javításra min. 1 hónapot kell várni, de reálisan legtöbbször annak is a többszöröse.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Nem sok idő? Mióta vannak jelen ezek a sec bugok? Ne csak a publikálás és a javítás közti ablakot nézd
- A hozzászóláshoz be kell jelentkezni
De, azt nézem, mert korábban feltételezhető, hogy senki nem tudott róla. Ez persze csak feltételezés, mert elméletileg tudhatott, és ki is használhatták, de ez nem szokott életszerű lenni. Ha valóban régóta létező gond lenne, már rég hírek érkeztek volna egy csomó felnyomott szerverről.
Amúgy meg kár ezen idegeskedni, ilyen sechole-ok minden szoftverben vannak szinte. A lényeg, hogy a publikálástól számítva ne teljen el sok idő, mert akkor tényleg bárki kihasználhatja.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Illúziókban ringatod magad, olyan érzésem van. Igaziból csak arra szerettem volna rávilágítani, hogy _kb._ felesleges epéniszt lengetni, hogy publikálás után mennyi idő alatt van fix.
- A hozzászóláshoz be kell jelentkezni
Nem, mert a publikálás mindenkinek lehetőséget jelent a kihasználására, tehát onnantól kezdve gyorsan meg kell oldani.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Igen, előtte meg x hónapig/évig használhatták ki, akik üzletet is építhettek rá. Publikálás után meg rárepülnek a script kiddiek. Nyilván jó ha hamar javítva van az ismert hiba, de azért túl nagy örömködésre nem ad okot szerintem.
Szerk.: a 6246-es bug a glibc 2.37-el jelent meg 2022 augusztusában, amit backportoltak a 2.36-ba is. 2024 január végén publikálják, február elején a főbb disztrók javítják. Legrosszabb esetben 17 hónapig lyukas volt emiatt az adott rendszer, nyilván attól függ, hogy az érintett disztró a bugos releaseket mikor kezdte szállítani.
Tehát ja, tök szép, hogy pár nap alatt javítva van az ismert hiba, viszont a másik oldalon egy akár 17 hónapig lyukas rendszer van.
- A hozzászóláshoz be kell jelentkezni
Nagyon leegyszerűsítve, akkor publikálják a sérülékenységet, amikor mindenki megvan a javítással.
Lefejlesztette, letesztelte, CDN-be betárazta. Ez egy koordinált erőfeszítés.
- A hozzászóláshoz be kell jelentkezni
Akkor nincs baj. Illetve egy hézag, ha néhányan késnek a frissítéssel.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
unprivileged user to gain full root access
Én csak azt a részét nem értem, hogy egy libc-ben mégis milyen kód teheti ezt egyáltalán lehetővé... Mármint a libc-nek annyi dolga van, hogy felhasználói címtérben ügyködjön, néha-néha megeresszen egy sysctl-t. Normális esetben max. a sysctl hibájából lehetne privilege escalation-re használni, na de semmiképp sem a libc kód hibájából...
Ezek integrálták a komplett sudo-t a glibc-be, vagy mi a f*? Számos oka van, hogy a glibc szar (funkcióverziózás pl.), na de hogy olyan kódot is tartalmaz, ami ezt lehetővé teszi, azért az már elég durva tervezési hiba.
Na, megvan:
For the first vulnerability (CVE-2023-6246), a significant security flaw has been identified in the GNU C Library’s __vsyslog_internal() function, affecting syslog() and vsyslog(). This heap-based buffer overflow vulnerability was inadvertently introduced in glibc 2.37 (August 2022) and subsequently backported to glibc 2.36 while addressing a different, less severe vulnerability (CVE-2022-39046). Major Linux distributions like Debian (versions 12 and 13), Ubuntu (23.04 and 23.10), and Fedora (37 to 39) are confirmed to be vulnerable. This flaw allows local privilege escalation, enabling an unprivileged user to gain full root access, as demonstrated in Fedora 38.
Hát itt eleve az a baj, hogy __vsyslog_internal() funkciónak minek kell root privilege ugye, a heap overflow már csak hab a tortán. Normál esetben a libc-nek egy UNIX socket-en keresztül kéne küldeni az üzeneteket a syslog daemon-nak, és akkor nem is létezhetne ez a bug, nemdebár.
- A hozzászóláshoz be kell jelentkezni
ha van egy binary ami suid-es, de csak adott dolgot tudsz vele csinalni (mondjuk umount parancs), es ha megfeleloen meghivodik az a fuggveny akkor nem a syslogba kerul valami uzenet hanem a root shelled kapod meg.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Na de itt nem erről van szó. Az tök más, ha egy program suid-os (tehát eleve root privilege-l rendelkezik és úgy fut), csak épp másra veszed rá, mint amit csinálnia kéne; na az nem "privilege escalation", mint itt.
A leírásban sem szerepel, hogy kéne a kihasználáshoz suid, csak hosszú paramétereket emlegetnek csupán:
Although the vulnerability requires specific conditions to be exploited (such as an unusually long argv[0] or openlog() ident argument), its impact is significant due to the widespread use of the affected library.
- A hozzászóláshoz be kell jelentkezni
Pedig de, az exploit is su-t hasznal.
- A hozzászóláshoz be kell jelentkezni
Egy másik (hírhedten anti-opensource), magyar nyelvű szakmai portálon úgy jött le ez a hír, hogy a hiba a Linux-ban van.
Most akkor nem tudom kinek higgyek :D
- A hozzászóláshoz be kell jelentkezni
Sting elfogulatlan hozzáértése?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Sose értettem azt az embert. Minek a Windowst védeni, ami nem szorul rá. Még azt is megértem, hogy a FOSS-t meg a Linuxot utálja, mert párszor kudarcot vallott vele, de hadjáratba kezdeni ellene?
Amúgy pedig vannak kint a pcforum-on érdekes hírek, sudo-t kap a Windows, illetve régi procikon (Core 2 és korabeli Athlonok) a Win10-es beépített programok elkezdtek egy frissítés után nem futni, vélhetőleg a MS véletlenül benne hagyta a C++ runtime-ban az SSE 4.2-őt a fordításnál. A redditen, YouTube-on meg az volt a nagy dobás a múlt héten, hogy valaki újra felfedezett egy régi, 10 éve nem fejlesztett, Object Pascalban írt, WinXP-t utánzó asztali környezetet, az XPde-t. Csodálkozok is, hogy trey ezeket nem teszi ki hírbe.
A hozzászólások viszont sok esetben nagyon színvonaltalanok azon az oldalon, pl. most olvastam egy fórumtémát, hogy 7. genes inteles i7-es laptopon a Win10 miért lassú 5400 rpm-es HDD-vel. Már messziről ordít, hogy a HDD miatt, erre a sok hülye ragozza 2 oldalon át, hogy biztos a hűtés, meg régi, elavult a proci, és rosszul van telepítve a Java (???), 32 bitesre a 64 bites rendszeren!!! Kellett várni több napot, a 2. oldal végére, 3. kommentoldal elejére, mire jöttek értelmesebb kommentelők, akik azonnal kiszúrták, hogy SSD kell bele. Másik fura komment ugyanott, hogy 1 évet húzzon ki a kérdező a lassú géppel, szenvedjen csak, 2025-ben meg váltson Linux Lite-ra. Okés, Linux, persze, de minek várjon vele akkor egy évet a Win10 support végéig, mikor SSD-ket lehet már kapni pendrive árában is, meg Linuxra azonnal lehetne váltani? Meg miért csak Linux Lite jön szóba? Utóbbival semmi baj nincs, csak túl specifikusnak tűnik, hogy csak az lehet.
Ami még gáz azon az oldalon, hogy minden nagyon izzadtságszagúan kényszermagyarítva van. Pl. glibc-t könyvtárnak nevezi, de könyvtáron én mappát értek. Persze a library is könyvtár, értem hogy érti, de ebben a jelentésében inkább függvénytár, rutingyűjtemény, vagy akármi másnak magyarítanám, amit amúgy kerülnék, nem nagyon volt dolgom már nagyon rég ilyen kényszermagyarított infós szövegekkel. Másik cikkben a Linux kernelbe kerülő drivert meghajtónak nevezi, amire én meg adattárolóra asszociálok. Igen, elmegy, de erőltetett, ezt én meghajtóprogramak, illesztőprogramnak nevezném, meg szakmai oldalon nem értem miért kell ezeket ennyire kényszermagyarítani, ennyi erővel akkor a pendrive-ot is hívja tollhajtánynak, a szkennert mert letapogatónak. Ezek az ősmagyarkodó kifejezések halálra idegesítenek Sting cikkeiben. 80-as, kora 90-es években kiadott ismeretterjesztő számtechkönyvekben voltak ezek a már akkor elavult kifejezések ennyire túlerőltetve.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
SSD-t mondjuk pont most faszság venni, mikor reggeltől délig emelnek 5-10%-ot az árakon, tavaly ősz óta nagyon abnormális árai lettek az összes SSD-nek. Mert faszkalap samsung-ék benyögték h. túl olcsó volt eddig minden ssd, túl sokat gyártottak, túl nagy raktárkészlet van. Na akkor mostantól behúzák a féket. Ez pedig automatikusan felverte az árakat szeptemberre-októberre. Azóta meg csak tovább emelkedtek. Megvolt a karácsony, a blekkfrájdéj, akit be lehetett húzni csőbe azok mind vettek, ideje lenne visszaállnia az áraknak az abnormális előtti szintre.
- A hozzászóláshoz be kell jelentkezni