Publicada vulnerabilidad crítica (RCE sin autenticar) en kernel de Linux

131 meneos

1464 clics

Publicada vulnerabilidad crítica (RCE sin autenticar) en kernel de Linux

KSMBD es un servidor del kernel de Linux que implementa el protocolo SMB3 en el espacio del kernel para compartir archivos a través de la red. Un atacante remoto no autenticado puede ejecutar código arbitrario en instalaciones vulnerables del kernel de Linux.

78 53 0 K 402

77 comentarios

78 53 0 K 402

Comentarios destacados:

#1 Zotal

“atacantes remotos ejecutar código arbitrario en instalaciones afectadas de Linux Kernel. No se requiere autenticación para explotar esta vulnerabilidad, pero solo los sistemas con ksmbd habilitado son vulnerables” es decir, un montón

4 26
#2 elchacas *

#1 Para aquellos que usan ksmbd, existe una solución diferente a cambiar a Samba: actualizar a la versión 5.15.61 del kernel de Linux, lanzada en agosto, o una versión más reciente.

Por lo que veo se solventa actualizando el kernel a versiones "modernas", la mayoría de distros que conozco van por delante hace ya bastante tiempo.

12 90
#3 --726925--

» ver comentario
#4 ppma

Soy un lego, y quizá sea una pregunta estúpida, pero me gustaría un poco de luz... ¿Cuál es la necesidad de integrar un servidor equivalente a Samba en el kernel? ¿Reducir el overhead en sistemas embebidos?

1 9
#5 --666006--

#4 Yo soy un tente.

12 97
#6 rogerillu

Es el año de linux en el escritorio…remoto

2 27
#7 Fingolfin

Casi nadie utiliza ksmbd, todo el mundo utiliza samba

5 55
#8 Hito

#4 Yo no tenía ni idea de que esto existía, la verdad, pero según el github del proyecto, el objetivo es conseguir mejor rendimiento e implementar ciertas características avanzadas de SMB que son mucho más fáciles de implementar dentro del kernel.

3 36
#9 geburah

#4 Esa es la idea:

"ksmbd" is a new Linux kernel module which implements an SMB server. It's aimed at being low overhead, low footprint, performant fileserver covering many basic usecases, running on smaller devices with limited resources being the most apparent one: OpenWRT, the Linux distribution for embedded devices, adopted ksmbd already 18 months ago while ksmbd was still being developed."

Las negritas son mias.

7 72
#10 CARLOSESTACABREADO

#4 No tengo ni idea de si samba soporta smb3 pero si no es así la seguridad es importante dejando a un lado el rendimiento y paralelización. Con SMB3 el repositorio se puede usar para ejecutar VMs desde un cluster
de hipervisores y gestionar correctamente los bloqueos de forma similar a NFS.

Yo también veo que meter esto en el kernel es un pelin peligroso pero en contrapartida el rendimiento debe ser espectacular.

0 10
#11 Hito

#1 Supongo que este ksmbd tendrá su caso de uso, no digo que no, pero sí que no diría que hay "un montón" de sistemas corriendo ksmbd.

3 36
#12 PasabaPorAquiUnRato

#5 y no solo eso. Aventuro que tiene Usted mas de cuarenta años.

3 47
#13 geburah

#1 A mi aun me falta ver un servidor con esto activado por defecto.

Que tengan un kernel con el modulo, si, que el modulo este cargado y listo para ser usado como tal es otra cosa.

Y las versiones del kernel desde agosto estarán mas que parcheadas.

Así que menos montón.

5 48
#14 Funkylab

#9 ¿Y las chinitas?

2 26
#15 geburah

#3 por lo menos en el kernel de Linux tienes a gente auditando este tipo de cosas, en sistema propietarios, no.

Supongo que toda la Infraestructura de Internet, todas las grandes empresas incluyendo bancos, telecos, energéticas, ciencia, etc, van con Linux por casualidad.

Espero que la proxima vez hablen contigo para que les des tu una idea buena, buena.

7 63
#16 MAD.Max *

#2 hay muchos sistemas que, por dependencias, no pueden actualizarse a la última versión de su distro. Por tanto tampoco tienen el último kernel

2 32
#17 Arariel

#12 _{_{Tengo 60 y cuando tenía 14 ya jugaba con Tente.}}

3 43
#18 --666006-- *

#12 Aventura usted bien. ¿En el barco de los piratas? Aún lo tengo por ahí, aunque las velas están casi quebradizas, me da no sé qué dejárselo a los sobrinos (ya tienen bastante con los mmaster del universo y los vehículos de los madelman).

2 26
#19 MAD.Max

