Re: [LUG.ro] Flisol 2018

2018-04-16 Por tema Omar Arino
>
> Podría, pero me quedo corto con el tema de "Comentar" la instalación, de
> hacerla
> entendible.
> El tema es que no se si voy a poder estar presente.
> Pensé en voz alta la solución al tema de "no hacer mas instalaciones en un
> Flisol".
>
>
Si, pero hoy es bastante fácil hacer la instalación, comparado con años
atrás.

Creo que las últimas que hicimos fueron en equipo "problemáticos".

Hablando al respecto, hace poco tuve que instalar en un equipo con UEFI en
paralelo a una instalación de Güindous 10 que no soporta el modo legacy de
la BIOS.
La instalación fue automática, con Ubuntu 16.04, lo único que tuve que
hacer, para
poder soportar los controladores propietarios para la placa de video es
deshabilitar
el control de firmas de UEFI.

No se que otra cosa pueda llegar a dar problemas hoy en una instalación,
salvo
algún componente no soportado en el kernel y que requiera compilación no
creo
que de problemas, aunque puede equivocarme.

Omar
___
Lugro mailing list
Lugro@lugro.org.ar
http://lugro.org.ar/mailman/listinfo/lugro


[LUG.ro] Flisol 2018

2018-04-16 Por tema Mario OROZ
El 10/4/2018 a las 3:55 p. m., Fernando Marcos Pelillo escribió:
>> Hola, buenas tardes...
>>
> Hola, Mario.
>
>> A lo mejor se pueda hacer *una* instalación comentada paso a paso, en la
>> que el
>> publico puede hacer preguntas?
>> Como para tener una idea de a lo que se enfrente el posible nuevo usuario,
>> o el
>> usuario de otros SO.
>>
> Me parece buena idea. ¿Te animás a hacerla vos?

Podría, pero me quedo corto con el tema de "Comentar" la instalación, de hacerla
entendible.
El tema es que no se si voy a poder estar presente.
Pensé en voz alta la solución al tema de "no hacer mas instalaciones en un 
Flisol".

>> No se con que recursos se contara pero con un proyector e instalando en
>> una VM
>> se podría hacer una instalación ejemplo...
>>
> Pregunto, creo que no va a haber problemas con conseguir un proyector...
>
>> Incluso sabemos que cada distro tiene su forma de instalar las cosas y se
>> podrían mostrar opciones.
>>
>> Saludos.
>>
> Saludos, y gracias por aportar...
>
>> Mario.
>>> También sería fantástico que alguien contara lo que sabe sobre Voto
>>> electrónico, sin necesidad de debatir sobre cuestiones partidarias
>> (aunque
>>> personalmente no me molestan, si son con altura).
>>> Espero sus comentarios.
>>> Un fraternal saludo.
>>>
>> _
>>
>>   
>>

___
Lugro mailing list
Lugro@lugro.org.ar
http://lugro.org.ar/mailman/listinfo/lugro


[LUG.ro] Escalada de permisos comando beep

2018-04-16 Por tema Omar Arino
http://unaaldia.hispasec.com/2018/04/holeybeep-escalado-de-permisos-en-linux.html

El programa Beep, disponible en la mayoría de distribuciones, no parecía
mantenerse desde el año 2013 a pesar de emplear el ejecutable el bit SUID

Parece casi una broma, como así evidencia la web creada para la ocasión
(holeybeep.ninja) con un gran sentido del humor, pero fallos como estos no
hacen más que demostrar la falta de auditoría de código, más en casos como
estos en los que el programa hace uso del bit 'SUID'.

El bit 'SUID', permite la ejecución de un programa como otro usuario (el
creador del ejecutable) para así poder realizar operaciones que normalmente
no podría realizar el usuario que emplea el programa. Un ejemplo clásico es
el comando 'passwd': este  programa requiere modificar el archivo protegido
del sistema ('/etc/shadow') donde se almacenan las contraseñas de los
usuarios, pero un usuario común requiere poder cambiar su propia contraseña
(pero no la del resto de usuarios). En este caso, el programa 'passwd' se
ejecuta como root a pesar de emplearse por un usuario sin permisos, y es el
programa el encargado de asegurar que el usuario no pueda realizar acciones
que pongan el sistema en riesgo.

En el caso que nos ocupa, el programa Beep, que hace uso del bit 'SUID'
para ejecutarse como root por un usuario común, llevaba varios años sin
actualizarse. Cualquiera pensaría que un programa de este tipo, de tan solo
375 líneas de código y tantos años a sus espaldas (la versión 1.2.2 es de
2002) no contaría con vulnerabilidades, lo que ha quedado patente que no es
así. La vulnerabilidad (CVE-2018-0492) es provocada por un efecto carrera
que permitiría escribir a un archivo protegido tal y como se explica en
Pirhack's Blog, y así escalar privilegios.

La vulnerabilidad, de la que ya hay un ejemplo de explotación, aprovecha
que la función 'handle_signal' del programa es un signal (permitiendo su
ejecución en cualquier momento), para así ejecutarse manteniendo el valor
anterior de la variable 'console_type', y el nuevo de la variable
'console_fd', y así poder escribir a cualquier archivo.

Por suerte el programa no se encuentra instalado de serie en distribuciones
como Debian, aunque sí es un paquete conocido y utilizado por scripts.
Aunque las vulnerabilidades para escalado de permisos son comunes, los
ejecutables que hacen uso del bit 'SUID' deberían ser los primeros en ser
analizados en busca de este tipo de errores.


Juan José Oyague
joyague[_AT_]ispasec.com

Más información:

Holey Beep:
https://holeybeep.ninja/

CVE-2018-0492:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0492

HoleyBeep: Explanations and exploit:
https://sigint.sh/#/holeybeep

Ejemplo explotación:
https://gist.github.com/Arignir/0b9d45c56551af39969368396e27abe8

Código fuente:
https://github.com/johnath/beep/blob/master/beep.c
___
Lugro mailing list
Lugro@lugro.org.ar
http://lugro.org.ar/mailman/listinfo/lugro