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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <1221161260.17533.30.camel@amilo>
Date:	Thu, 11 Sep 2008 21:27:40 +0200
From:	Miloslav Trmač <mitr@...hat.com>
To:	John Dennis <jdennis@...hat.com>
Cc:	Eric Paris <eparis@...hat.com>,
	linux-audit <linux-audit@...hat.com>, viro@...iv.linux.org.uk,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] audit: fix NUL handling in untrusted strings

John Dennis píše v Čt 11. 09. 2008 v 15:12 -0400:
> 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
> > data). 
> >   
> 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.
If the interface says "NUL-terminated string", any bytes after that are
not "actual data".  The bytes might be useful for diagnosing an anomaly
if the kernel's behavior somehow depended on the bytes after NUL due to
a kernel bug - but the kernel's behavior might depend on anything due to
such a bug, and we don't log the complete state of the system in each
audit message.  The "actual data" of a string is only up to the NUL
byte.

> 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.
Yes, that's why it was wrong to use audit_*string() for TTY input data.
And the 2/2 patch fixes it - at the source of the problem, not in an
unrelated function that was incorrectly used.
	Mirek

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/