#3 no hay sistema seguro, sino poco conocido

0 7
#20 PasabaPorAquiUnRato

#3 vaya por delante que carezco de conocimientos informáticos, pero yo diría que a dia de hoy (reitero que lo digo alegremente y sin conocimientos) linux me parece mas seguro que Windows. No puedo valorar Mac.

1 17
#21 ninefingers

#1 Servidores corporativos pocos.

1 16
#22 nospotfer

#3 Imagínate la de agujeros de seguridad que tienen Windows o Mac y que nunca sabrás ni que existen.

0 6
#23 Jakeukalane

#20 OpenBSD > Linux >>>> Windows > Mac

1 17
#24 jjmf *

Qué manía en Linux de nombrar las cosas cogiendo letras al azar y después eliminar las vocales.

0 7
#25 mre13185

#2 Por ejemplo yo. Para esas versiones no encuentro driver para mi tarjeta gráfica, y que no me digan que use el Wayland, que menudos cuelgues que se pega. Tengo que usar el software privativo y para los núcleos superiores a la 5.4.0 no funciona. El Samba uso el SMB2 aún, que no depende del kernel nada más que para lo necesario.

0 6
#26 --735246--

» ver comentario
#27 MarlonBlando

#3 "Yo le hago caso a giliwoke" no dicen.

0 6
#28 --731452--

#25 ¿ Cuál es tu tarjeta gráfica ?

0 11
#29 --731452--

#2 Es un error de Julio y en una versión antigua. Desde entonces ha habdo más de diez versiones de linux. ES lo que me pasa siempre con las noticias de bugs de software libre, que cuando llegan a mnm están más que parcheadas en mi sistema sin que yo siquiera me haya enterado.

5 52
#30 Ehorus

#4 ... pregunta y desde el desconocimiento, ¿quién deja "expuesto" un servidor de ficheros?... me refiero, que la vulnerabilidad - si en el hilo se ha explicado bien, es cuando expones el servidor con ksmbd. Ese servidor podrá estar dentro de una red "local" ... por lo que no termino de ver eso de "atacante remoto no autenticado".. en cualquier caso tendría (creo) que ser a través de la red
(disculpen mi ignorancia)

1 13
#31 --731452--

#3 Como se ve que desconoces el mundillo, te cuento las bases: en ingeniería no hay ningún sistema perfecto. Ninguno. El software no es una excepción. Uno de los ciclos de ingeniería es detectar errores, reportarlos y corregirlos. Cuando veas errores es que el sistema está funcionando. Este error en octubre estaba resuelto.
Cuando veas un sistema del que no se anuncia ningún error, es que no stá siendo mantenido y los errores se mantienen ahí indefinidamente.

1 18
#32 --731452--

#6 No, sin importancia. Nadie usará el protocolo smb a día de hoy en ningún sistema medianamente importante o cuidado. Hay cosas mucho mejores.

2 28
#33 geburah

#26 y el propietario tampoco es garantía de nada.

Si no sale a cuenta que salga la información de un problema de seguridad, se entierra y punto.

Con open source pueden haber cagadas pero estas están a la vista. Inherentemente es más seguro y confiable.

Del sistema propietario te tienes que fiar, es un acto más de fe. En el OpenSource és facil saber si algo lo es o no lo es.

2 25
#34 mre13185

#28 una GeForce 210, de 1 Gb, sí, ya sé que es antigua, pero ya no me molesto en cambiarla

0 6
#35 Jells

#26

En un sistema propietario tienes a gente contratada auditando, o por lo menos debería ser así

Seguro que tienen a gente auditando código, pero tú como usuario no puedes ver lo que hace ese código, así que te toca fiarte...

1 14
#36 Jells

#32 you también soy un lego (city, en mi caso), ¿qué otros protocolos (mejores) hay para un cliente Windows?

0 7
#37 Pablosky

#29 #2 Yo he visto servidores críticos en CPD críticos haciendo tareas críticas con Red Hat 7 (Sí, la del año 2000).

No la tienen expuesta a Internet al menos, pero vamos...

1 22
#38 --731452--

#36 por suerte en windows se puede instalar ya mucho software libre. Pero vamos, no conozco mucho windows. No me parece que sea algo muy usado en sistemas serios y lo poco que se usa da más dolores de cabeza que otra cosa.

0 11
#39 --731452--

#34 ah, claro, nvidia. Es una faena que el fabricante no haya querido colaborar con el núcleo de línux para darle un soporte adecuado. No sé si ya habían cambiado de idea. Yo cogí una amd para evitarme problemas.

3 32
#40 Jells

