From: "Miloslav Trmač" <mitr@redhat.com>
To: John Dennis <jdennis@redhat.com>
Cc: linux-audit <linux-audit@redhat.com>,
viro@zeniv.linux.org.uk,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] audit: fix NUL handling in untrusted strings
Date: Thu, 11 Sep 2008 20:10:12 +0200 [thread overview]
Message-ID: <1221156612.17533.14.camel@amilo> (raw)
In-Reply-To: <48C955C8.2000602@redhat.com>
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
data).
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.
TTY input auditing was the only place where it makes a difference, all
other code was passing a string that was at least as long as the
specified size to audit_log_n_untrustedstring().
> It seems to me the problem is with audit_string_contains_control():
>
> int audit_string_contains_control(const char *string, size_t len)
> {
> const unsigned char *p;
> for (p = string; p < (const unsigned char *)string + len && *p; p
> ++) {
> if (*p == '"' || *p < 0x21 || *p > 0x7e)
> return 1;
> }
> return 0;
> }
>
> The problem is that it is passed a counted octet sequence but in some
> circumstances ignores the count. This occurs when *p == 0, the test
> for NULL should be removed. If that test is removed it will return the
> flag which indicates the string must be encoded differently to be
> conformant with the protocol.
Yes, that's possible - but then audit_log_n_untrustedstring() would be
more accurately called audit_log_n_ascii_like_binary_data().
Anyway, Eric/Al - if you prefer this solution, I can prepare an
alternative patch.
> 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.
Mirek
WARNING: multiple messages have this Message-ID (diff)
From: "Miloslav Trmač" <mitr@redhat.com>
To: John Dennis <jdennis@redhat.com>
Cc: Eric Paris <eparis@redhat.com>,
linux-audit <linux-audit@redhat.com>,
viro@zeniv.linux.org.uk,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] audit: fix NUL handling in untrusted strings
Date: Thu, 11 Sep 2008 20:10:12 +0200 [thread overview]
Message-ID: <1221156612.17533.14.camel@amilo> (raw)
In-Reply-To: <48C955C8.2000602@redhat.com>
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
data).
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.
TTY input auditing was the only place where it makes a difference, all
other code was passing a string that was at least as long as the
specified size to audit_log_n_untrustedstring().
> It seems to me the problem is with audit_string_contains_control():
>
> int audit_string_contains_control(const char *string, size_t len)
> {
> const unsigned char *p;
> for (p = string; p < (const unsigned char *)string + len && *p; p
> ++) {
> if (*p == '"' || *p < 0x21 || *p > 0x7e)
> return 1;
> }
> return 0;
> }
>
> The problem is that it is passed a counted octet sequence but in some
> circumstances ignores the count. This occurs when *p == 0, the test
> for NULL should be removed. If that test is removed it will return the
> flag which indicates the string must be encoded differently to be
> conformant with the protocol.
Yes, that's possible - but then audit_log_n_untrustedstring() would be
more accurately called audit_log_n_ascii_like_binary_data().
Anyway, Eric/Al - if you prefer this solution, I can prepare an
alternative patch.
> 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.
Mirek
next prev parent reply other threads:[~2008-09-11 18:10 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-10 22:23 [PATCH 1/2] audit: fix NUL handling in untrusted strings Miloslav Trmač
2008-09-11 14:25 ` Eric Paris
2008-09-11 14:25 ` Eric Paris
2008-09-11 14:43 ` Miloslav Trmač
2008-09-11 14:43 ` Miloslav Trmač
2008-09-11 17:30 ` John Dennis
2008-09-11 18:10 ` Miloslav Trmač [this message]
2008-09-11 18:10 ` Miloslav Trmač
2008-09-11 18:15 ` Miloslav Trmač
2008-09-11 19:08 ` Steve Grubb
2008-09-11 19:08 ` Steve Grubb
2008-09-11 19:19 ` John Dennis
2008-09-11 19:12 ` John Dennis
2008-09-11 19:27 ` Miloslav Trmač
2008-09-11 19:27 ` Miloslav Trmač
2008-09-11 19:47 ` John Dennis
2008-09-11 20:03 ` Miloslav Trmač
2008-09-11 20:03 ` Miloslav Trmač
2008-09-11 19:14 ` Andrew Morton
2008-09-11 19:14 ` Andrew Morton
2008-09-11 19:37 ` Miloslav Trmač
2008-09-11 19:37 ` Miloslav Trmač
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1221156612.17533.14.camel@amilo \
--to=mitr@redhat.com \
--cc=jdennis@redhat.com \
--cc=linux-audit@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.