Re: New do_mremap vulnerabitily.

Re: New do_mremap vulnerabitily.

[Ulrich Keil]

There was also a Proof-of-concept exploit released:

http://www.derkeiler.com/Mailing-Lists/Securiteam/2004-02/0052.html

Ulrich Keil
-- 
http://www.derkeiler.com
PGP Fingerprint: 5FA4 4C01 8D92 A906 E831  CAF1 3F51 8F47 1233 9AAD
Public key available at http://www.derkeiler.com/uk/pgp-key.asc

Re: New do_mremap vulnerabitily.

[Chris Friesen]

Ulrich Keil wrote:
> There was also a Proof-of-concept exploit released:
> 
> http://www.derkeiler.com/Mailing-Lists/Securiteam/2004-02/0052.html

Its a bit confusing.  They talk about multiple instances of do_munmap() 
with unchecked return codes.  I can only find one, in move_vma().

Chris




-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: New do_mremap vulnerabitily.

[Richard B. Johnson]

On Wed, 18 Feb 2004, Chris Friesen wrote:

> Ulrich Keil wrote:
> > There was also a Proof-of-concept exploit released:
> >
> > http://www.derkeiler.com/Mailing-Lists/Securiteam/2004-02/0052.html
>
> Its a bit confusing.  They talk about multiple instances of do_munmap()
> with unchecked return codes.  I can only find one, in move_vma().
>
> Chris
>

Except in some drivers, you seem to be (nearly) correct ......

For Linux version 2.4.24

(file-name __follows__ the function name)

EXPORT_SYMBOL(do_munmap);
./kernel/ksyms.c
		do_munmap(current->mm, addr, old_len);
		do_munmap(current->mm, new_addr, new_len);
		do_munmap(current->mm, addr+new_len, old_len - new_len);
