Not supported "uint32be" condition in yara rules

[NetVicious]

The internal library on LibClamAV related to yara rules seems to be non-updated to the current one.

I use some rules with a uint32be condition which it doesn't supports:

LibClamAV Error: yyerror(): /var/lib/clamav/yara_2.yar line 248 undefined identifier "uint32be"
LibClamAV Warning: cli_loadyara: failed to parse or load 4 yara rules from file /var/lib/clamav/yara_2.yar, successfully loaded 10 rules.

Looking at the yara documentation this identifier should be supported:
https://yara.readthedocs.io/en/v3.5.0/writingrules.html#conditions

1)
Description: Ubuntu 20.04 LTS
Release: 20.04

2)
libclamav9:
  Instalados: 0.102.3+dfsg-0ubuntu0.20.04.1
  Candidato: 0.102.3+dfsg-0ubuntu0.20.04.1
  Tabla de versión:
 *** 0.102.3+dfsg-0ubuntu0.20.04.1 500
        500 http://es.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages
        100 /var/lib/dpkg/status
     0.102.2+dfsg-2ubuntu1 500
        500 http://es.archive.ubuntu.com/ubuntu focal/main amd64 Packages

3) ClamAV should load correctly the yara rule
4) Rule not loaded due to reported error.

[Paride Legovini (paride)]

Hello and thanks for taking the time to report this bug. In order to drive this forward we some more things from your side:

0. Can you please double check your yara_2.yar is valid? The error your report is:

  undefined identifier "uint32be"

but the documentation you linked says "The following keywords are reserved and cannot be used as an identifier:" and follows listing "uint32be" as one of these keywords. This makes me suspect your yara file has syntax issues.

1. Is this a regression, or is this the first time you try to setup ClamAV with yara rules? In other words: did you upgrade an existing, working Ubuntu system to 20.04 and hit the issue, or did you hit it while setting up a system up from scratch?

2. Can you share your yara_2.yar file and outline how you setup ClamAV for using it? Ideally we need the minimal set of steps to setup a system which will hit the problem you described.

I'm marking this report as Incomplete for the moment. Please change its status back to New after commenting back and we'll look at it again. Thanks!

[Launchpad Janitor (janitor)]

[Expired for clamav (Ubuntu) because there has been no activity for 60 days.]

[NetVicious (netvicious)]

I'm sorry for not answer in time:

I'm using the yara rules to block malware on the SMTP server within spamassassin and clamd

These rules have the non supported uint32be

Regards,

rule packager_cve2017_11882 {
   meta:
      author = "Rich Warren"
      description = "Attempts to exploit CVE-2017-11882 using Packager"
      reference = "https://github.com/rxwx/CVE-2017-11882/blob/master/packager_exec_CVE-2017-11882.py"
      score = 60
   strings:
      $font = { 30 61 30 31 30 38 35 61 35 61 }
      $equation = { 45 71 75 61 74 69 6F 6E 2E 33 }
      $package = { 50 61 63 6b 61 67 65 }
      $header_and_shellcode = /03010[0,1][0-9a-fA-F]{108}00/ ascii nocase
   condition:
      uint32be(0) == 0x7B5C7274 // RTF header
      and all of them
}

rule CVE_2017_11882_RTF {
   meta:
      description = "Detects suspicious Microsoft Equation OLE contents as used in CVE-2017-11882"
      license = "https://creativecommons.org/licenses/by-nc/4.0/"
      author = "Florian Roth"
      reference = "Internal Research"
      date = "2018-02-13"
      score = 60
   strings:
      $x1 = "4d534854412e4558452068747470" /* MSHTA.EXE http */
      $x2 = "6d736874612e6578652068747470" /* mshta.exe http */
      $x3 = "6d736874612068747470" /* mshta http */
      $x4 = "4d534854412068747470" /* MSHTA http */

      $s1 = "4d6963726f736f6674204571756174696f6e20332e30" ascii /* Microsoft Equation 3.0 */
      $s2 = "4500710075006100740069006f006e0020004e00610074006900760065" ascii /* Equation Native */
      $s3 = "2e687461000000000000000000000000000000000000000000000" /* .hta .... */
   condition:
      ( uint32be(0) == 0x7B5C7274 or uint32be(0) == 0x7B5C2A5C ) /* RTF */
      and filesize < 300KB and
      ( 1 of ($x*) or 2 of them )
}

[NetVicious (netvicious)]

As you can see my file doesn't has syntax issues. The rules are using a condition which it's not supported by the compiled version on Ubuntu.

Check this URL https://yara.readthedocs.io/en/v3.5.0/writingrules.html and look for the "Accessing data at a given position" section. There appears uint32be it's a reserved function name.

[Paride Legovini (paride)]

Hi and thanks for the follow-up. As I understand this is a limitation of ClamAV's parser for YARA rules. If this is the case there's little we can do on the Ubuntu side to add support for it, and I'd suggest you to file a bug or feature request to ClamAV upstream.

This is what I deduced from some digging into issues and mailing list discussions, but I couldn't find a clear statement about uint32be not being supported, we still have a question mark here. Do you have reasons to expect uint32be to be supported by ClamAV?

(I am not familiar at all with YARA rules, but I assume that uint32be is a type cast to Unsigned Integer 32bit Big Endian. In your example above conditions like

  uint32be(0) == 0x7B5C7274

look like odd "always false" conditions to me, but again I don't really know.)

[Launchpad Janitor (janitor)]

[Expired for clamav (Ubuntu) because there has been no activity for 60 days.]