Hervé Godquin

Aller au contenu | Aller au menu | Aller à la recherche

lundi 6 mai 2019

La superbe backdoor Américaine

On peut toujours parler des hypothétiques backdoors chinoises mais en tout cas les backdoors US sont bien réelles elles :).

Une petite clé SSH présentes par défaut sur les Nexus 9000. Elle donne les droits root bien évidemment.

Have Fun !

GRO packet of death

Ca rappelle le bon vieux temps :) Il semblerait qu'il soit possible de faire un DoS sur des kernels 5.0.x avec des paquets UDP avec des payloads null.

Sur le sujet : https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=4dd2b82d5adfbe0b1587ccad7a8f76d826120f37

Have fun !

jeudi 2 mai 2019

[CVE-2019-9928] Heap Overflow dans GStreamer

Un patch pour une vulnérabilité dans l'analyseur RTSP de Gstreamer vient de sortir, et en regardant de plus prêt on constate qu'il s'agit de l'histoire d'un classical fail pour le coup :

for (i = 0; session_id[i] != '\0'; i++) {

            if (session_id[i] == ';') {

              maxlen = i;

et un peu plus loin :

            strncpy (conn->session_id, session_id, maxlen);

Le patch ? remplacer le for par celui-ci :

          for (i = 0; i < maxlen && session_id[i] != '\0'; i++) {

Voilà c'était la classical vuln du soir :)

Have fun !

Etude de la vulnérabilité CVE-2019-10125 et combat pour le patching part. 2

Bonjour à toutes et à tous,

Je vais tenter ici d'étudier une vulnérabilité touchant le kernel Linux à savoir la CVE-2019-10125. Cette dernière a un score de 9.8 sur NVD, elle est qualifiée de 7.3 par RedHat, 5.5 par vulndb, "Medium" par Ubuntu, nous allons tenter de savoir pourquoi, et je vais dans la continuité parler de la difficulté de la mise en place des campagnes de patchs qui en découlent.

La description de la vulnérabilité est la suivante :

An issue was discovered in aio_poll() in fs/aio.c in the Linux kernel through 5.0.4. A file may be released by aio_poll_wake() if an expected event is triggered immediately (e.g., by the close of a pair of pipes) after the return of vfs_poll(), and this will cause a use-after-free.

Autant dire que c'est extrémement parlant pour le coup. Voilà vous avez compris je peux m'arrêter là ! Non je rigole, allons un peu plus loin car au final avec une explication pareil on peut avoir du mal à comprendre la note de 9.8.

Nous avons donc à faire à un use-after-free, pour ceux qui ne savent pas ce que c'est je vous invite à lire à minima ceci : https://www.owasp.org/index.php/Using_freed_memory

Nous savons que la vulnérabilité touche AIO, AIO c'est pour Asynchronous I/O c'est du POSIX et cela permet à un programme d'effectuer ... bah des I/O de manière asynchrone :) Merci super évidence Hervé !. En gros cela est utilise lorque l'on a un grand nombre d'opérations à traiter et qu'attendre un retour disque avec un read() bah ... ce n'est pas envisageable.

Petit exemple : pour lire le fichier /etc/shadow on ferait un truc de ce style :

fileDescripteur = open("/etc/shadow", O_RDONLY);
aio_context_t a = 0;
b = io_setup(128, &a);
char i[4096];
struct iocb icb = {.aio_fildes = fileDescripteur,
                   .aio_lio_opcode = IOCB_CMD_PREAD,
                   .aio_buf = (uint64_t)i,
                   .aio_nbytes = sizeof(i)};
struct iocb *iocbList[1] = {&icb};
b = io_submit(a, 1, iocbList);
struct io_event e[1] = {{0}};
b = io_getevents(a, 1, 1, e, NULL);
z = e[0].res;
printf("Données lues : %lld octets\n", z);
 

Si vous avez appréhendé le concept de use-after-free vous pouvez deviner que des opérations asynchrone, à gérer en C, c'est bien le genre d'endroit ou on oublie un petit cas de figure et ou le use-after-free arrive :).

Du coup qu'est-ce qui pose problème ?

Le problème semble venir de la fonction aio_poll(), regardons donc son code source (avant le patch) dans fs/aio.c :

Pour mon exemple j'ai pris le code source de la 5.0.2 que vous pouvez télécharger ici : https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/linux-5.0.2.tar.gz.

Voici donc le code de la coupable :

static ssize_t aio_poll(struct aio_kiocb *aiocb, const struct iocb *iocb)
{
        struct kioctx *ctx = aiocb->ki_ctx;
        struct poll_iocb *req = &aiocb->poll;
        struct aio_poll_table apt;
        __poll_t mask;

        /* reject any unknown events outside the normal event mask. */
        if ((u16)iocb->aio_buf != iocb->aio_buf)
                return -EINVAL;
        /* reject fields that are not defined for poll */
        if (iocb->aio_offset || iocb->aio_nbytes || iocb->aio_rw_flags)
                return -EINVAL;

        INIT_WORK(&req->work, aio_poll_complete_work);
        req->events = demangle_poll(iocb->aio_buf) | EPOLLERR | EPOLLHUP;
        req->file = fget(iocb->aio_fildes);
        if (unlikely(!req->file))
                return -EBADF;

        req->head = NULL;
        req->woken = false;
        req->cancelled = false;

        apt.pt._qproc = aio_poll_queue_proc;
        apt.pt._key = req->events;
        apt.iocb = aiocb;

        apt.error = -EINVAL; /* same as no support for IOCB_CMD_POLL */

        /* initialized the list so that we can do list_empty checks */
        INIT_LIST_HEAD(&req->wait.entry);
        init_waitqueue_func_entry(&req->wait, aio_poll_wake);

        /* one for removal from waitqueue, one for this function */
        refcount_set(&aiocb->ki_refcnt, 2);

        mask = vfs_poll(req->file, &apt.pt) & req->events;
        if (unlikely(!req->head)) {
                /* we did not manage to set up a waitqueue, done */
                goto out;
        }

        spin_lock_irq(&ctx->ctx_lock);
        spin_lock(&req->head->lock);
        if (req->woken) {
                /* wake_up context handles the rest */
                mask = 0;

                apt.error = 0;
        } else if (mask || apt.error) {
                /* if we get an error or a mask we are done */
                WARN_ON_ONCE(list_empty(&req->wait.entry));
                list_del_init(&req->wait.entry);
        } else {
                /* actually waiting for an event */
                list_add_tail(&aiocb->ki_list, &ctx->active_reqs);
                aiocb->ki_cancel = aio_poll_cancel;
        }
        spin_unlock(&req->head->lock);
        spin_unlock_irq(&ctx->ctx_lock);

out:
        if (unlikely(apt.error)) {
                fput(req->file);
                return apt.error;
        }

        if (mask)
                aio_poll_complete(aiocb, mask);
        iocb_put(aiocb);
        return 0;
}
 

Bon autant dire que comme ça, ça ne nous aide pas trop, y a même pas un free qui traîne, par contre on trouve des fget() et des fput() et si on prend le temps de lire ce que disent les linuxiens on voit ceci dans un commentaire qui va avec le patch :

Al Viro root-caused a race where the IOCB_CMD_POLL handling of fget/fput() could cause us to access the file pointer after it had already been freed.

Bon c'est que l'on se rapproche tout de même. Mais au final on ne la voit toujours pas bien cette vulnérabilité qui a un 9.8 !

Avant d'expliquer la vulnérabilité en soit il faut décrire, entre autre, ce que sont : aio_kiocb et iocb.

Voici donc la définition de aio_kiocb :

struct aio_kiocb {
        union {
                struct kiocb            rw;
                struct fsync_iocb       fsync;
                struct poll_iocb        poll;
        };

        struct kioctx           *ki_ctx;
        kiocb_cancel_fn         *ki_cancel;

        struct iocb __user      *ki_user_iocb;  /* user's aiocb */
        __u64                   ki_user_data;   /* user's data for completion */

        struct list_head        ki_list;        /* the aio core uses this
                                                 * for cancellation */
        refcount_t              ki_refcnt;

        /*
         * If the aio_resfd field of the userspace iocb is not zero,
         * this is the underlying eventfd context to deliver events to.
         */
        struct eventfd_ctx      *ki_eventfd;
};
 

Et celle de iocb :

struct iocb {
        /* these are internal to the kernel/libc. */
        __u64   aio_data;       /* data to be returned in event's data */

#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
        __u32   aio_key;        /* the kernel sets aio_key to the req # */
        __kernel_rwf_t aio_rw_flags;    /* RWF_* flags */
#elif defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
        __kernel_rwf_t aio_rw_flags;    /* RWF_* flags */
        __u32   aio_key;        /* the kernel sets aio_key to the req # */
#else
#error edit for your odd byteorder.
#endif

        /* common fields */
        __u16   aio_lio_opcode; /* see IOCB_CMD_ above */
        __s16   aio_reqprio;
        __u32   aio_fildes;

        __u64   aio_buf;
        __u64   aio_nbytes;
        __s64   aio_offset;

        /* extra parameters */
        __u64   aio_reserved2;  /* TODO: use this for a (struct sigevent *) */

        /* flags for the "struct iocb" */
        __u32   aio_flags;

        /*
         * if the IOCB_FLAG_RESFD flag of "aio_flags" is set, this is an
         * eventfd to signal AIO readiness to
         */
        __u32   aio_resfd;
};

 

Afin de mieux comprendre la vulnérabilité je vous suggère aussi de lire la page man de io_submit : http://man7.org/linux/man-pages/man2/io_submit.2.html.

Lorsque l'on fait un io_submit() ce dernier alloue des instance aio_kiocb et les passe à aio_poll(), ensuite cette fonction fait son job, à savoir :

  • résoudre le descripteur de fichier;
  • change l'état woken;
  • passe les données à vfs_poll();
  • Gère l'état de la queue et le statut des aio_kiocb.

En soit la plus part des problèmes vous les verrez dans le fichier aio.c (fs/aio.c) :

En plus des erreurs qui faisaient le pointeur vers le fichier n'était pas le premier élément de certaines structures, la plus grosse erreur se situe aussi dans une fonction au nom assez évocatrice à savoir aio_complete_rw() qui avait le code suivant :

file_end_write(kiocb->ki_filp);

}

fput(kiocb->ki_filp);

aio_complete(iocb, res, res2);

}