./mm/mremap.c
		if (!do_munmap(mm, newbrk, oldbrk-newbrk))
		if (do_munmap(mm, addr, len))
		 * in the do_munmap, so FIXME (not in 2.4 to avoid breaking
int do_munmap(struct mm_struct *mm, unsigned long addr, size_t len)
	ret = do_munmap(mm, addr, len);
		if (do_munmap(mm, addr, len))
./mm/mmap.c
	 * do_munmap() behaves similarly, taking the range out of mm's
		 * exit_mmap() and do_munmap() cases described above:
./mm/swapfile.c
			do_munmap(mm, shmd->vm_start, shmd->vm_end - shmd->vm_start);
******---> ./ipc/shm.c


	if (do_munmap(current->mm, cont_mem.linear, size) != 0)
./drivers/char/drm/savage_drv.c
#define DO_MUNMAP(m, a, l)	do_munmap(m, a, l)
./drivers/char/drm/i830_dma.c
#define DO_MUNMAP(m, a, l)	do_munmap(m, a, l)
./drivers/char/drm/i810_dma.c
        	retcode = do_munmap(current->mm,
./drivers/char/drm-4.0/i810_dma.c
		do_munmap(current->mm, newbrk, oldbrk-newbrk);
./arch/sparc/kernel/sys_sunos.c
		do_munmap(mm, newbrk, oldbrk-newbrk);
./arch/mips/kernel/sysirix.c
		do_munmap(current->mm, newbrk, oldbrk-newbrk);
./arch/sparc64/kernel/sys_sunos32.c
	ret = do_munmap(current->mm, addr, len);
./arch/sparc64/kernel/sys_sparc.c
	r = do_munmap(task->mm, ctx->ctx_smpl_vaddr, psb->psb_size);
./arch/ia64/kernel/perfmon.c
		if (!do_munmap(mm, newbrk, oldbrk-newbrk))
./arch/ia64/kernel/sys_ia64.c
		do_munmap(current->mm, addr, len);
./arch/s390x/kernel/linux32.c

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an Intel Pentium III machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

New do_mremap vulnerabitily.

[Raphael Rigo]

Since it seems nobody posted it yet (at least I hope so) :

http://www.isec.pl/vulnerabilities/isec-0014-mremap-unmap.txt

It is a local root exploit.

Raphaël Rigo

Re: New do_mremap vulnerabitily.

[Linus Torvalds]

On Wed, 18 Feb 2004, Raphael Rigo wrote:
>
> Since it seems nobody posted it yet (at least I hope so) :
> 
> http://www.isec.pl/vulnerabilities/isec-0014-mremap-unmap.txt

Fixed in 2.6.3 and 2.4.25 (and, I think, vendor kernels), please upgrade
if you allow local shell access to untrusted users.

		Linus

Re: New do_mremap vulnerabitily.

[Chris Friesen]

Linus Torvalds wrote:

> Fixed in 2.6.3 and 2.4.25 (and, I think, vendor kernels), please upgrade
> if you allow local shell access to untrusted users.

There is still a call to do_munmap() that does not check the return 
code, called from move_vma(), which in turn is called in do_mremap().

Can that call ever fail and cause Bad Things to happen?

If we know that its never going to fail, it might be useful to have a 
comment explaining it so we don't open up more exploits in the future.


Chris


-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: New do_mremap vulnerabitily.

[Linus Torvalds]

On Wed, 18 Feb 2004, Chris Friesen wrote:
> 
> There is still a call to do_munmap() that does not check the return 
> code, called from move_vma(), which in turn is called in do_mremap().
> 
> Can that call ever fail and cause Bad Things to happen?

Yes it can fail, and no, bad things can't happen. We could return the 
error code to user space, but on the other hand, by the time the munmap 
fails we would already have done 90% of the mremap(), so it doesn't much 
help user space to know that the old area still has a vma, but no pages 
associated with it.

		Linus

Re: New do_mremap vulnerabitily.

[Andrea Arcangeli]

On Wed, Feb 18, 2004 at 02:26:45PM -0800, Linus Torvalds wrote:
> 
> 
> On Wed, 18 Feb 2004, Chris Friesen wrote:
> > 
> > There is still a call to do_munmap() that does not check the return 
> > code, called from move_vma(), which in turn is called in do_mremap().
> > 
> > Can that call ever fail and cause Bad Things to happen?
> 
> Yes it can fail, and no, bad things can't happen. We could return the 
> error code to user space, but on the other hand, by the time the munmap 
> fails we would already have done 90% of the mremap(), so it doesn't much 
> help user space to know that the old area still has a vma, but no pages 
> associated with it.

which is a bug, mremap has to retire fully and it's not doing that
(obviously we don't want to write a retirement logic, we only want to
preallocate whatever needed so we don't need to retire), but it's not a
bad bug, since it only matters for real apps, an real apps will only
fall into this do_munamp due the oom condition, which isn't going to
trigger in do_munmap anyways, and even in the unlikely case that it does
it is extremly unlikely to generate an exploitable hole in the real (non
malicious) app.

Re: New do_mremap vulnerabitily.

[Andrea Arcangeli]

On Wed, Feb 18, 2004 at 05:13:56PM -0500, Chris Friesen wrote:
> Linus Torvalds wrote:
> 
> >Fixed in 2.6.3 and 2.4.25 (and, I think, vendor kernels), please upgrade
> >if you allow local shell access to untrusted users.
> 
> There is still a call to do_munmap() that does not check the return 
> code, called from move_vma(), which in turn is called in do_mremap().
> 
> Can that call ever fail and cause Bad Things to happen?

it shouldn't cause bad things, it may generate a corrupt address space
from userspace point of view (the original vma will be stil there), but
it's like if you did one more mmap, so it's only a problem if you can
drive the app to buffer overflow or something like that because of this
corrupted address space. So it's only an userspace issue with real apps,
and with real apps the only thing that can make munamp fail is an oom
which is near to impossible for you to oom the app exactly in this
do_munmap call, the by far highest probability is that the first oom
will happen in the page faults, not in the syscalls.

> If we know that its never going to fail, it might be useful to have a 
> comment explaining it so we don't open up more exploits in the future.

the whole code needs a revamp for example for when the pagetables cannot
be allocated and the merging isn't retired (similar problem to the
do_munmap you mentioned above and there are other issues like that),
mremap simply isn't retiring correctly in presence of oom errors, that's
only an userspace issue, no way to exploit the kernel with that, we've
to fix it for 2.6 to provide perfect retirement from oom (basically only
a pratical matter with full overcommit but anyways). For 2.4 where the
thing will go in production the next day, going with the bandaid from
Solar was the simplest and in turn safest solution without risk of
regression.