Stable kernel 2.6.25.10

Greg,

you probably misunderstood me. i do *not* care about the disclosure policy you choose (*that*
discussion is something *you* kernel devs have to have, i have zero influence on it). what i
do care about is that once you decided it, you stick to it and when you don't (remember, it's
supposedly still 'full disclosure' as of now), i'll point it out. in any case, if you really
really want me to get involved in all this (i very much doubt you do, but you can prove
yourself now), start that thread yourself and CC spender and me.

> > instead of witchhunting on vendor-sec
> I'm confused, what do you mean by this?

make the vendor-sec archives public and i'll explain. deal? ;)

> Once again, if you have any comments, questions, or concerns about how I
> and the other kernel developers are handling the -stable updates and
> notifications, please do so on the linux-kernel mailing list and I will
> be very glad to discuss them there, in public.

so, i did just that yesterday. note that you might want to fix your spam filters because i
didn't see my mail show up in the archives nor did i get a bounce. but at least the
individuals on CC (yourself included) should have got it. for reference for others in case it
doesn't make it into the archives:

On 3 Jul 2008 at 11:57, Greg KH wrote:

> On Thu, Jul 03, 2008 at 10:29:14AM -0700, Greg KH wrote:
> Adding 2 more addresses to this thread, as they were said to have
> questions about this kernel release.

not only this one, but every commit for the past few years that fixed
bugs with security impact. for reference:

http://lwn.net/Articles/285438/
http://lwn.net/Articles/286263/
http://lwn.net/Articles/287339/
http://lwn.net/Articles/288473/

> Again, if the above information is somehow insufficient as to what
> exactly is fixed in the -stable releases, and anyone has questions about
> how these release announcements are created, please let me know.

what is the disclosure policy used for commits fixing bugs with security
impact (both vanilla and -stable, especially if there's a difference)?

what do you include/omit?

how does it relate to what is declared in Documentation/SecurityBugs?

i'm not sure you entirely understand this whole userland/kernel separation thing and the issue
of privilege elevation. the short story is that your CPU offers privileged instructions and a
corresponding privileged operation mode (or modes) that are, well, privileged, not meant to be
executed by normal userland because of their impact on the security model implemented by the
kernel. think of, say, page table manipulation, modifying credentials information stored in
kernel (read: privileged) memory, etc. if there is a bug in privileged code that userland can
abuse in order to elevate its own privilege then that is called a security problem and people
*do* care about them (whether you personally care about such security problems is your
business of course, but you don't get to tell what others care about). since not all kernel
bugs can be abused for privilege elevation, it is very important and in accordance with the
disclosure policy declared by the kernel devs to disclose such information.

If they're in an array of structures and you can integer-overflow the 
array index, suddenly they're dangerous again.

> null function pointers are only exploitable if vm.mmap_min_addr is zero,

no, if a process has CAP_SYS_RAWIO it can also evade the 0 mmap restriction (and let's ignore
the early implementation bugs of this feature). if a process doesn't yet have CAP_SYS_RAWIO,
it can 'acquire' it by exploiting another that does have it (think of X for example or any
suid root process). or alternatively, one has to use SELinux and make sure no process can be
granted MEMPROTECT__MMAP_ZERO. and all of this breaks valid userland programs, so it's not a
universal solution (it's default off for that reason).

> which should not be the case on most installations.

any statistics to back it up? remember, it needs both CONFIG_SECURITY and be set to some
meaningful value.

in any case, i'm not sure what you were trying to say, if a bug falls into a known exploitable
bug class then it should be reported as such (or briefly explained why it's not what it looks
like), regardless of what mitigation factors may apply in a given installation. such info
belongs to vendor advisories at most, not a kernel commit message.

> I imagine getting 4G references on a task_struct would be hard without
> root privileges.

the patch fixes a few ptrace commands that can be issued by any user, not only root. therefore
it's triggerable and exploitable by any user who's not otherwise prevented from using ptrace.
as for the technical feasibility of issuing 4G ptrace calls, on a core2 a single GETREGS takes
less than 30 usec, that's less than 2 days of runtime.