#37 por principio de prudencia si es crítico mejor tocarlo poco o nada, no sea que se estropee por haberlo tocado

0 7
#41 inar

#24 Starting pdrsnchz daemon ...............

0 10
#42 flixter

#30 en ese contexto que dibujas, los potenciales atacantes son (en efecto) las demas maquinas de la red.

0 7
#43 prejudice

#24 Yo no veo ninguna letra al azar. El protocolo original de Microsoft se llamaba smb
Luego un tio hizo una implementación libre de smb y lo llamo samba.

3 35
#44 jjmf

#43 y la k y la d?

0 7
#45 elchacas

#44 Normalmente la k es de kernel y la d de deamon.

3 24
#46 prejudice

#45 Sabía lo de la d pero no lo de la k
Siempre habia asociado la k a proyecto kde (Aunque en este caso no tiene nada que ver)

2 24
#47 ioxoi

#40 depende que es lo que tienes en tus sistemas, a poco que pueda ser comprometido, usa una distro orientada a servidores y parchea, ya sabes, primero en preproduccion, después en producción y a la semana en el centro de respaldo.
Te garantizo que se puede hacer incluso con sistemas realmente críticos de cientos de millones.

2 33
#48 Wajahpantat

#9 A ver, las negritas son universales, no te las puedes apropiar

2 18
#49 jularaXD

#26 a parte de lo que ha dicho #33 en codigo propietario te pueden meter puertas traseras sin que el usuario sea consciente. En open source cualquiera puede revisar que no sea asi.

1 16
#50 sesshoumaru

#46 Hubo un tiempo en el que el kernel incluía un servidor HTTP llamado khttpd

1 13
#51 chavi

#23 Mac usa kernel BSD

1 19
#52 Jakeukalane *

#51 no es relevante en este caso. Mi opinión se enfoca en el conjunto del software, no solo el núcleo.

0 11
#53 chavi

#9 Teniendo ssh smb es una inutilidad....

Salvo que los Windows están muy limitados, y si tienes sistemas Windows en la.red...

0 9
#54 chavi

#10 Con SMB3 el repositorio se puede usar para ejecutar VMs ..
Vaya, que avance....

0 9
#55 Jakeukalane *

#30 en la vida real hay servidores en producción con servicios abiertos publicados (algo aberrante si no hay un WAF o muy buena seguridad). Si se puede dejar expuesto, alguien lo dejará expuesto. Y los movimientos laterales dentro de una LAN son el primer ataque que se realiza una vez se ataca exitosamente una red.

0 11
#56 Jakeukalane

#41 systemctl restart pdrsnchzd

1 20
#57 PasabaPorAquiUnRato

#23 tambien confieso que no puedo valorar OpenBSD porque no le usado. Pero prometo asomarme a curiosearlo.

0 6
#58 mre13185

#39 Yo siempre los cojo nvidia porque se supone que son más fiables con Linux, pero en el nuevo ordenador me lo pensaré.

1 17
#59 CARLOSESTACABREADO

#54 Vaya, que manipulador... Te has dejado lo más importante, la coletilla...

... en un clúster

Para microsoft si es un avance teniendo en cuenta que SMB era (y en parte sigue siendo) una verdadera basura.

0 10
#60 chavi

#59 En un clúster hace mucho que se puede hacer eso. Y smb es innecesario para hacerlo

0 9
#61 CARLOSESTACABREADO

#60 ¿De que cluster me hablas? ¿De uno en azure, azure stack, hyper-v pelado?

Smb3 ha supuesto que microsoft no necesite tecnologías de terceros.¿Tiene lógica verdad?

0 10
#62 chavi

#61 Ya usa Hyper-v Microsoft en su nube ?

0 9
#63 chavi

#61 Ya en serio. Entiendo que smb3 sea útila para los sistemas Windows.

Pero ya. Nada más.

0 9
#64 bradbury9

#53 Rara es la red que no acaba teniendo un windows por algún lado

0 9
#65 chavi

#3 Pues si. Fíjate hasta que punto que una vulnerabilidad crítica como está puede no afectar prácticamente a nadie.

0 9
#66 CARLOSESTACABREADO

#63 Azure no es windows y smb3 tiene implicaciones que veo que no entiendes... Oye mejor déjalo ya.

Un saludo

0 10
#67 chavi *

#66 Que implicaciones que no pueda solucionar mejor por ejemplo Ceph, iSCSI o mismo NFS ?

Azure es un nombre que se le da a una estructura de virtualización como tantas otras.

0 9
#68 jjmf

#41 Hay que añadirle además una k y una d al final por lo visto.
Kpdrsnchzd sería un buen nombre.