Et des goto out_fput un peu partout comme dans la fonction : aio_prep_rw() :

ret = kiocb_set_rw_flags(req, iocb->aio_rw_flags);

if (unlikely(ret))

goto out_fput;

req->ki_flags &= ~IOCB_HIPRI; 

return 0;

 

out_fput:

fput(req->ki_filp);

return ret;

}

Le problème vient donc du fait que si juste après notre fget() et avant le retour de poll() un thread termine le descripteur, alors le fput() est fait sur une ressource libérée ... nous avons donc un Use-After-Free.

Du coup on comprend bien mieux la description :

An issue was discovered in aio_poll() in fs/aio.c in the Linux kernel through 5.0.4. A file may be released by aio_poll_wake() if an expected event is triggered immediately (e.g., by the close of a pair of pipes) after the return of vfs_poll(), and this will cause a use-after-free.

 

Bon là vous me dites : ok on a un super UAF en local, certes avec un "pont" ring kernel / ring user et tout, mais je vois pas pourquoi on se retrouve avec un score de 9.8.

Alors je vous le donne en mille : il est possible de gérer des sockets avec ça :).

Bon après IOCB_CMD_POLL n'étant pas si vieux : https://lwn.net/Articles/743714/ ... Trouver un cas réel et exploitable ça ne va pas nécessaire être de la tarte, mais c'est certainement possible.

