From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Dennis Subject: Re: [PATCH 1/2] audit: fix NUL handling in untrusted strings Date: Thu, 11 Sep 2008 15:19:49 -0400 Message-ID: <48C96F55.3080102@redhat.com> References: <1221085418.2705.19.camel@amilo> <48C955C8.2000602@redhat.com> <1221156612.17533.14.camel@amilo> <200809111508.13658.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0351136464==" Return-path: In-Reply-To: <200809111508.13658.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com, viro@zeniv.linux.org.uk, linux-kernel List-Id: linux-audit@redhat.com This is a multi-part message in MIME format. --===============0351136464== Content-Type: multipart/alternative; boundary="------------030301040803040004050501" This is a multi-part message in MIME format. --------------030301040803040004050501 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Steve Grubb wrote: > On Thursday 11 September 2008 14:10:12 Miloslav Trma=C4=8D wrote: > =20 >>> As a side note I'm concerned there may be places in the user audit >>> code which treat string data as null terminated (at least that is my >>> recollection). >>> =20 >> Yes, auditd adds a NUL terminator to the audit record, and then treats >> it as a regular NUL-terminated string; if the audit record contains an >> embedded NUL byte, the rest of the record is discarded by auditd. >> =20 > > In every case where this occurs (kernel or user space), the field value= s are=20 > expected to be encoded to prevent it from being discarded. > =20 This is true. The proposed patch defeats the encoding of the entire data=20 block and thus fails the criteria Steve correctly states is a requirement= . The concern I have in the user level audit code is not with handling the=20 encoded string values which is fine, but rather with the handling the=20 decoded string block. --=20 John Dennis --------------030301040803040004050501 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Steve Grubb wrote:

On Thursday 11 September 2008 14:10:12 Miloslav Trma=C4=8D=
 wrote:

As a side note I'm concerned there may be places in =
the user audit
code which treat string data as null terminated (at least that is my
recollection).

Yes, auditd adds a NUL terminator to the audit record,=
 and then treats
it as a regular NUL-terminated string; if the audit record contains an
embedded NUL byte, the rest of the record is discarded by auditd.


In every case where this occurs (kernel or user space), the field values =
are=20
expected to be encoded to prevent it from being discarded.

This is true. The proposed patch defeats the encoding of the entire data block and thus fails the criteria Steve correctly states is a requirement.

The concern I have in the user level audit code is not with handling the encoded string values which is fine, but rather with the handling the decoded string block.

--=20
John Dennis <jdennis@redhat.com>

--------------030301040803040004050501-- --===============0351136464== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0351136464==--