Ugly logs

Over at the LogAnalysis mailing list a pseudo contest is being held. A lot of the log snippets posted really is ugly, funny and useless. A particular log snippet from Novell OES 2 Linux's Lightweight/Linux Auditing Framework is being ridiculed: Novell_OES2_LAF_log.txt.

I admit that it is ugly but it is far from useless. I find the information provided quite readable and verbose. There must be switch to make less verbose. I think the following is not really useful:

• arch
• a0
• a1
• a2
• a3
• items
• subj
• key

The format needs improvement, I guess it was formatted that way for easier parsing by shell utilities such as AWK. Splitting it into multiple lines grouped by type e.g. guid, uid, eid and with a marker for easier specific host identification is definitely much better.

If you are wondering why would anyone want detailed logs like that. From a security standpoint it is good practice to monitor users/directory/file/application access and of course compliance to SOX Section sec 302(a)(5) and the like.

Segmentation fault logging

A few days ago I updated my notebook to Linux 2.6.23. While trying to create exploits for the recently reported VLC buffer overflow and format string vulnerabilities I saw an unfamiliar message in the kernel logs.

vlc[6061]: segfault at a401f000 eip 41414141 esp a3ff5888 error 7

I remember seeing a similar message from an x86_64 machine. Could it be that segfault logging was ported to i386?.

Visited the Linux gitweb interface but I can not seem to find the exact commit. In x86_64 the code snippet that does the logging is at arch/x86_64/mm/fault.c.

if (exception_trace && unhandled_signal(tsk, SIGSEGV)) {
             printk(
             "%s%s[%d]: segfault at %016lx rip %016lx rsp %016lx error %lx\n",
                              tsk->pid > 1 ? KERN_INFO : KERN_EMERG,
                              tsk->comm, tsk->pid, address, regs->rip,
                              regs->rsp, error_code);
}

In i386 it is at arch/i386/mm/fault.c.

if (show_unhandled_signals && unhandled_signal(tsk, SIGSEGV) &&
          printk_ratelimit()) {
              printk("%s%s[%d]: segfault at %08lx eip %08lx "
                  "esp %08lx error %lx\n",
                  tsk->pid > 1 ? KERN_INFO : KERN_EMERG,
                  tsk->comm, tsk->pid, address, regs->eip,
                  regs->esp, error_code);
}

Confirmed, userspace segmentation faults are now logged by the kernel. This also exhibits the difference between i386 and x86_64 registers.