Par exemple vous trouverez ici un code faisant cela : https://github.com/cloudflare/cloudflare-blog/blob/master/2019-01-io-submit/aio_poll.c#L63

Et du coup cela nous dit quoi au final ?

Alors la CVE-2019-10125 c'est quoi comme note : au fait si vous êtes paranoïac et théoriquement : oui c'est du 9.8, par contre je peux comprendre les notes de 5.5 et Medium d'une autre part : bien que pas impossible, l'exploitation de cette vulnérabilité semble ... plus de complexe (et bon généralement on trouve quelque chose de nettement plus simple à côté :)).

De même il est à noter que certaines distributions ne semblent même pas être vulnérables : https://deb.freexian.com/extended-lts/tracker/CVE-2019-10125.

Alors je n'ai pas spécialement envie de fixer une note concernant cette vulnérabilité de mon coté : ça n'a aucun intérêt, je suis plutôt à mener le combat du patching : donc patchez, on s'en moque de la criticité ;).

Et voilà où le bât blesse, dans beaucoup de circonstance, si un RCE à distance n'est pas démontrable facilement et avec des logiciels/middlewares bien utilisés il est assez dur de dire il faut patcher et en urgence. Ou même patcher de la production car en effet ceci ne parle au final pas beaucoup à un responsable de production :

 BUG: KASAN: use-after-free in perf_trace_lock_acquire+0x3ab/0x570
 Read of size 8 at addr ffff888379bfd4b0 by task syz-executor.1/4953

 CPU: 0 PID: 4953 Comm: syz-executor.1 Not tainted 4.19.24
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1
 Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0xca/0x13e lib/dump_stack.c:113
  print_address_description+0x79/0x330 mm/kasan/report.c:256
  kasan_report_error mm/kasan/report.c:354 [inline]
  kasan_report+0x18a/0x2e0 mm/kasan/report.c:412
  trace_event_get_offsets_lock_acquire include/trace/events/lock.h:13 [inline]
  perf_trace_lock_acquire+0x3ab/0x570 include/trace/events/lock.h:13
  trace_lock_acquire include/trace/events/lock.h:13 [inline]
  lock_acquire+0x202/0x310 kernel/locking/lockdep.c:3899
  __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
  _raw_spin_lock+0x2c/0x40 kernel/locking/spinlock.c:144
  spin_lock include/linux/spinlock.h:329 [inline]
  aio_poll fs/aio.c:1750 [inline]
  io_submit_one+0xb90/0x1b30 fs/aio.c:1853
  __do_sys_io_submit fs/aio.c:1919 [inline]
  __se_sys_io_submit fs/aio.c:1890 [inline]
  __x64_sys_io_submit+0x19b/0x500 fs/aio.c:1890
  do_syscall_64+0xc8/0x580 arch/x86/entry/common.c:290
  entry_SYSCALL_64_after_hwframe+0x49/0xbe
  ......
  Allocated by task 4953:
  set_track mm/kasan/kasan.c:460 [inline]
  kasan_kmalloc+0xa0/0xd0 mm/kasan/kasan.c:553
  kmem_cache_alloc_trace+0x12f/0x2d0 mm/slub.c:2733
  kmalloc include/linux/slab.h:513 [inline]
  kzalloc include/linux/slab.h:707 [inline]
  alloc_pipe_info+0xdf/0x410 fs/pipe.c:633
  get_pipe_inode fs/pipe.c:712 [inline]
  create_pipe_files+0x98/0x780 fs/pipe.c:744
  __do_pipe_flags+0x35/0x230 fs/pipe.c:781
  do_pipe2+0x87/0x150 fs/pipe.c:829
  __do_sys_pipe2 fs/pipe.c:847 [inline]
  __se_sys_pipe2 fs/pipe.c:845 [inline]
  __x64_sys_pipe2+0x55/0x80 fs/pipe.c:845
  do_syscall_64+0xc8/0x580 arch/x86/entry/common.c:290
  entry_SYSCALL_64_after_hwframe+0x49/0xbe

 Freed by task 4952:
  set_track mm/kasan/kasan.c:460 [inline]
  __kasan_slab_free+0x12e/0x180 mm/kasan/kasan.c:521
  slab_free_hook mm/slub.c:1371 [inline]
  slab_free_freelist_hook mm/slub.c:1398 [inline]
  slab_free mm/slub.c:2953 [inline]
  kfree+0xeb/0x2f0 mm/slub.c:3906
  put_pipe_info+0xb0/0xd0 fs/pipe.c:556
  pipe_release+0x1ab/0x240 fs/pipe.c:577
  __fput+0x27f/0x7f0 fs/file_table.c:278
  task_work_run+0x136/0x1b0 kernel/task_work.c:113
  tracehook_notify_resume include/linux/tracehook.h:193 [inline]
  exit_to_usermode_loop+0x1a7/0x1d0 arch/x86/entry/common.c:166
  prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
  syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
  do_syscall_64+0x461/0x580 arch/x86/entry/common.c:293
  entry_SYSCALL_64_after_hwframe+0x49/0xbe
  1. Tiens : A noter que sur securityfocus la vulnérabilité est bien noté comme étant Local.

