Onderwerp: Re: OpenBSD kernel holes ...

<snip>

> from http://www.wideopenbsd.org/errata.html
>
> All architectures
>
> 005: RELIABILITY FIX: November 4, 2003
> It is possible for a local user to cause a system panic by
> executing
> a specially crafted binary with an invalid header.
> A source code patch exists which remedies the problem.
>
>
> reliability ??? ehh ;-P yeah yeah right!
>

um, that's the wrong errata entry. For 3.4 -

006: SECURITY FIX: November 17, 2003
It may be possible for a local user to overrun the stack in
compat_ibcs2(8).
ProPolice catches this, turning a potential privilege escalation into
a denial of service. iBCS2 emulation does not need to be enabled via
sysctl(8) for this to happen.
A source code patch exists which remedies the problem.

Taken from http://www.openbsd.org/security.html#34

i will be releasing a paper regarding kmem allocator (heap) overflows in
kernel space and exploit for patch 005 will be in its content.

buf = malloc(user_controled_size);
vn_rdwr(UIO_READ, ..., user_buf, user_controlled_size, ...);

these types of vulnerabilities are %100 exploitable!
check kern_malloc.c line 178

if (size > MAXALLOCSAVE)
allocsize = round_page(size);

this might hint you or not ...

i have only release the stack based exploit since there is nothing new in
the technique but the heap technique deserves more explanation and
attention than an exploit post ...

- noir


On Tue, 18 Nov 2003, Steve Tornio wrote:

> <snip>
>
> > from http://www.wideopenbsd.org/errata.html
> >
> > All architectures
> >
> > 005: RELIABILITY FIX: November 4, 2003
> > It is possible for a local user to cause a system panic by
> > executing
> > a specially crafted binary with an invalid header.
> > A source code patch exists which remedies the problem.
> >
> >
> > reliability ??? ehh ;-P yeah yeah right!
> >
>
> um, that's the wrong errata entry. For 3.4 -
>
> 006: SECURITY FIX: November 17, 2003
> It may be possible for a local user to overrun the stack in
> compat_ibcs2(8).
> ProPolice catches this, turning a potential privilege escalation into
> a denial of service. iBCS2 emulation does not need to be enabled via
> sysctl(8) for this to happen.
> A source code patch exists which remedies the problem.
>
> Taken from http://www.openbsd.org/security.html#34
>
>

> I may be wrong here, but I don't think that any of the kern.emul.*
> executable emulations are actually enabled on a default install. I have
> installed openbsd in environments requiring one of these since 3.2 and
> have had to specifically enable them every time. COMPAT_* are compiled in
> the default kernel, but are turned of via sysctl in the default install.

this exploit will get you uid=0 in all default installs starting from 2.6
upto and including 3.3. i have personally tested 2.6, 3.0, 3.1, 3.2, 3.3
on vmware (since i cann't effort to waste real hardware on openbsd.)

> that matter. IMHO, the slogan should be "More secure by default".

IMHO, the slogan should be "Less secure than claimed".

>
> This does fall under reliability fix category, though, since it isn't really
> a security issue, the bug puts the system into one of its most secure states:
> halted. Well, that is as long as youve disabled the kdb, which you should have
> on a production box.

this so true for OpenBSD. yes its most secure state is: halted.

- noir

On Tue, 18 Nov 2003, Coleman Kane wrote:

> This does fall under reliability fix category, though, since it
> isn't really a security issue, the bug puts the system into one
> of its most secure states: halted. Well, that is as long as
> youve disabled the kdb, which you should have on a production
> box.

It's a denial of service attack then.

It's very simple really: the OpenBSD team graciously maintains
and develops a distribution of software. If one of the components
exhibits a security flaw in a reasonable configuration then it is
a security hole.

That's all there is to it. No need for PR damage control.

--
Thamer Al-Harbash
GPG Key fingerprint: D7F3 1E3B F329 8DD5 FAE3 03B1 A663 E359 D686 AA1F