Nulls embedded in Cisco-AVPairs

[Brian Weis (bew)]

Hi folks,

I'm trying to do a regular expression match on a Cisco-AVPair value that is sent by the NAD in an Accounting-Request message. He’s a sample of the configuration using the suggested “foreach” method. I’ve added it to the accounting{} section of sites-available/default.

     foreach &Cisco-AVPair { 
          if (Foreach-Variable-0 =~ /raspberrypi/) { 
              update { 
                  &Url-Name := "getaclname"
                  &Url-DataType := "MAC_ADDR"
                  &Url-Data := "%{Foreach-Variable-0}"
              } 
              rest
       }

However, some of the Cisco-AVPairs we’re wanting to parse contain zeros in the value, such as 

	Cisco-AVPair = "lldp-tlv=\000\005\000\013raspberrypi"

Note that the print function above is translating the bytes to an octal format, so \000 is really 0x00 in memory.

The zeros in the attribute interfere with the regular expression processing.The line proceeded with a hash prints the entire value representing non-printable octets with octal representations (as above), but the regular expression processing stops at the first zero (e.g., following 'lldp-tlv=’ in the example string), obviously interpreting the zero as the string termination null.  This is shown in this log. Note that following EXPAND X that the reported string has been truncated.

      foreach &Cisco-AVPair {
      # Foreach-Variable-0 = "lldp-tlv=\000\005\000\013raspberrypi"
 {
        EXPAND %{Foreach-Variable-0}
          %{Foreach-Variable-0}
          Parsed xlat tree:
            virtual --> Foreach-Variable-0
          EXPAND X Foreach-Variable-0
             --> lldp-tlv=
        --> lldp-tlv=
     ...
 }    

Looking in the code, I see that both the full and trunctated log entries are the output of fr_pair_value_snprint(). The call that display the full value specifies ‘“‘ as a quote value, which results in it representing the non-printable characters as octal values. But the call that creates a string for regular expression processing (the EXPAND X string) specifies no quote value, which results in a string truncated at the first zero byte. Note that not only is the value shorted in the log above, but the regular expression processing uses this string as well. This effectively doesn’t allow regular expression processing matching strings following the zero in the value.

This truncation seems to be because some regular expression libraries do not safely process nulls. These are messages I received when changing the quote variable to ‘“' for debugging purposes:

ERROR : (57)      regex failed: Found null in subject at offset 9.  String unsafe for evaluation
ERROR : (57)      Condition evaluation failed because the value of an operand could not be determined

I’ve tried many different string representations in the code snippet above and nothing  changes this behavior. But I also can’t find a way to  transform Foreach-Variable-0 such that it can be given to another module for processing … always the fr_pair_value_snprint() call with a zero quote value in is used, which truncates the string. This is the call in in xlat_foreach().

There is a FreeRADIUS compile option to use regex code where nulls are safe within the value (i.e., regnexec), which would seem to avoid the message above. But that does not seem sufficient as the current code in xlat_foreach() would still provide a truncated string to the regex library.

Suggestions for a workaround?

I’m using FreeRADIUS 3.1.0.

Thanks,
Brian

-- 
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: bew at cisco.com