[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [PATCH 1/2] audit: fix NUL handling in untrusted strings

Miloslav Trmač wrote:
John Dennis píše v Čt 11. 09. 2008 v 13:30 -0400:
Special processing with regards to the presence or absence of a null
byte is one example of prohibited interpretation.
This is UNIX, "string" means "NUL-terminated string" (in fact the
presence of a NUL byte is the only way to reasonably detect binary

A primary purpose of the audit system is to log with the greatest accuracy possible the actual data. If that data somehow contained a null, even in a context in which a null would have been prohibited, the audit system absolutely needs to be able to correctly record that aberrant event and it's actual data. If the audit system failed at that moment it's failing at the worst possible moment, the moment when you're looking for bad data.

A UNIX-like operating system does not in and of itself mandate the default conventions of the C programming language. A great danger and the source of bugs is making assumptions concerning how to interpret octet sequences. By far and away the worst possible place to make a mistake handling an octet sequence is in the kernel. It would be wrong for the audit system to assume the memory block it was pointed to only ever contained null terminated ascii strings, especially when the memory block is terminated by virtue of an octet count.
You're far more likely to encounter a fixed-length field with an
optional terminating NUL (like the old-style, 16-byte directory entries)
than an ASCII-compatible string that intentionally contains a NUL byte.

John Dennis <jdennis redhat com>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]