Question regarding EventData attribute names clashing Output Runtimes

[nflexfo]

Hi,

While reviewing the new data types introduced in version 20240826, I've noticed that some of them had attributes names that might clash with output runtime fields. For instance, teamviewer:connections_incoming:entry re-defines display_name, or cri:container:log:entry re-defines tag.

Based on the documentation, I expect this field to be a "Human readable representation of the path specification". It is true for almost any data type but a few (see below). In this particular case, the pydoc says "The display name of the incoming connection source. Usually the computer name or the TeamViewer user name.".

During investigation, it is common to rely on this field to retrieve the original artifact path and starts searching from here. Now, since the parser overwrite it with something else, we need to find another way to get the same information. This issue actually strikes me back some years ago with windows:registry:usbstor:instance but then I forgot about it.

Curious about what other clashes might exist, I've wrote this small scripts.

Here is the result of output runtime fields to data type being clashed:

{
    "description": [
        "android:twitter:contact",
        "av:symantec:scanlog",
        "ios:twitter:contact",
        "mackeeper:cache",
        "macos:startup_item:entry",
        "opera:history:entry",
        "windows:lnk:link",
        "windows:pca_log:entry",
        "windows:registry:network",
        "windows:restore_point:info",
        "windows:timeline:generic"
    ],
    "display_name": [
        "fs:stat",
        "fs:stat:ntfs",
        "skype:event:account",
        "spotlight_searched_terms:entry",
        "teamviewer:connections_incoming:entry",
        "windows:registry:usbstor:instance"
    ],
    "filename": [
        "av:defender:detection_history",
        "av:mcafee:accessprotectionlog",
        "av:trendmicro:scan",
        "fs:bodyfile:entry",
        "fs:ntfs:usn_change",
        "fs:stat",
        "fs:stat:ntfs",
        "gcp:log:entry",
        "kodi:videos:viewing",
        "networkminer:fileinfos:file",
        "viminfo:history"
    ],
    "host": [
        "android:webview:cookie",
        "azure:application_gateway_access:entry",
        "chrome:cookie:entry",
        "firefox:cookie:entry",
        "firefox:places:bookmark",
        "firefox:places:page_visited",
        "safari:history:visit_sqlite"
    ],
    "hostname": [
        "linux:utmp:event",
        "macos:utmpx:entry",
        "olecf:dest_list:entry",
        "syslog:cron:task_run",
        "syslog:line",
        "syslog:ssh:failed_connection",
        "syslog:ssh:login",
        "syslog:ssh:opened_connection",
        "systemd:journal",
        "windows:user_access_logging:dns"
    ],
    "inode": [
        "fs:bodyfile:entry",
        "fs:stat"
    ],
    "message": [
        "android:logcat",
        "chrome:preferences:extensions_autoupdater",
        "gcp:log:entry",
        "google_drive_sync_log:entry",
        "googlelog:log",
        "macos:asl:entry",
        "macos:securityd_log:entry",
        "snort:fastlog:alert"
    ],
    "source": [
        "skype:event:transferfile"
    ],
    "tag": [
        "cri:container:log:entry"
    ],
    "time": [
        "av:symantec:scanlog"
    ],
    "type": [
        "firefox:downloads:download",
        "firefox:places:bookmark",
        "linux:utmp:event",
        "macos:utmpx:entry",
        "windows:registry:mount_points2"
    ],
    "user": [
        "av:symantec:scanlog",
        "cups:ipp:event",
        "gcp:log:entry",
        "postgresql:application_log:entry",
        "santa:execution",
        "santa:file_system_event"
    ],
    "username": [
        "android:twitter:contact",
        "android:twitter:status",
        "av:mcafee:accessprotectionlog",
        "ios:kik:messaging",
        "linux:utmp:event",
        "macos:user:entry",
        "macos:utmpx:entry",
        "pls_recall:entry",
        "powershell:transcript_log:entry",
        "skype:event:account",
        "syslog:cron:task_run",
        "syslog:line",
        "syslog:ssh:failed_connection",
        "syslog:ssh:login",
        "syslog:ssh:opened_connection",
        "windows:registry:mstsc:connection",
        "windows:registry:sam_users",
        "windows:tasks:job",
        "windows:tasks:trigger"
    ]
}

If you prefer a data type to runtime type view, here it is. Note that most of those clashes come from the "Dynamic Runtime Fields" which is what I'm stuck with for now (will transition to json eventually).

In some cases, it totally makes sense. For instance inode in fs:stat. On the other hand, it is more questionable like display_name, tag, type, user or username.

What's your though about it? Is "reserved attribute names" a thing in Plaso? Should we expect field to have a consistent meaning across several data types? At least, those defines by output runtime. Or is it an overlook that should be addressed?

Thanks,

Nicolas.