Message-ID: <20060820020417.GA17450@openwall.com>
Date:	Sun, 20 Aug 2006 06:04:17 +0400
From:	Solar Designer <solar@...nwall.com>
To:	Willy Tarreau <wtarreau@...a.kernel.org>
Cc:	linux-kernel@...r.kernel.org
Subject: [PATCH x7] misc fixes from 2.4.33-ow1

Willy and all,

Attached are 7 small changes from 2.4.33-ow1, as separate patches.  I do
not feel that these warrant separate messages.

linux-2.4.33-ow1-BAD_ADDR.diff

This one is a one-liner, in binfmt_elf.c:

-#define BAD_ADDR(x)	((unsigned long)(x) > TASK_SIZE)
+#define BAD_ADDR(x)	((unsigned long)(x) >= TASK_SIZE)

I feel that it is more logical to have BAD_ADDR() defined in this way:
indeed, the first kernel-space address is unusable for userspace.  I
don't think this change affects anything, and we had it in -ow for a
couple of years.

linux-2.4.33-ow1-create_elf_tables.diff
linux-2.4.33-ow1-elf_core_dump.diff

These two are pieces from my more elaborate version of the coredump
vulnerability fix:

	http://www.isec.pl/vulnerabilities/isec-0023-coredump.txt

The first one does for env_end the same thing that the minimal fix did
for arg_end, and the second one makes things more correct for 64-bit
archs.  Neither fixes any known security problem, although I would not
be surprised if there's a yet unexplored attack vector that uses env_end.
This has been in -ow for over a year.

linux-2.4.33-ow1-load_elf_library.diff

This rejects ELF libraries with elf_ex.e_phnum == 0 earlier in the code.
Without this change, such libraries would be rejected anyway - after a
kmalloc() and a kernel_read(), both of zero bytes.  This has been in -ow
for almost two years.

linux-2.4.33-ow1-mremap-arch-sanity.diff

This makes 32-bit emulation mmap/mremap calls on 64-bit archs refuse to
accept/return addresses beyond the 32-bit user address space.  This is
about correctness, not security.  Andrea Arcangeli did not like these,
commenting on them like: "supeflous, reject, must BUG if something", to
which I replied:

I don't see how these architecture-specific checks are superfluous.
The non-arch-specific code has only checked against TASK_SIZE, not
against the lower limit present with 32-bit syscall emulation on
64-bit archs.  Yes, with other checks in the arch-specific code, my
added checks are pretty much limited to just the special case of
addr == end, but such addr's are invalid under 32-bit syscall
emulation and should not be accepted/returned by syscalls.

BUG() would be wrong, it would introduce a DoS.

(That discussion occurred in December, 2003; I kept the changes in -ow
since then.)

linux-2.4.33-ow1-proc_file_read.diff

This is hardening of proc_file_read() similar to what was recently done
in 2.6 in response to the vulnerability discovery.  While 2.4 kernels
were not vulnerable due to differences in the lseek implementation, I
prefer to harden the reads as well.  This change is new with 2.4.33-ow1.

linux-2.4.33-ow1-proc-nosuid-noexec-nodev.diff

This attempts to make procfs MS_NOSUID | MS_NOEXEC | MS_NODEV by
default, in response to another recently discovered 2.6-specific
vulnerability (so for 2.4 this is just proactive hardening).  Most of
the changes in this patch were in -ow patches for years (in order to
enable the uid= and gid= mount options to work).  Only the specific
"s->s_flags |= ..." line is a recent addition, and this one has not yet
been tested to actually make a difference.

Thanks,

Alexander

View attachment "linux-2.4.33-ow1-BAD_ADDR.diff" of type "text/plain" (375 bytes)

View attachment "linux-2.4.33-ow1-create_elf_tables.diff" of type "text/plain" (509 bytes)

View attachment "linux-2.4.33-ow1-elf_core_dump.diff" of type "text/plain" (691 bytes)

View attachment "linux-2.4.33-ow1-load_elf_library.diff" of type "text/plain" (649 bytes)

View attachment "linux-2.4.33-ow1-mremap-arch-sanity.diff" of type "text/plain" (1945 bytes)

View attachment "linux-2.4.33-ow1-proc_file_read.diff" of type "text/plain" (739 bytes)

View attachment "linux-2.4.33-ow1-proc-nosuid-noexec-nodev.diff" of type "text/plain" (2707 bytes)

Powered by blists - more mailing lists