Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-39955

audisp-af_unix behavior change in binary mode compared to builtin version

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • rhel-10.0
    • rhel-10.0
    • audit
    • None
    • rhel-sst-security-special-projects
    • ssg_security
    • 16
    • None
    • False
    • Hide

      None

      Show
      None
    • No
    • Red Hat Enterprise Linux
    • SECENGSP Cycle 4
    • None
    • None
    • Unspecified Release Note Type - Unknown
    • None

      Originates from bz2273726:

      In Audit 3.1 and prior, for af_unix plugin in binary mode, data is copied over in full event frame, ie 16 bytes of header + 8970 bytes of buffer body, directly into the UDS client.
       
      If UDS client doesn't exist, the full event frame is dropped, this means whenever a client connect, it will always receive aligned event data, ie read from byte 0. This behavior is the same as if client is reading directly from the audit netlink socket.

      In Audit 3.1.1, a standalone util audisp-af_unix is created to replace the builtin af_unix plugin, where full event frame is copied into audisp-af_unix's stdin, audisp-af_unix only read 8970-1 bytes at a time, and copy successfully read bytes into UDS client.
       
      When client doesn't exist, the read bytes are dropped, but since there is a mismatch between read size(8970-1) and the write size(16+8970), when client connect to UDS, the data received isn't aligned, and there is no reliable way for the client to tell where real event data should start at. For example, assume the client connects after the second time audit_fgets read data off stdin, the client will receive data with the trailing 17 bytes of a previous event buffer, then begins the next event. 

      This can be fixed by increase the buffer used for audit_fgets to fill by 17 bytes, ie, aligning the read frame size with the write frame size, so that whenever a client read from the UDS in binary mode, the event data is always aligned and can be consumed from byte 0. A simple patch is attached below:

       

      diff --git a/audisp/plugins/af_unix/audisp-af_unix.c b/audisp/plugins/af_unix/audisp-af_unix.c
      index ffbf2ac0..483903be 100644
      --- a/audisp/plugins/af_unix/audisp-af_unix.c
      +++ b/audisp/plugins/af_unix/audisp-af_unix.c
      @@ -49,7 +49,7 @@
       
       /* Global Data */
       static volatile int stop = 0, hup = 0;
      -char rx_buf[MAX_AUDIT_MESSAGE_LENGTH];
      +char rx_buf[MAX_AUDIT_MESSAGE_LENGTH + sizeof(struct audit_dispatcher_header) + 1];//1 extra byte for null terminator
       int sock = -1, conn = -1, client = 0;
       struct pollfd pfd[3];
       unsigned mode = 0;

      Reproducible: Always

      Steps to Reproduce:
      1. configure auditd 3.1.1+ to use audisp-af_unix plugin in binary mode
      2. generate some audit events
      3. read from the UDS socket: e.g. nc -U /var/run/audispd-events -x out.bin
      4. generate some more audit events and check results in the out.bin file
      Actual Results:  
      Notice the data in the output is not aligned with event header at byte 0

      Expected Results:  
      Event header should be starting from byte 0, ie exactly as if the client is reading from the audit netlink socket directly

      This happens on all system with auditd 3.1.1+, we have currently observe these in Fedora 39, Fedora 40, and Ubuntu 23.10

      String mode works fine generally, as the string events are not as big, and can recover easily as newline char serves as a means to re-align. But technically can happen if the string size is bigger than 8970-1.

      This issue gives no recourse for apps that depend on binary mode other than switch over impl to use string mode. For security apps captures events using binary mode, it results in data loss as events fail to parse correctly.

              rh-ee-alakatos Attila Lakatos
              rh-ee-alakatos Attila Lakatos
              Sergio Correia Sergio Correia
              SSG Security QE SSG Security QE
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: