SEO

Hello,

there is a local root exploit available, which allowes to get root
access on any Slackware multiuser system!

To fix this hole, you have to compile kernel 2.6.24.2 on your own. You
may use "make oldconfig" to copy the kernel configuration of the
official Slackware kernel.

Exploits:
http://www.milw0rm.com/exploits/5092
http://www.milw0rm.com/exploits/5093

CU

Manuel

Why the hell do you post the exploits?


Manuel Reimer wrote:
> Hello,
>
> there is a local root exploit available, which allowes to get root
> access on any Slackware multiuser system!
>
> To fix this hole, you have to compile kernel 2.6.24.2 on your own. You
> may use "make oldconfig" to copy the kernel configuration of the
> official Slackware kernel.
>
> Exploits:
> http://www.milw0rm.com/exploits/5092
> http://www.milw0rm.com/exploits/5093
>
> CU
>
> Manuel
>


--
On dira ce qu'on voudra, j'étais pas un petit loubard comme les autres.
(Rocky)

On Mon, 11 Feb 2008 12:56:30 +0100, Manuel Reimer <mreimer@expires-29-02-2008.news-group.org> wrote:

>Hello,
>
>there is a local root exploit available, which allowes to get root
>access on any Slackware multiuser system!
>
>To fix this hole, you have to compile kernel 2.6.24.2 on your own. You
>may use "make oldconfig" to copy the kernel configuration of the
>official Slackware kernel.

Linux kernels 2.6.23.16 and 2.6.22.18 also have the fix.

See: http://www.kernel.org/pub/linux/kernel/v2.6/?C=M&O=D for the latest
kernel patches.

Grant.
--
http://bugsplatter.mine.nu/

Grant wrote:
> Linux kernels 2.6.23.16 and 2.6.22.18 also have the fix.

> See: http://www.kernel.org/pub/linux/kernel/v2.6/?C=M&O=D for the latest
> kernel patches.

Interesting. Thanks for this info.

Unfortunately it's not easy to find out, which kernels are still
supported. In this case, it would be a possible solution to update
Slackware 12.0 to kernel 2.6.22.18.

CU

Manuel

ciol wrote:
> Why the hell do you post the exploits?

Why not? A big german publisher (heise.de) had those links on their
ticker. At least most of the german IT people should know those
exploits, now.

Goal of this posting is to show, that the kernel, which is the current
stable kernel of Slackware 12.0 is insecure.

Maybe it would be a good idea to restart something like "slacksec.info",
to publish "inofficial" security patches...

CU

Manuel

On Mon, 11 Feb 2008 23:11:17 +1100, Grant <g_r_a_n_t_@dodo.com.au> wrote:

>On Mon, 11 Feb 2008 12:56:30 +0100, Manuel Reimer <mreimer@expires-29-02-2008.news-group.org> wrote:
>
>>Hello,
>>
>>there is a local root exploit available, which allowes to get root
>>access on any Slackware multiuser system!
>>
....
>Linux kernels 2.6.23.16 and 2.6.22.18 also have the fix.

Hmm, it appears the 2.6.22.18 patch may be borked (it doesn't remove the
problem code as in the other kernel version patches), I'm running 2.6.23.16
here, as 2.5.24.2 is a bit too new for my liking...

Grant.
--
http://bugsplatter.mine.nu/

ciol wrote:
> Why the hell do you post the exploits?
>
>
>


well, I got the exploits from a link on /. yesterday, so this isn't
exactly an unknown thing anymore.

Ray

mreimer@expires-29-02-2008.news-group.org wrote:
> Grant wrote:
>> Linux kernels 2.6.23.16 and 2.6.22.18 also have the fix.
>
>> See: http://www.kernel.org/pub/linux/kernel/v2.6/?C=M&O=D for the latest
>> kernel patches.
>
> Interesting. Thanks for this info.
>
> Unfortunately it's not easy to find out, which kernels are still
> supported. In this case, it would be a possible solution to update
> Slackware 12.0 to kernel 2.6.22.18.

I applied the patch to my 2.6.21.5-smp kernel from Slackware 12.0 today
and it does apply and 'fixes' the problem. (That is, the exploit works
before, and does not work after.)

The patch I used is from the Linux Kernel mailing list, here:
http://marc.info/?l=linux-kernel&m=120271504513333&w=2

So no, you do not have to move to a newer kernel version if you don't want
to.

On Tue, 12 Feb 2008, Keith Keller wrote:

>> Real servers do not allow telnet, do not allow anyone but sys admins
>> access to ssh,
>
> This is of course completely untrue. How would one work remotely
> otherwise? IPSec is one option, but how many of your users are going to
> go through that much trouble?


Bullshit, if you dont restrict access to it, you deserve everything you
get.

and its simple, if one works remotely one has their IP in an ACL, and only
those in postion of trust will ever get that privilidge.

>>> local exploits = minimal risk

--
Cheers
Res

mysql> update auth set Framed-IP-Address='127.0.0.127' where user= 'troll';

On Wed, 13 Feb 2008, Manuel Reimer wrote:

> Any hole is critical. That's also the problem, I see with the "only patch a
> minimum" philosophy behind Slackware.

not really, a machine that has no public access and is completely
protected can run a 1.0.1 kernel and be completely safe from these
lifeless turdfaced script kiddies, its not just a case of server
management, its also network managment, its trivial on a Juniper or even a
Cisco to create an ACL for your main servers that protect them from
lowlifes


> understand, why there is no update for SeaMonkey, so far. In the past, they

Let me see...

~$ cd /var/ftp/pub/MIRRORS/slackware/slackware-12.0/patches/packages
~$ ls |grep seamonkey | grep 1.1.8

seamonkey-1.1.8-i486-1_slack12.0.tgz
seamonkey-1.1.8-i486-1_slack12.0.tgz.asc
seamonkey-1.1.8-i486-1_slack12.0.txt

.......now broswing mozilla.org, that claim 1.1.8 is current...


> I still think, it would be great to restart something like "slacksec.info" as
> an alternative source for security patches.

No, I disagree, Slackware has very little problems *because* only a select
few people have the right to issue packages, that includes security
updates, I would have less faith in Slackware if 'any ol clown' could
contribute to this, FFS look at the mess they call fedora, that is reason
enough NOT to let unknown and untrusted people mess with the distro.


> What about a small mistake while programming an CGI script? What if this
> script allowes a remote attacker to run shell commands? Wouldn't it be nice,
> if the attacker only is able to run his commands with the rights of the
> "apache" user, which usually is able to do nearly nothing on the system?

Users get their own system UID, 710 perms (group apache needs to acces
sit afterall lol), only ftp access via database no /etc/passwd shell access,
suexec and tightened php, of course I know its not foolproof, but its stopped
the lame little turds for many years so far, any damage that might occur
is only going to be to a single host that runs crap that allows
people to take control of their site, like phpnuke, if they run it they
deserve what they get


--
Cheers
Res

mysql> update auth set Framed-IP-Address='127.0.0.127' where user= 'troll';