What's this about "Evil Code" kernel bug?

Hello.
I have heard hints about some kind of flaw in the kernel that allows a C
program to crash a CPU with just a normal user's access. I was wondering
what the story is and if there is a fix (and how to apply said fix - I am
on Fedora 1 with no kernel source in sight...)
Thanks
--
Bats
~..~
(I can only post on weekends and rare times during the week.)

> I have heard hints about some kind of flaw in the kernel that allows a C
> program to crash a CPU with just a normal user's access. I was wondering
> what the story is and if there is a fix (and how to apply said fix - I am
> on Fedora 1 with no kernel source in sight...)

It has to do with floating point instructions used within an interrupt or
signal handler. It seems that this type of code can reliably crash the
kernel: http://cve.mitre.org/cgi-bin/cvename...=CAN-2004-0554

I've been trying to figure out the recent status on this problem for a
while. It does affect "Linux kernel 2.4.2x and 2.6.x for x86" including
kernel 2.4.26, but a patch is available. Unfortunately there is not yet
2.4.27 that includes the fix.

What bothers me is, the patch that I saw fixes only a specific instance of
the code that can crash the kernel but does not correct a more fundamental
underlying problem. In other words, I'm not confident that the kernel patch
is sufficient to really protect your system.

--
Jem Berkes
http://www.sysdesign.ca/

On 2004-07-10, Bats <nomail@no.way> wrote:

> I have heard hints about some kind of flaw in the kernel that allows a C
> program to crash a CPU with just a normal user's access. I was wondering
> what the story is and if there is a fix

http://search.linuxsecurity.com/advi...sory-4521.html

IIRC, this exploit requires shell access to your machine. If you don't
provide untrusted shell access your risk is mitigated.

--

-John (john@os2.dhs.org)

John Thompson wrote:

> If you don't
> provide untrusted shell access your risk is mitigated.

Forgive a simple one who does not grok the subtleties of security and please
explain how to check that I have not inadvertently provided such access.


--
Bats
~..~
(I can only post on weekends and rare times during the week.)

On Sun, 11 Jul 2004 09:19:26 +0200, Bats wrote:

> John Thompson wrote:
>
>> If you don't
>> provide untrusted shell access your risk is mitigated.
>
> Forgive a simple one who does not grok the subtleties of security and please
> explain how to check that I have not inadvertently provided such access.

Remote shell access is usually provided by ssh or telnet, telnet is not
installed by default in Fedora, but it doesn't hurt to check it. To check
if they are running:

netstat -natu
....
tcp 0 0 192.168.100.1:53 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
....

You have to check if there is something listening in ports 22 or 23.
i.e:
0.0.0.0:22

You can stop the telnet and ssh daemons with:
service sshd stop
service telnetd stop # I'm not sure about this one.

If you don't want them to start in the next boot use ntsysv to take them
out of the start up process.

Jesus wrote:

> On Sun, 11 Jul 2004 09:19:26 +0200, Bats wrote:
>
>> John Thompson wrote:
>>
>>> If you don't
>>> provide untrusted shell access your risk is mitigated.
>>
>> Forgive a simple one who does not grok the subtleties of security and
>> please explain how to check that I have not inadvertently provided such
>> access.
>
> Remote shell access is usually provided by ssh or telnet, telnet is not
> installed by default in Fedora, but it doesn't hurt to check it. To check
> if they are running:
>
> netstat -natu
> ...
> tcp 0 0 192.168.100.1:53 0.0.0.0:* LISTEN
> tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
> ...
>
> You have to check if there is something listening in ports 22 or 23.
> i.e:
> 0.0.0.0:22
>
> You can stop the telnet and ssh daemons with:
> service sshd stop
> service telnetd stop # I'm not sure about this one.
>
> If you don't want them to start in the next boot use ntsysv to take them
> out of the start up process.

0.0.0.0:22 was in the list. Stopping sshd put paid to that. Thanks for the
info.
--
Bats
~..~
(I can only post on weekends and rare times during the week.)

Bats wrote:

>John Thompson wrote:
>
>
>
>>If you don't
>>provide untrusted shell access your risk is mitigated.
>>
>>
>
>Forgive a simple one who does not grok the subtleties of security and please
>explain how to check that I have not inadvertently provided such access.
>
>
>
>
Filter out all incoming telnet and ssh with ipchains or iptables, and
you won't have to think about it. We hope.

--
Spammers' real email addresses:
arero68@hanmail.net business@99peak.com epschao@sogiant.twmail.net
gagq@gagq.com good_day@sendmailforyou.com
imc911@netian.com kim@derek.nl infobank7655@hanmail.net iloveadult2004@yahoo.co.kr
kingoffice@so-net.net.tw ksc-0110@hanmail.net medsman25@aol.com mom666@seed.net.tw
sogiant.service@msa.hinet.net succa@roofo.com smtp007@so-net.net.tw shir88@seed.net.tw
tlqwkd2@hanmail.net user2@989888.com wjuuberich@yahoo.com.tw
yahoomelsww@yahoo.com

Check out my Java, SQL and Python samples at http://rowland.blcss.com/

> Forgive a simple one who does not grok the subtleties of security and
> please explain how to check that I have not inadvertently provided
> such access.

You don't necessarily need ssh or telnet shell access for this to be a
problem... someone who can upload cgi scripts that execute on the web
server can also run exploit code.

--
Jem Berkes
http://www.sysdesign.ca/

On 2004-07-12, Jem Berkes <jb@users.pc9.org> wrote:

>> Forgive a simple one who does not grok the subtleties of security and
>> please explain how to check that I have not inadvertently provided
>> such access.

> You don't necessarily need ssh or telnet shell access for this to be a
> problem... someone who can upload cgi scripts that execute on the web
> server can also run exploit code.

Assuming, of course, that you're running a web server on the machine in
question.

The bottom line is to only run the services you strictly require.

--

-John (john@os2.dhs.org)

John Thompson <john@starfleet.os2.dhs.org> writes:

]On 2004-07-12, Jem Berkes <jb@users.pc9.org> wrote:

]>> Forgive a simple one who does not grok the subtleties of security and
]>> please explain how to check that I have not inadvertently provided
]>> such access.

]> You don't necessarily need ssh or telnet shell access for this to be a
]> problem... someone who can upload cgi scripts that execute on the web
]> server can also run exploit code.

]Assuming, of course, that you're running a web server on the machine in
]question.

]The bottom line is to only run the services you strictly require.

The problem is that none of these things actually close the hole. They are
all ways to try to prevent the necessary condition that the hole be
triggered, namely that someone runs the program on your machine. Anyone who
can run an arbitrary short program on your machine can trigger the bug.
This includes people who you want to be able to sign on. The
telnet/ssh/http is just to stop people from outside from being able to sign on.
It does not make your machine insensitive to the bug, it simply prevents
outsiders from running a program which could trigger the bug.

Any buffer overflow fault in any program which listens to the net could
also be used. (nfs, mail, fetchmail, viruses in email, ....)

]--

]-John (john@os2.dhs.org)