Some auditd Data Corrupted After 8.4.0 Upgrade

Elastic Stack Beats
1

I'm seeing some records created from auditd including corrupt data after upgrading to 8.4.0. This are fine after downgrading back to 8.3.3.

For example, with minimal config:

auditbeat.modules:
- module: auditd
  include_raw_message: true
output.file:
  path: "/tmp"
  filename: auditbeat

8.4.0 produces records like this:

{
    "@timestamp": "2022-08-26T00:00:00.000Z",
    "@metadata": {
        "beat": "auditbeat",
        "type": "_doc",
        "version": "8.4.0"
    },
    "host": {
        "name": "[redacted]"
    },
    "ecs": {
        "version": "8.0.0"
    },
    "auditd": {
        "summary": {
            "actor": {
                "primary": "unset",
                "secondary": "root"
            },
            "object": {
                "primary": "A",
                "type": "user-session"
            }
        },
        "result": "success",
        "data": {
            ":se": "sion_o",
            "en gran": "ors=pam_lo"
        },
        "session": "d,pa",
        "message_type": "login",
        "sequence": 5678
    },
    "user": {
        "effective": {
            "id": "A",
            "name": "root"
        },
        "selinux": {
            "user": "=unconfined"
        },
        "audit": {
            "id": "A",
            "name": "root"
        }
    },
    "agent": {
        "ephemeral_id": "[redacted]",
        "id": "[redacted]",
        "name": "sole",
        "type": "auditbeat",
        "version": "8.4.0"
    },
    "related": {
        "user": [
            "root"
        ]
    },
    "service": {
        "type": "auditd"
    },
    "process": {
        "pid": 12345
    },
    "event": {
        "module": "auditd",
        "category": [
            "authentication"
        ],
        "action": "changed-login-id-to",
        "outcome": "success",
        "original": [
            "type=LOGIN msg=audit(1661472000.000:5678): pid=12345 uid=0 subj==unconfined old-auid=4294967295 auid=0 tty=(none) old-ses=4294967295 ses=1234 res=1"
        ],
        "kind": "event",
        "type": [
            "start"
        ]
    }
}

while 8.3.3 produces for a similar event (compare event.original):

{
    "@timestamp": "2022-08-26T00:00:00.000Z",
    "@metadata": {
        "beat": "auditbeat",
        "type": "_doc",
        "version": "8.3.3"
    },
    "host": {
        "name": "[redacted]"
    },
    "ecs": {
        "version": "8.0.0"
    },
    "auditd": {
        "summary": {
            "actor": {
                "primary": "unset",
                "secondary": "root"
            },
            "object": {
                "primary": "0",
                "type": "user-session"
            }
        },
        "result": "success",
        "data": {
            "tty": "(none)",
            "old-ses": "4294967295"
        },
        "session": "1234",
        "message_type": "login",
        "sequence": 5678
    },
    "user": {
        "effective": {
            "id": "0",
            "name": "root"
        },
        "selinux": {
            "user": "=unconfined"
        },
        "audit": {
            "id": "0",
            "name": "root"
        }
    },
    "agent": {
        "ephemeral_id": "[redacted]",
        "id": "[redacted]",
        "name": "sole",
        "type": "auditbeat",
        "version": "8.3.3"
    },
    "related": {
        "user": [
            "root"
        ]
    },
    "service": {
        "type": "auditd"
    },
    "process": {
        "pid": 12345
    },
    "event": {
        "module": "auditd",
        "category": [
            "authentication"
        ],
        "action": "changed-login-id-to",
        "outcome": "success",
        "original": [
            "type=LOGIN msg=audit(1661472000.000:5678): pid=12345 uid=0 subj==unconfined old-auid=4294967295 auid=0 tty=(none) old-ses=4294967295 ses=1234 res=1"
        ],
        "kind": "event",
        "type": [
            "start"
        ]
    }
}

Note the munged data in auditd.data and auditd.session, as well as user.audit.id, user.effective.id and others. (Also note data was cleansed for privacy and easy comparison.) Not all events or event types show these errors.

Interestingly the bad data seems to come not from this event but from different events, like the "en gran": "ors=pam_lo" in auditd.data coming from an event with grantors=pam_loginuid,pam_env,pam_env,pam_permit,pam_unix,pam_limits, but clearly not the event currently being reported. It's as if there is some issue with clearing variables between events, possibly related to [Auditbeat] Upgrade to go-libaudit v2.3.1 by andrewkroh · Pull Request #32421 · elastic/beats · GitHub, in particular https://github.com/elastic/go-libaudit/pull/111 or Use go-shellquote to split rules into arguments by andrewkroh · Pull Request #115 · elastic/go-libaudit · GitHub, both changed in 8.4.0.

This is running on Debian 11.4.

1 Like
2

Hi @CraigHolyoak. Apologies for the issue you've ran into with the 8.4 upgrade. We've already implemented a fix (see here), which will be included in an upcoming 8.4.1 release.

3

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.