0 7
#69 CARLOSESTACABREADO

#67 Ceph es un hiperescalar de ficheros, nada más... ISCSI es solo servir bloque... Por cierto un protocolo que es como es por su herencia con SCSI y que aunque ahora tiene una interesante función, es mucho más lento, inseguro y problemático que por ejemplo Fiber Channel.

NFS hace bien su cometido en la gestión de bloqueos pero es malísimo para paralelizar en múltiples canales hacia un solo origen. Casi es mejor hacerlo a nivel "IP" haciendo agregación de puertos.

SMB3 a parte de proveer de un nuevo servicio SaaS para gente que quiera un servidor seguro SMB en azure sin VPNs, es un repositorio que supera en rendimiento a NFS gracias a su nueva paralelización de conexiones y la gestión del bloqueo del nodo del cluster que tenga activo uno de los recursos del share. És útil en hyper-v, en azure y muy rápido... Realmente microsoft ha matado dos pájaros de un tiro. No me gusta nada microsoft pero ahí ha acertado. Por cierto SMB lo inventó IBM un año antes que NFS.

No seamos talibanes... Microsoft hoy es uno de los mayores donantes de proyectos open source y casi seguro que windows va a ser un GNU-linux más más pronto de lo que nos imaginamos (lo del linux subkernel system no es por azar, es para converger)

0 10
#70 chavi *

#69 Ceph es un hiperescalar de ficheros,
Qué quieres decir con "un hiperescalar" ?
Ceph es un sistema de almacenamiento en cluster con balanceo de carga y alta disponibilidad. Cuando Smb de la mitad de características esenciales para un sistema de clustering de virtualización avisa.
Recuerda que sobre CEPH puedes montar FiberChannel o iSCSI entre otras cosas.
iSCSI es para servir dispositivos de almacenamiento en red. ¿ Para qué quieres compartir archivos en un sistema de virtualización?.... entre sistemas virtualizados, aún. Pero para un sistema de de virtualización como hyper-v.....

es mucho más lento, inseguro y problemático que por ejemplo Fiber Channel.
Claro. Pero mucho más barato.
En los CPD potentes se usa FiberChannel.... ¿ Pero SMB3 para qué exactamente ?

NFS hace bien su cometido en la gestión de bloqueos pero es malísimo para paralelizar en múltiples canales hacia un solo origen. Casi es mejor hacerlo a nivel "IP" haciendo agregación de puertos.
Es infinitamente más eficiente en su trabajo que SMB. Por eso lleva décadas usándose en sistemas de virtualización, mientras que SMB solo parece que va a ser "usable" ahora.
Y no veo el problema de utilizar port-trunking/LACP para lo que está pensado el port-trunking/LACP. Por cierto, LACP no funciona a nivel de IP.

SMB3 a parte de proveer de un nuevo servicio SaaS para gente que quiera un servidor seguro SMB en azure sin VPNs...
Parece un copia-pega del departamento de márketing.
¿ Quieres decir "a parte de permitir compartir carpetas sin VPN" ?

es un repositorio que supera en rendimiento a NFS...
Je. Ardo en ver los benchmark. Por supuesto con una correcta configuración de ambos. LACP incluido.

gracias a su nueva paralelización de conexiones y la gestión del bloqueo del nodo del cluster que tenga activo uno de los recursos del share
Benchmark son amores. Los copia-pega de la página de venta del producto, no.

És útil en hyper-v...
Para hacer qué exactamente. Es un simple sistema de compartición de archivos. No es más útil que NFS.
Útil es iSCSI, Fiber Channel o Ceph.

Realmente microsoft ha matado dos pájaros de un tiro.
Qué dos pájaros?
Qué puede hacer aparte de compartir archivos ?

Por cierto SMB lo inventó IBM un año antes que NFS.
Ni, idea. ¿ importa ?. Por cierto, NFS nació en el año 1984.

No seamos talibanes... Microsoft hoy es uno de los mayores donantes de proyectos open source y casi seguro que windows va a ser un GNU-linux más más pronto de lo que nos imaginamos (lo del linux subkernel system no es por azar, es para converger)
Ciertamente, me importa un huevo.

En serio: ¿ Para qué sirve smb3 aparte de para compartir archivos ?. Si puede ser en palabras comprensibles, que los corta-pegas de márketing se me hacen difíciles.

0 9
#71 CARLOSESTACABREADO *

#70 "corta-pegas"

Encuentra de donde he cortado y pegado anda... Menudo Ad-hominem te has marcado.

"LACP no funciona a nivel de IP"

