Security-X

Forum Security-X => News => Discussion démarrée par: igor51 le novembre 04, 2020, 21:04:43

Titre: [FireEye]In Wild Critical Buffer Overflow Vulnerability in Solaris Can Allow Remote Takeover — CVE-2020-14871
Posté par: igor51 le novembre 04, 2020, 21:04:43
In Wild Critical Buffer Overflow Vulnerability in Solaris Can Allow
Remote Takeover — CVE-2020-14871

FireEye Mandiant has been investigating compromised Oracle Solaris
  machines in customer environments. During our investigations, we
  discovered an exploit tool on a customer’s system and analyzed it to
  see how it was attacking their Solaris environment. The FLARE team’s
  Offensive Task Force analyzed the exploit to determine how it worked,
  reproduced the vulnerability on different versions of Solaris, and
  then reported it to Oracle. In this blog post we present a description
  of the vulnerability, offer a quick way to test whether a system may
  be vulnerable, and suggest mitigations and workarounds. Mandiant
  experts from the FLARE team will provide more information on this
  vulnerability and how it was     href="/content/fireeye-www/en_US/blog/threat-research/2020/11/live-off-the-land-an-overview-of-unc1945.html">used
    by UNC1945 during a Nov. 12 webinar.     href="https://www.brighttalk.com/webcast/7451/451508">Register
  today and start preparing questions, because we will be fielding
  them from the audience at the end of the session.


 

Vulnerability Discovery


 

The security vulnerability occurs in the Pluggable Authentication
  Modules (PAM) library. PAM enables a Solaris application to
  authenticate users while allowing the system administrator to
  configure authentication parameters (e.g., password complexity and
  expiration) in one location that is consistently enforced by all applications.


 

The actual vulnerability is a classic stack-based buffer overflow
  located in the     href="http://web.archive.org/web/20080612012716/http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libpam/pam_framework.c#parse_user_name">PAM
      parse_user_name function. An
  abbreviated version of this function is shown in Figure 1.


 
   
     


          static int
  parse_user_name(char
            *user_input, char **ret_username)
  {
           
              register char *ptr;
              register int index
            = 0;
              char
            username[PAM_MAX_RESP_SIZE];
         /* ...
        */


                      ptr = user_input;
       
             /* ... */
               /*
               *
            username will be the first string we get from
            user_input
               * - we skip leading
            whitespaces and ignore trailing whitespaces
           
               */
              while (*ptr != '\0') {
       
                        if ((*ptr == ' ') || (*ptr == '\t'))
     
                                       break;
                   
            else {
                                 username[index]
            = *ptr;
                                 index++;

                                           ptr++;
                 
              }
              }
               /* ret_username
            will be freed in pam_get_user(). */
              if
            ((*ret_username = malloc(index + 1)) == NULL)
         
                      return (PAM_BUF_ERR);
              (void)
            strcpy(*ret_username, username);
              return
            (PAM_SUCCESS);
  }

 


  Figure 1: The parse_user_name function has a
    stack-based buffer overflow vulnerability


 

The vulnerability arises whenever a username longer than   class="code">PAM_MAX_RESP_SIZE (512 bytes) is passed to   class="code">parse_user_name. The vulnerability has likely
  existed for decades, and one possible reason is that it is only
  exploitable if an application does not already limit usernames to a
  smaller length before passing them to PAM. One situation where
  network-facing software does not always limit the username length
  arises in the SSH server, and this is the exploit vector used by the
  tool that we discovered.


 

SSH Keyboard-Interactive authentication is a “passthrough”
  authentication mechanism where the SSH protocol relays prompts and
  responses between the server’s PAM libraries and the client. It was
  designed to support custom forms of authentication such as two-factor
  without modifying the SSH protocol. By manipulating SSH client
  settings to force Keyboard-Interactive authentication to prompt for
  the username rather than sending it through normal means, an attacker
  can also pass unlimited input to the PAM   class="code">parse_user_name function.


 

Proof of Concept Exploit


 

In order to quickly test different versions of Solaris to see if
  they may be vulnerable, we developed a proof of concept exploit to
  trigger the overflow and crash the SSH server. The standard OpenSSH
  client offers all the options needed to trigger the vulnerability
  (Figure 2).


 


      src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/solaris/picture2.png" alt="" />
 
 Figure 2: A server can be quickly tested
    to see if it is vulnerable over SSH


 

The indication that the server is vulnerable is that the SSH client
  prints “Authentication failed;” a non-vulnerable PAM library causes
  the SSH server to repeatedly prompt for a username if it receives one
  that is too long. The overflow in the PAM library also causes the SSH
  server to crash, as shown in Figure 3. The operating system writes a
  crash dump to /core if the SSH server
  crashes with no debugger attached. In fact, if a   class="code">/core file exists on a Solaris machine and the
  file command reports that it is from sshd,
  those are indicators consistent with this vulnerability having been exploited.


 


      src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/solaris/picture3.png" alt="" />
 
 Figure 3: The SSH server crashes in the
    parse_user_name function


 

Vulnerable Operating Systems


 
 

Mitigations and Workaround


 

A patch from Oracle for Solaris 10 and 11 is described in the     href="https://www.oracle.com/security-alerts/cpuoct2020.html#AppendixSUNS">October
    2020 Critical Patch Update.


 

Because Solaris 9 is no longer supported, Oracle has not released a
  patch. For Solaris 9, as well as Solaris 10 or 11 systems where
  patching is inconvenient, we recommend editing the   class="code">/etc/ssh/sshd_config file to add the lines     class="code">ChallengeResponseAuthentication no and     class="code">KbdInteractiveAuthentication no and restart the
  SSH server. While this removes the opportunity to exploit the
  vulnerability using SSH Keyboard-Interactive authentication, there may
  be other ways to attack the parse_user_name
  function and we recommend using this workaround only as a stopgap
  until Solaris 9 systems can be upgraded, or the October patch can be
  accessed and installed for supported Solaris versions.


 

Acknowledgements


 

Jeffrey Martin of Rapid7 contributed to the testing of this vulnerability.


Source: In Wild Critical Buffer Overflow Vulnerability in Solaris Can Allow
Remote Takeover — CVE-2020-14871 (http://)