Ni même à certains ingénieur système d'ailleurs ... Du coup comment faire ?

Créer un PoC démontrant la vulnérabilité et son exploitation (en local ET en remote), combien d'heure pour cela ?

Pas sûr que beaucoup d'équipes de cyber-sécurité internes aient le temps pour ce genre d'amusement (elles aimeraient bien j'en suis sûr, mais bon), ne serait-ce que pour trouver cet exemple de vulnérabilité, pour démontrer l'exemple, l'étude de cette dernière, regarder les fonctions touchées, les patchs, trouver des exemples d'utilisations, et écrire ces quelques lignes ... cela prend pas mal de temps, ou alors je suis rouillé c'est possible je veillis, mais faire un PoC d'exploitation en plus.

Et faire ça pour chaque patchs kernels/gLibC de ce type ?

Non une seule politique doit fonctionner : si je passe un coup d'OpenVAS/Qualys/Nessus/Rapid7 : le résultat doit être null, je sais c'est inatteignable mais bon c'est l'objectif à fixer tout de même.

En même temps il est souvent assez difficile de faire comprendre cela à des DSI, et même des RSSI, quand des vendeurs d'échecs de rêves leurs promettent une sécurité à 100% contre les menaces qui sont inconnues à longueur de journée. Non ! Non ! et non ! Ton anti-APT-de-la-mort-qui-tue ne sert à rien si le parc n'est pas patché. Et à lma rigueur s'il ne restait que la CVE-2019-10125 sur la plus part des systèmes ... Ca serait déjà le bonheur :)

Conclusions

Certaines vulnérabilités sont déjà assez dure à définir d'un point de vue de la criticité, mais leur exploitabilité in da real life n'est pas toujours facile à prouver, du moins dans le temps d'une personne travaillant sur de la production. Après certes on peut faire une petite application avec un thread qui déclenche le UAF à un moment définit mais cela ne prouvera jamais à un responsable de production, ou pire à un responsable métier, un cas d'exploitation réel.

D'ailleurs les différences de scores montre aussi d'autres problèmes : certaines ou certains ont pensé que cela pouvait être exploitable à distance pour se retrouver avec un 9.8 tandis que d'autres non (Medium, 5.5, 7.3). Assez difficile dans ce cas de justifier d'un patching en urgence de ce type de vulnérabilités. Cela montre donc la difficulté du travail d'évangelisation à faire autour du patching, qui malgré tout, et malgré le temps passé est toujours quelque chose de dur à mettre en oeuvre.

Voilà, désolé cela faisait bien longtemps que je n'avais pas fait un blogpost, j'espère que ce n'est pas trop fouilli et que ce vous a plu (et que je n'ai pas laissé trop de fautes d'orthographe). Promis la prochaine fois je parle d'une, oui je précise une car je vais faire des blogpost régulièrement sur les dernières vulnérabilités touchant Linux (du moins le kernel et la gLibC), vulnérabilité je mets un PoC d'exploitation :).

Mais bon après on est tout de même mieux à faire ça, que faire de l'IAM !

[CVE-2019-6974][CVE-2019-7221] : Kernel - kvm : 2 UAF à corriger et combat pour le patching part.1

Bonjour à toutes et à tous,

Ce soir je viens vous parler du RHSA-2019:0818 (https://access.redhat.com/errata/RHSA-2019:0818) qui corrige, entre autre, deux vulnérabilités de types Use-After-Free à savoir : CVE-2019-6974 et CVE-2019-7221. Ces deux vulnérabilités sont assez intéressantes, et assez simples, à étudier car elles font l'objet toutes les deux de publications par projectzero.

Vous allez me dire : "tu triches du coup, tu reprends le travail d'autres !" : oui pour le coup j'avoue, mais cela fait parti d'un ensemble, nous allons voir ici l'exemple de deux vulnérabilités assez bien documentées mais je vous prépare un prochain article montrant comment il est difficile de faire prendre en compte la menace d'une vulnérabilité, notamment dans le cadre d'une campagne de patching.

La CVE-2019-7221

La description générale :

A use-after-free vulnerability was found in the way the Linux kernel's KVM hypervisor emulates a preemption timer for L2 guests when nested (=1) virtualization is enabled. This high resolution timer(hrtimer) runs when a L2 guest is active. After VM exit, the sync_vmcs12() timer object is stopped. The use-after-free occurs if the timer object is freed before calling sync_vmcs12() routine. A guest user/process could use this flaw to crash the host kernel resulting in a denial of service or, potentially, gain privileged access to a system.

La description sur projectzero est disponible ici : https://bugs.chromium.org/p/project-zero/issues/detail?id=1760

La CVE-2019-6974

La description générale :

A use-after-free vulnerability was found in the way the Linux kernel's KVM hypervisor implements its device control API. While creating a device via kvm_ioctl_create_device(), the device holds a reference to a VM object, later this reference is transferred to the caller's file descriptor table. If such file descriptor was to be closed, reference count to the VM object could become zero, potentially leading to a use-after-free issue. A user/process could use this flaw to crash the guest VM resulting in a denial of service issue or, potentially, gain privileged access to a system.

On va un peu plus d'attarder sur cette vulnérabilité car elle vous permttra d'appréhender mon prochain article. Qui sera un peu plus long je vous l'assure.

Comme expliquer dans l'article de projectzero le code posant problème est le suivant :

kvm_ioctl_create_device() contains the following code:

dev = kzalloc(sizeof(*dev), GFP_KERNEL);
if (!dev)
return -ENOMEM;

dev->ops = ops;
dev->kvm = kvm;

mutex_lock(&kvm->lock);
ret = ops->create(dev, cd->type);
if (ret < 0) {
mutex_unlock(&kvm->lock);
kfree(dev);
return ret;
}
list_add(&dev->vm_node, &kvm->devices);
mutex_unlock(&kvm->lock);

if (ops->init)
ops->init(dev);

ret = anon_inode_getfd(ops->name, &kvm_device_fops, dev, O_RDWR | O_CLOEXEC);
if (ret < 0) {
mutex_lock(&kvm->lock);
list_del(&dev->vm_node);
mutex_unlock(&kvm->lock);
ops->destroy(dev);
return ret;
}

kvm_get_kvm(kvm);
cd->fd = ret;
 

De même on nous explique que :

This code:

1. creates a device that holds a reference to the VM object (with a borrowed
reference, the VM's refcount has not been bumped yet)
2. initializes the device
3. transfers the reference to the device to the caller's file descriptor table
4. calls kvm_get_kvm() to turn the borrowed reference to the VM into a real
reference

The ownership transfer in step 3 must not happen before the reference to the VM
becomes a proper, non-borrowed reference, which only happens in step 4.
After step 3, an attacker can close the file descriptor and drop the borrowed
reference, which can cause the refcount of the kvm object to drop to zero.

Oui je sais jusque là je me suis vraiment déchiré niveau éditorial :). Mais voilà on va rentrer dans le dur.

Alors le problème se situe donc quelque part par ici :

if (ops->init)

ops->init(dev);

ret = anon_inode_getfd(ops->name, &kvm_device_fops, dev, O_RDWR | O_CLOEXEC);

if (ret < 0) {

mutex_lock(&kvm->lock);

list_del(&dev->vm_node);

mutex_unlock(&kvm->lock);

Et ici :

return ret;

}

kvm_get_kvm(kvm);

cd->fd = ret;

return 0;

}

On peut donc constater qu'effectivement il manque quelques petites choses, et parfois des petites choses en trop :

Dans la première partie de code que je présente à aucun moment kvm_get_kvm() n'est appelé, il n'est appelé qu'à la fin du processus. De même aucun appel n'est fait vers kvm_put_kvm() fonction définit comme suit :

void kvm_put_kvm(struct kvm *kvm)
  {
  if (refcount_dec_and_test(&kvm->users_count))
  kvm_destroy_vm(kvm);
  }
 

EXPORT_SYMBOL_GPL(kvm_put_kvm);

Voilà cette vulnérabilité est assez "simple" à appréhender et à comprendre, d'ailleurs vous pouvez retrouver un exemple d'exploitation sur projectzero : https://bugs.chromium.org/p/project-zero/issues/detail?id=1765

Patching

Je ne vais pas vous présenter le patch vous pouvez le trouver vous même, mais vous parler de patching, en soit ce genre de vulnérabilité est sympathique, en effet, elle est simple à décrire, un PoC d'exploitation est présent. C'est publié par des personnes connues et tout le monde est d'accord sur l'impact, convaincre un responsable de production ou un resposable métier de pacher est bien plus facile avec ce genre de vulnérabilité, mais dans un prochain article à paraître (paru ici : https://www.herve-godquin.fr/index.php?post/2019/04/30/Etude-de-la-vuln%C3%A9rabilit%C3%A9-CVE-2019-10125) très bientôt vous verrez que ce n'est pas nécessairement le cas tout le temps.

Conclusion

Patchez !

mercredi 1 mai 2019

Nouveau blog

Bienvenue à toutes et à tous sur mon nouveau blog,

J'ai décidé de faire tout en un en créant ce nouveau blog à la place d'un site statique.

Je vais essayer que ce blog soit un peu plus actif et un peu plus axé cyber-sécurité que le dernier, bien que je continuerai à parler aussi de technique liée au streaming/VoD aussi de temps en temps.

Je vous laisse je vais préparer de nouveaux posts :).

Have fun !