☰

» »

Tuz ma vas rad

Tuz ma vas rad

denial ::

copy/paste from teh interwebs = ON
Linux kernel patch 2.6.29.1 fixes remote buffer overflow condition in SMB. Of course - no advisory as to Linus "we don't notify anybody" - what an irresponsible bunch of cowards!
copy/paste from teh interwebs = OFF

Info (in German):
fefe.de

Kernel team note:
CIFS: Fix memory overwrite when saving nativeFileSystem field during mount.

CIFS can allocate a few bytes to little for the nativeFileSystem field during tree connect response processing during mount. This can result
in a "Redzone overwritten" message to be logged.

Can anybody spot attempt to downgrade security risk?

Fuck advisories anyway, we don't have time for dumb child games. Check our new kernel logo instead.

SELECT finger FROM hand WHERE id=3;
  • spremenil: denial ()

jype ::

Dobr da nimamo SMB na interwebs odprt :)

fiction ::

CIFS: Fix memory overwrite when saving nativeFileSystem field during mount

upstream commit: b363b3304bcf68c4541683b2eff70b29f0446a5b

CIFS can allocate a few bytes to little for the nativeFileSystem field
during tree connect response processing during mount. This can result
in a "Redzone overwritten" message to be logged.

Signed-off-by: Sridhar Vinay <vinaysridhar@in.ibm.com>
Acked-by: Shirish Pargaonkar <shirishp@us.ibm.com>
CC: Stable <stable@kernel.org>
Signed-off-by: Steve French <sfrench@us.ibm.com>
[chrisw: minor backport to CHANGES file]
Signed-off-by: Chris Wright <chrisw@sous-sol.org>


NativeFileSystem (variable): The name of the file system on the local resource that is being connected to. If
SMB_FLAGS2_UNICODE is set in the Flags2 field of the SMB header of the response, this value MUST be a null-terminated
string of Unicode characters. Otherwise, this field MUST be a null-terminated string of ASCII characters. For resources
that are not backed by a file system, such as the IPC$ share used for named pipes, this field MUST be set to a single null
character.

V bistvu gre za tipicen ASCII character (1 bajt) vs. UNICODE character (2 bajta) problem. Alociras length + 2 bajta za
tcon->nativeFileSystem potem pa hoces noter dat length + 1 znake. Se slisi kul, razen tega, da cifs_strfromUCS_le() pretvori vse skupaj v unicode verzijo in tako vsak znak porabi 2 bajta pa pride do overflowa. Kolikor jaz to razumem
je to problem za clienta, ce se poveze na zlonamerni streznik in nekaj mounta. Druga stvar je kako exploitable je
vse skupaj. Cisto mogoce je, da me kdo preseneti s kaksno elite PoC kodo, ampak tako na prvi pogled bi rekel, da je
problem precej tezko izkoristiti. V userspacu z Doug Lea malloc-om in zadnjim libc-jem, ki ima precej checkov je
heap overflow prakticno nemogoce izkoristiti s prepisom kontrolnih struktur. Tukaj gre za neke vrste "kernel heap overflow" in izgleda kot da ima kmalloc() tudi neke sanity checke (ali kaj je tisti Redzone overwritten)?

Se strinjam, da ni lepo, da popravka niso oznacili kot "security fix", ampak ni pa spet tako, da bi hoteli issue v celoti zakriti. Mogoce so ravnali v dobri veri, da problem na noben nacin ni exploitable in niso hoteli po nepotrebnem zganjati panike. Za nazaj se lahko marsikateri bug izkaze kot relevanten za varnost. Je pa tudi obratno res: ni nujno da je vsak
buffer overflow kriticna stvar.

Kar se tice Tuza (malce offtopic): Ja, ugly as hell. Ampak vseeno je zanimiv nacin za pomoc pri ohranitvi ogrozene tasmanske zverinice.

Daedalus ::

Uff, hvala za dodatno pojasnilo. Ker ko sem bral on prvi post je bil sam en tak WTF nad glavo... nismo vsi kernel haxorji, prvi post pa ni bil hudo informativen.
Man is condemned to be free; because once thrown into the world,
he is responsible for everything he does.
[J.P.Sartre]

denial ::