Pues claro que no, yo no he dicho eso, pero si tu repositorio NFS está en una IP, una de las variables del balanceo puede ser esa (ip, hash, mac...). El que seguro que no usa "ip" para nada es fiber channel

Es simple, NFS necesita de switchs para paralelizar,SMB3 no

Sobre Ceph pues es un SDS de tantos (muy popular, eso es todo)... Para mi gusto mejor en fichero y objeto y lento y malo para bloque. Y es hiperescalar debido a su arquitectura (pst, eso es bueno, no te enfades con me importa un huevo y cosas por el estilo)

"""En serio, para que sirve smb3 aparte de para compartir archivos?"""

Pues te lo he dicho es un muy buen repositorio para almacenar discos de máquinas virtuales vhdx y vhd onprem y en azure stack (y que los nodos del cluster lean y escriban coordinadamente sin romper nada) y pst... Integrado con storage spaces direct que es el SDS también hiperescalar de microsoft.

Precisamente por ser microsoft el peor player han ido dando pasos muy interesantes y económicos. Antes comentabas que iscsi es una solución coste efectiva... Pues SMB3 también y tiene algunas ventajas sobre iscsi (aunque para algunos escenarios siempre va a ser mejor un protocolo bloque nativo).

Ei, que no soy tu enemigo...

0 10
#72 inar

#68 Así debe ser. Será que la mía es un versión obsoleta o algo. Ya decía yo que no cargaba bien

0 10
#73 chavi *

#71 Pues claro que no, yo no he dicho eso, pero si tu repositorio NFS está en una IP, una de las variables del balanceo puede ser esa

No. Usas LACP. O bonding simple. Nada que ver con IP.

Es simple, NFS necesita de switchs para paralelizar,SMB3 no
Es simple. NFS tampoco. Para eso está el bonding

<I>Pues te lo he dicho es un muy buen repositorio para almacenar discos de máquinas virtuales vhdx y vhd
Eso es compartir archivos. Así de simple. No lo hace mejor que NFS y es una mierda pinchada en un palo para una infraestructura de virtualización.

Sobre Ceph pues es un SDS de tantos
Cita 3 con características similares. Y si obviamos VMWARE...

(y que los nodos del cluster lean y escriban coordinadamente sin romper nada)
Eso lo lleva haciendo décadas NFS

No has dicho aún que hace smb3 aparte de compartir archivos

0 9
#74 CARLOSESTACABREADO

#73

Espera me voy a empezar a poner con el mismo tonito que tu

"Y si obviamos VMWARE..."

Primero, lo obviamos por tus huevos morenos

Dos, vmware no tiene nada ni medio parecido a ceph... VSAN (by vmware) es un SDS bloque, ni objeto ni fichero (para eso ya tiene VMFS_X)

Sobre lacp, en serio, tienes que leer un poco sobre los algoritmos de balanceo... Mucha gente cree que se agregan los puertos físicos y lacp obra la magia... Pues no, se necesita un hash para la secuencia y una ip o mac para establecer origenes y destinos... Puedes leer ieee 802.3ad que buena falta te hace...

Y sobre el resto no voy a perder el tiempo tu soberbia es infinita... Vamos, un tio que nos explica a todos, incluidos todos los ingenieros de microsoft que se metan smb3 por donde les quepa que para entornos de azure o azure stack ya hay cosas mejores y que smb3 en storafmge spaces direct es una putísima mierda.

En serio, los talibanes tecnológicos sois tóxicos... ni te molestes en responder que no he sido yo el que ha ido increpando...

0 10
#75 chavi *

Lo importante de Ceph es la alta disponibilidad y el almacenamiento distribuido. No has citado ninguna alternativa

thelinuxcluster.com/2010/01/08/linux-bonding-modes/

NO se hace a nivel IP. Se usa la Mac. Son capas OSI distintas.

0 9
#76 chavi *

Sobre el resto no pierdes el tiempo porque no tienes nada que decir

Qué aporta smb3 más allá de la compartición de ficheros? Que hace que no haga NFS más allá de la autenticación y autorización? ( Que se puede lograr con kerberos)

Yo no he dicho que se metan smb3 por ningún lado. He dicho que no es nada "importante".

Otra cosa es que Azure esté organizado de modo que smb sea "algo importante".

Respecto al tono, lamento que no te guste. Solo he expresado y fundamentado mi opinión. Y el explicar cosas como si fuera un panfleto de Marketing no ayuda.

0 9
#77 Trigonometrico

#39 #58 Se supone que los drivers AMD abiertos son buenos, pero para una Vega 8 me funciona mejor el driver propietario.

1 22