nismo vsi kernel haxorji, prvi post pa ni bil hudo informativen.


Še enkrat poglej kaj piše pod kernel team note v prvem postu. Got it? Linus je mnenja, da je to čist dovolj informacij.
SELECT finger FROM hand WHERE id=3;

fiction ::

Še enkrat poglej kaj piše pod kernel team note v prvem postu. Got it? Linus je mnenja, da je to čist dovolj informacij.
Kje je tam tocno omenjen Linus Torvalds? Linus != Linux. Res je, da tip se vedno bedi nad projektom in je maintainer za 2.6 vejo, ampak sigurno pa ni tako da bi sel za vsak commit preverjati, ce je slucajno kaj relevantnega glede varnosti; ce ne drugega je tukaj dala druga oseba svoj "OK". Po tej logiki bi lahko rekel tudi: zlobnezi z IBM so hoteli vse skupaj prikriti. Sicer pa se vedno mislim, da je bila ideja odprava warninga in sploh niso sli gledati z varnostnega stalisca oz. so bili prepricani, da se tega itak ne da exploitati. Seveda nic ni 100%, ampak ce ze, je tole precej tezko exploitable. Vem, da se je ze dogajalo to, ko so hoteli downplayati varnostne ranljivosti, ampak v tem primeru se mi ne zdi da gre za kaj takega. Hype glede tega je torej povsem odvec. Ko smo ravno pri tem, tudi OpenBSD je precejkrat "degrardiral" varnostne ranljivosti, samo zato da jim ne bi bilo treba povecati counterja na glavni strani. Kar nekaj remote memory corruption issuejev so proglasili za DoS, ker jim nobeden ni prikazal delujocega exploita. Po njihovi logiki, ce lahko nekdo od zunaj s samo enim paketom zablokira masino, to ni "remote hole". Je pa najbrz Theo precej bolj "diktatorski" kot Linus in osebno mislim, da pri OpenBSD vecina stvari poteka tako kot Theo rece, medtem ko je pri Linux jedru, Linus bolj kot ne samo "maskota".

denial ::

Pred časom se je Linus zelo jasno izrazil kaj si misli o security folku, varnostnih opozorilih in še čem. Nekje na tem forumu je celo potekala debata.

Jep, every OS has its skeletons in the closet. To sploh ni hype. To je dejstvo.

Linus = Linux? Tega nisem rekel. Pravim samo Linus = Linux kernel. Čeprav da, there's kernel team too.
SELECT finger FROM hand WHERE id=3;

Daedalus ::

Ah joj, a še vedno nisi prebolel onega Linusovega nabijanja o bsd folku:) Pač, tip je tak genij, da mu na trenutke konkretno škodi.
Man is condemned to be free; because once thrown into the world,
he is responsible for everything he does.
[J.P.Sartre]

denial ::

Still buggy: KLIK
SELECT finger FROM hand WHERE id=3;

fiction ::

Mah tezava je v tem, da je vse skupaj postalo prevec zakomplicirano. Unicode je dolg 4 bajte ali kako? Te razni transformacijski formati ala UTF-8 so pa se bolj tricky. Navadni znaki so en bajt dolgi tako kot ASCII (medtem ko je za posebne uporabljenih vec bajtov). Ponavadi imas 3 znake in je to 3 bajte, lahko pa pride do tega, da imas 3 special znake, ki zasedejo 18 bajtov (baje je do 6 bajtov sem nekje prebral, ceprav bi bilo bolj logicno samo do 4). S temi pretvorbami sem in tja hitro pride do napak. Da ne govorimo o tem, da imas lahko tudi "napacne" znake.

Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Izšel KDE 4.3

Oddelek: Novice / Ostala programska oprema		485330 (2807) Icematxyz
»

Linux / net

Oddelek: Pomoč in nasveti		221569 (1242) roscha
»

SATA diski @ Gentoo - kernel panic

Oddelek: Operacijski sistemi		61668 (1565) PARTyZAN
»

Varnost v Linuxu

Oddelek: Operacijski sistemi		131587 (1293) d0rK
»

Linux varnostne luknje

Oddelek: Operacijski sistemi		302371 (2124) BigWhale

Več podobnih tem